Netty Flaws Let Attackers Reroute Your Traffic via DNS Cache Poisoning — Update to 4.1.135.Final (CVE-2026-45674)

A vulnerability has been found in Netty, a networking foundation widely used behind the scenes on corporate servers, that lets attackers swap out the server an application thinks it is talking to for a different one of their own choosing. Fixed versions are now available. Netty is the building block that lets Java-based servers process communication at high speed, and it runs in places where its name never shows up: search engines, databases, the relays that sit between various APIs. Even if you do not recall ever using it, there is a good chance it is running deep inside some other piece of software you have pulled in.

The headline issue is CVE-2026-45674, a hole in which Netty accepts the response from DNS, the system that looks up "where is the server with this name," without checking whether it actually came from the correct party. When this is exploited, the address of the server you were supposed to connect to gets rewritten to a fake one, and you are made to connect to the attacker's server without noticing. Two related flaws in the same name-lookup processing, CVE-2026-45673 and CVE-2026-47691, were disclosed at the same time.

All three are closed in the fixed release Netty 4.1.135.Final (and 4.2.15.Final in the newer line). So far there are no reports of these being used in real-world attacks, and as explained below, exploitation requires certain conditions and a fair amount of effort, so there is no need to panic. That said, the sheer number of software products that bundle Netty makes it wise to check your own dependencies and get them updated to be safe.

What Netty Is, and Why It Concerns You

Netty is the building block that lets servers written in Java (a programming language widely used in business systems) handle large volumes of communication efficiently. It takes on the entire job of "network processing," the back-and-forth exchange of data between servers, and it is a standard choice wherever performance and stability matter. It never appears as the name of a user-facing app, but it is Netty quietly carrying the traffic underneath.

The tricky part is that even if your own application never calls Netty directly, it is extremely common for another piece of software you have pulled in to use Netty internally. This is called a transitive dependency. For example, the full-text search engines Elasticsearch and OpenSearch, the Google-led communication framework gRPC, the distributed database Cassandra, and the large-scale data processing engine Spark, many of the products familiar in corporate systems, use Netty under the hood. So even if you think "we do not use anything like Netty," it is not unusual to find it running somewhere deep down once you trace your dependencies.

The cases most likely to be affected are those using Netty's built-in feature for "resolving DNS addresses on its own." As described below, these flaws are concentrated in this DNS resolution process, so the more a system is built to frequently reach out to external servers, the higher its priority for checking.

An Overview of the Three Vulnerabilities

All three are holes related to how Netty handles "DNS," the internet's address lookup system. DNS is the mechanism that converts a human-readable name (e.g. example.com) into the numeric address (IP address) machines use to communicate. If this conversion result can be swapped for a fake one, the communication itself is redirected into the attacker's hands. The danger figures are the "CVSS" scores, an international common scale that rates severity from 0 to 10.

The core issues are CVE-2026-45674 and CVE-2026-47691, both holes that make Netty believe a fake address because it never checks whether the contents of a DNS response actually came from the correct party. CVE-2026-45673 is not the kind that hijacks a server on its own; it is a supporting hole that makes it "easier" for an attacker to land a fake response, and combined with the other two it pushes up the success rate. Collectively these are known as "DNS cache poisoning."

Where the Fake Signpost Leads, and What Gets Taken

The term "DNS cache poisoning" alone makes it hard to picture your own losses, so let us look from the attacker's side at what actually happens when this succeeds. In essence, it is an attack that swaps out one of the signposts guiding you to your destination. Following the sign, what waits at the end of the road is the attacker's server, built to look exactly like the real thing.

The ones who come after this are fraud rings that cut into server-to-server communication to steal payment details and authentication tokens, industrial spies who impersonate a business partner to inject false instructions, and ransomware crews who use the captured traffic as raw material to hunt for further ways in. What gets carried off at the substituted destination is the login access tokens that servers exchange with each other, API secret keys, the contents of communications containing payment and personal data, and the certificate information needed to impersonate the peer server. The moment the address lookup is rewritten by CVE-2026-45674, the confidential data you meant to send to the real server arrives, in full, at the attacker's server instead.

What makes this attack frightening is that almost nothing looks wrong to the user or the application. The screen works as usual, and the communication throws no errors. Only the party that traffic passes through has been switched out. The more an automated integration is built on trust between servers, the more quietly the damage spreads, and by the time anyone notices, transaction data and credentials may have been leaking for a long time.

And the responsibility for the damage falls not on Netty's developers but on the company operating the service that embedded it. The figure of CVSS 8.7 only indicates the technical severity of having communication hijacked; it does not include the cost of cleaning up the resulting data breach or rebuilding trust afterward. Exploitation may take effort, but with a fixed version already out, whether you can check your dependencies and update is what makes the difference.

A Closer Look at the Three Flaws

