TCP and DNS Can Still Be Hijacked From the Wrong Side of the Network

• The Mess: Researchers found a way for an unprivileged malicious application to collaborate with a remote attacker and recover network state that should be hidden behind TCP and DNS randomization.
• The Damage: The technique can enable TCP connection hijacking and DNS cache poisoning without traditional on-path access, turning an ordinary malicious app into a network attack primitive.
• The Fix: Patch affected operating systems, prefer encrypted protocols, enforce DNS protections, and stop assuming that an off-path attacker automatically means a harmless attacker.

TCP sequence numbers and randomized DNS source ports have existed for a reason.

They are supposed to make spoofing traffic difficult for an attacker who cannot see the legitimate packets.

If you are not on the network path, you shouldn’t know the values needed to forge the next packet.

That assumption just took another hit.

Researchers Tamir Shahar and Amit Klein demonstrated a new class of attacks in which an unprivileged malicious application running on the victim device collaborates with a remote off-path attacker.

The local application cannot simply sniff network traffic.

It doesn’t need to.

Instead, it abuses ordinary operating-system interfaces and observable network-stack behavior to infer information that should have remained hidden.

The researchers demonstrated TCP connection hijacking against Linux, Android, Windows, macOS and iOS.

They also demonstrated DNS cache poisoning against Windows, Android and Linux systems using systemd-resolved.

The attacker doesn’t need to sit in the middle

The classic network attack model is easy to visualize.

The attacker sits somewhere between the victim and the server.

Packets pass through the attacker.

The attacker reads them.

The attacker modifies them.

The attacker injects new ones.

That’s a man-in-the-middle.

The research describes something different.

The remote attacker remains off-path.

The malicious application is also not traditionally on-path.

Instead, the two cooperate.

The local application extracts information from the operating system and networking stack.

It sends that information to the remote attacker.

The remote attacker uses it to construct packets that should otherwise be impossible to forge reliably.

The architecture is roughly:

Malicious app

↓

OS/network side channels

↓

TCP sequence / UDP source-port information

↓

Remote attacker

↓

Spoofed packets

↓

TCP hijacking / DNS poisoning

That is a nasty change in perspective.

The attack does not defeat TCP cryptographically.

It attacks the assumptions surrounding TCP.

TCP’s secret sauce is the sequence number

TCP connections use sequence numbers to maintain the state of the byte stream.

During the handshake, each endpoint chooses an Initial Sequence Number, or ISN.

The peer must acknowledge the correct sequence number.

An off-path attacker who doesn’t know it should have an extremely difficult time injecting packets that the target accepts.

The researchers found ways for an unprivileged application to infer enough information about these values to make the protection substantially weaker.

Their techniques exploit several ordinary mechanisms, including:

• bind() and bind(0);
• IP options;
• classic BPF;
• /proc;
• TCP ISN generation behavior.

The important point is that none of these mechanisms was designed to become a TCP-hijacking API.

The attack emerges from their interaction.

cBPF becomes an information leak

One of the more interesting Linux pieces involves classic BPF.

Modern Linux discussions tend to focus on eBPF, but cBPF is much older and considerably more restricted.

The researchers found that packet truncation behavior can be abused as a side channel.

A malicious application doesn’t need direct access to packets.

Instead, it can manipulate how much information reaches a socket and infer information from the resulting behavior.

The operating system becomes the oracle.

The application asks an innocent-looking networking question.

The response leaks one more bit of information than it should.

Repeat that enough times and supposedly unpredictable state starts becoming predictable.

The same idea reaches mobile platforms

This isn’t a Linux-only curiosity.

The researchers demonstrated TCP hijacking on:

• Linux;
• Android;
• Windows;
• macOS;
• iOS.

That makes the finding much more interesting.

Different operating systems use different networking stacks and security models.

Yet the underlying problem survives because the attack isn’t tied to one broken function.

It targets the relationship between unprivileged applications and shared network state.

Mobile platforms are particularly interesting here because they aggressively isolate applications.

The malicious app doesn’t need root.

It doesn’t need packet capture privileges.

It doesn’t need to become the VPN.

It simply needs to run.

That’s the security boundary being challenged.

DNS gets hit too

TCP is only half of the story.

The researchers also demonstrated DNS cache poisoning.

DNS normally uses several pieces of information to make spoofed responses difficult to accept:

• transaction ID;
• source port;
• source and destination addresses.

The source port is especially useful because it increases the search space an off-path attacker has to guess.

If the attacker can infer it, a significant part of the protection disappears.

The research demonstrates that a malicious application can infer the UDP source port used by a DNS stub resolver and provide that information to a remote attacker.

The attacker can then attempt to inject a forged DNS response.

If accepted and cached, the consequences are obvious.

A legitimate domain can resolve to an attacker-controlled address.

That can redirect traffic to malicious infrastructure.

And DNS is not merely used by browsers.

It supports practically every network application on a modern operating system.

systemd-resolved is one of the targets

Linux administrators should pay particular attention to the DNS component.

The researchers demonstrated cache poisoning against the popular systemd-resolved DNS stub resolver.

This is significant because systemd-resolved is common on modern Linux desktops and servers.

The issue is not that systemd-resolved suddenly becomes universally exploitable.

The attack requires the specific conditions described by the researchers.

But the result demonstrates that even a local unprivileged application can interact with a system-wide DNS resolver in ways that expose information useful to a remote attacker.

Encryption changes the game

There is an important limitation.

The researchers point out that the TCP hijacking attacks are particularly relevant to applications that don’t use fully encrypted communications.

If the attacker injects data into an HTTP connection, the result can be devastating.

A forged HTTP response could contain malicious content.

A redirected connection could lead the victim to attacker infrastructure.

But HTTPS changes the equation.

The attacker may still be able to interfere with the underlying TCP connection.

They don’t automatically gain the ability to forge valid TLS records.

That distinction matters.

TCP security and application-layer cryptographic security are different layers.

A successful TCP injection does not automatically equal a TLS compromise.

The researchers explicitly identify applications and services that lack full encryption as particularly exposed.

Android has another uncomfortable number

The paper also highlights the continuing presence of cleartext traffic.

Although Android has blocked cleartext traffic by default for applications since Android 9 unless explicitly permitted, the researchers cite a 2026 large-scale study finding that 33.74% of Android apps explicitly enable HTTP cleartext traffic, while actual HTTP traffic was observed in 2,790 of 35,000 analyzed applications.

That creates an interesting collision.

One side of the security stack says:

“You don’t have to worry about off-path TCP injection because sequence numbers are unpredictable.”

The application says:

“I’m sending credentials over HTTP anyway.”

The attack research shows why that combination is dangerous.

NAT doesn’t automatically save you

The researchers also evaluated the techniques in realistic environments involving port-preserving NAT routers.

That matters because home and enterprise networks frequently place devices behind NAT.

NAT changes addressing.

It does not magically eliminate host-level side channels.

If the malicious application can extract the relevant state from the local machine, the remote attacker can potentially use that information across the NAT boundary.

In other words:

private IP

doesn’t necessarily mean

isolated attack surface.

This is an OS boundary problem

The most interesting part of the research isn’t actually TCP.

It is the boundary between applications.

A modern operating system tries to isolate applications from each other.

Application A should not be able to observe secrets belonging to Application B.

Network state is one of those secrets.

The TCP connection belongs to another process.

The DNS query belongs to the system resolver.

The malicious application should know neither the sequence number nor the UDP source port.

But the operating system exposes enough behavior around those mechanisms to create indirect observation channels.

That creates a general security pattern:

No direct access doesn’t mean no information.

Side channels can reconstruct information without ever exposing the underlying object.

This isn’t a single CVE

That’s also why this story is different from most Bugstoday articles.

There isn’t one magic vulnerable function to patch.

The researchers disclosed the techniques to Microsoft, Apple, Linux and Google, and the disclosures resulted in multiple patches.

That suggests vendors treated the findings as implementation-level security problems rather than a single application bug.

It also means administrators should not expect one universal apt upgrade or Windows KB to eliminate the entire class of attacks everywhere.

The mitigations are platform-specific.

What administrators should do

The first rule is painfully simple:

Use encryption.

HTTPS should be the default.

SSH should replace plaintext remote administration.

Email protocols should use TLS.

Applications should not transmit sensitive information over raw HTTP.

DNS should use modern authenticated or encrypted mechanisms where appropriate.

For Linux environments, administrators should keep the kernel and resolver packages current and review security advisories for their distribution.

For Windows, Android, macOS and iOS, install current security updates.

Developers have another job.

Do not assume:

“The OS isolates my application, therefore network state is impossible to infer.”

That assumption needs testing.

Applications should also avoid relying on plaintext protocols merely because they operate inside a trusted LAN.

The LAN is not a cryptographic security boundary.

Neither is localhost.

The bigger problem is composability

TCP is old.

DNS is old.

Sockets are old.

Operating-system isolation mechanisms are old.

Each component individually looks reasonable.

The problem appears when an attacker combines them.

A bind() call isn’t a security vulnerability.

cBPF isn’t a TCP exploit.

/proc isn’t a DNS poisoning primitive.

IP options aren’t automatically malicious.

TCP ISN generation isn’t broken in the conventional sense.

Put them together with a malicious local application and a remote attacker, however, and the assumptions start collapsing.

That’s classic security research.

Not:

“This function is broken.”

But:

“These individually reasonable assumptions interact in a way nobody expected.”

Bugstoday’s take

This is the kind of research that should make network engineers uncomfortable.

For years we’ve treated the off-path attacker as someone who doesn’t know enough about the connection to inject useful traffic.

Now the attacker can outsource part of the observation problem to a malicious application already running on the victim.

The remote attacker doesn’t need to see the packets.

The local application becomes their sensor.

That’s the real story.

The attack also reinforces an old rule that somehow keeps getting forgotten:

TCP is transport security, not application security.

If the application still trusts plaintext HTTP, a clever TCP injection can become a serious compromise.

And if DNS is the only thing telling an application where to connect, poisoning the resolver can redirect the entire conversation before the application even gets started.

The network stack isn’t one security boundary.

It’s dozens of small assumptions stacked on top of each other.

Attackers only need one of them to leak.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Tamir Shahar, Amit Klein — Cross User/App Network Attacks — Extended Research Paper
• ACM CCS 2026 — Paper DOI
• Google — Android Network Security Configuration
• Linux Kernel — cBPF documentation
• RFC 6528 — Defending Against Sequence Number Attacks
• RFC 9293 — Transmission Control Protocol