CVE-2026-45674: Trusting Alias Data Without Checking Its Origin

A DNS response can contain information that says "this name is an alias for another name" (a CNAME record). Properly, you must confirm whether that pointer falls within "the range the party you queried is authorized to answer for." But in CVE-2026-45674, Netty does not check this range of authority (in technical terms, the zone the responding server is actually authoritative for, its bailiwick) and unconditionally accepts and remembers the alias data included in the response.

When this is exploited, even an attacker not positioned to directly observe the communication path (such an attacker is called an "off-path attacker") can slip in fake alias data and make Netty believe the address of a different server than intended. As a result, subsequent communication to that name is redirected to the attacker's server. The severity is CVSS 8.7. While it leads to eavesdropping and tampering with information, it is not the kind that takes a service down, so the impact on availability is rated as "none."

CVE-2026-47691: The Referral Server Data Goes Unchecked Too

CVE-2026-47691 is a case where the same "unchecked origin" problem as CVE-2026-45674 occurred with a different kind of DNS data (the NS record that points to the referral server for a name). Because the attacker can replace the referral server itself with a fake one, all subsequent queries are placed entirely under the attacker's control. The severity is CVSS 8.6, and this too is fixed in the 4.1.135.Final line.

CVE-2026-45673: A Supporting Hole That Makes Fake Replies "Easier to Land"

CVE-2026-45673 is not the kind that hijacks a server on its own. A DNS query is randomly assigned a "per-query number" and a "source entry number (port)" to fend off fake responses. In this hole, the way that number was generated was easy to predict and the entry number tended to be fixed, so the probability of an attacker landing a fake response as the "correct answer" rises sharply. Combined with the two flaws above, it serves to boost the success rate of poisoning.

How Dangerous Is This (No Need to Panic, but You Cannot Ignore It Either)

These three are not the kind to panic over right away. Even the most serious, CVE-2026-45674, carries the condition "high attack complexity" in its severity rating. DNS cache poisoning requires slipping a fake response in ahead of the real one, and doing so with the query number and the like correctly guessed; success demands the right timing and a fair number of attempts. There are also no reports, as of now, of these three being used in actual attacks.

On the other hand, this is not something to leave alone. First, Netty lurks in far too many systems as a transitive dependency, and the organizations that think "this does not concern me" are precisely the ones that have fallen within its blast radius without realizing it. Second, with all three disclosed at the same time, an attacker now has both "a hole that makes the number easier to guess" and "holes that do not check origin" in hand; the combination pushes up the success rate. Third, because publishing a fix reveals where the hole is, the more time passes, the more the study of exploitation advances. No need to panic, but you should put the update on the schedule and steadily close it out; that is the accurate read on the temperature of these three.

Is Your Application Affected (Check Procedure and Version Quick Reference)

You can check the version of Netty you are currently running with mvn dependency:tree -Dincludes=io.netty if you use Maven, or gradle dependencies with Gradle. It lists which versions are present, transitive dependencies included. The part involved in these holes is specifically the DNS resolution component (netty-resolver-dns). Check your number against the table below.

If an old Netty is present through a transitive dependency, you may need to update the parent product that pulls it in (such as Elasticsearch or gRPC). It helps to start by using mvn dependency:tree to grasp "which product is dragging in the old Netty," which makes the planning easier. Following the same idea as the OSS vulnerability checking approach that inspects npm and Python dependencies, making a habit of regularly taking stock of "which version is present" for your Java dependencies too is what prevents oversights like this.

What to Do Now

The most reliable countermeasure is to update Netty to 4.1.135.Final (or 4.2.15.Final for the newer line) or later. If you depend on it directly, raise the version specified in your build settings (pom.xml or build.gradle); if it is a transitive dependency, either wait for the parent product's update or pin it to a safe version using your build tool's version-forcing feature (Maven's dependencyManagement or Gradle constraints).

If circumstances prevent an immediate update, stopgap measures you can use alongside it include restricting the DNS your internal systems use to trusted paths equipped with verification features (such as DNSSEC), and reviewing configurations that query external DNS servers directly. But these only buy time; the fundamental fix is updating the component itself. While exploitation still takes effort, taking stock of your dependencies and planning the update now is the best move to prevent this quietly spreading kind of damage.

References

• ▸ Netty official advisory - GHSA-676x-f7gg-47vc (CVE-2026-45674 / CNAME bailiwick not checked)
• ▸ NVD - CVE-2026-45674 (CVSS 8.7 / DNS cache poisoning)
• ▸ NVD - CVE-2026-47691 (CVSS 8.6 / NS record bailiwick not checked)
• ▸ NVD - CVE-2026-45673 (query ID predictability)
• ▸ Netty - Release notes (4.1.135.Final)
• ▸ GitLab Advisory - io.netty/netty-resolver-dns (affected version list)