Netty: 3 DNS Cache Poisoning Flaws and 20+ July CVEs, Fixed in 4.1.136

Let us start with the honest part. CVE-2026-59921, added to the US vulnerability database (NVD) on July 28, 2026, carries a severity of 5.7 (medium) and is clearly milder than the three flaws from June that this article originally covered (severity 8.7 and similar). The conditions it needs are narrow too. This is not a case of "another critical hole in Netty."

But while digging into that one entry, something more worth telling turned up. The July releases of Netty are a security update that closes more than 20 vulnerabilities at once. The project's own announcements list 21 fixes in 4.1.136.Final (released July 9) and 22 in 4.2.16.Final (released July 6). CVE-2026-59921 is just one of them, and not one of the heavier ones. Which means that any organization that upgraded to June's DNS fix (4.1.135.Final / 4.2.15.Final), felt safe and stopped there still has all 20-plus open.

Netty is the building block that lets servers written in Java handle traffic at high speed. It runs in places where its name never shows up: the full-text search engine Elasticsearch, the Google-led communication framework gRPC, the distributed database Cassandra, the large-scale data engine Spark, and the reactive side of Spring Boot. Even if you never chose it, it is probably sitting deep inside something else you pulled in, which is why "this does not concern us" is a hard line to hold. This article now covers June's three DNS flaws and July's additions in one place, and leads with the answer to the real question: how far do you have to upgrade for all of it to be closed?

July's One New Flaw Is Milder Than June's Three

First the numbers. Severity is the "CVSS" score, an international common scale from 0 to 10. In the table, "Vendor" is the value assigned by GitHub, which issues Netty's security advisories, and "NVD" is the value the US National Institute of Standards and Technology database re-assigned on its own.

There are two discrepancies in this table that will cause confusion if left unexplained. The first is that for June's two DNS flaws (CVE-2026-45674 and CVE-2026-47691), the vendor's 8.7 and NVD's 10.0 flatly disagree. The vendor factored in "high attack complexity" and landed on 8.7; NVD dropped that condition and assigned the maximum, 10.0. If your scanner pulls NVD's value, the same hole is reported at top severity. In practice, as explained below, DNS spoofing needs effort and luck to succeed, so we consider the vendor's read closer to reality. Still, it is worth knowing the history so nobody panics when 10.0 lands in an internal report. Note also that our earlier text listed CVE-2026-47691 as 8.6; rechecking the primary sources shows 8.7, and we have corrected it.

The second is that the 5.7 assigned to CVE-2026-59921 differs from the reporter's own assessment. The body of the vendor's advisory (GHSA-gcjf-9mgh-3p7g) still carries the reporter's own calculation of "8.1 (High)". The value adopted officially is the vendor's 5.7, and NVD copied that across. The gap comes from the reporter judging the flaw reachable over the internet with data exposure, while the vendor judged it reachable from an adjacent network with no confidentiality impact. From here on, the official 5.7 is the number we work from.

Now the main point. July's releases did not close only that fourth flaw. The 21 entries in the vendor's announcement (22 on the 4.2 line) include memory exhaustion in the STOMP, SPDY and HAProxy components that can take a server down, XML parsing that ships with unsafe defaults, and certificate revocation checks that are not performed correctly. The individual items are tabulated later on. This article covers the newest flaw, CVE-2026-59921, first, but read it knowing that the reason to upgrade is those 20-plus, not this one.

Four Flaws, Four Different Targets and Ways In

Start with CVE-2026-59921. The people who can reach it are anyone in a position to freely send files into a service that has a file-attachment screen or an intake API. A SaaS product anyone can sign up for, a business system that receives documents from outside, an integration platform that exchanges files with partners: an attacker who slips into one of those creates an account under their own name and works entirely within features that are meant to be used. No special privileges are needed.

One line break is all it takes. Plant it in the "name" of an uploaded file, and the service writes an extra line into the header it attaches when forwarding the file on to another server internally. Rewrite a header that says "this is an image" into one that says "this is a web page", and the receiving side displays as a page what it thought it had stored as an image. The instructions embedded there then run in the browser of whoever views it later. The awkward part is that the entry point is the filename, a place nobody thinks of as dangerous.

Being shown content you never asked for, and losing your logged-in session with it: that is what the people using the service stand to suffer. Operators are left with a different injury: they carry the fact that suspicious content was served from their own domain, and lose time working out the cause. June's three DNS flaws, by contrast, are holes a completely different group goes after, aimed at pointing the traffic itself at a fake server. Those attackers want to cut into server-to-server communication and harvest credentials, and when they succeed the damage spreads far more quietly and far more widely. Same product, different places to check, different level of urgency.

4.1.136 or 4.2.16: Which Line to Land On

This is probably the list readers need most. June's and July's fixes are laid out together. Check which line you are on (4.1 or 4.2), then find your row.

The 4.2 line has one more entry because it alone carries the HTTP/3 component (netty-codec-http3) and its fix, CVE-2026-56816. The 4.1 and 4.2 lines are maintained separately, so you cannot judge which is newer from the number alone. 4.1.136.Final and 4.2.16.Final are both endpoints that carry the same July fixes.

Updating the Upper Library Does Not Close July's Fixes

The pitfall in this whole upgrade sits right here. In many shops nobody declares Netty directly; you take whatever version Spring Boot or gRPC decided on. So we checked, one by one, which Netty version the latest release of each actually pins, using the published dependency definition files (BOMs). The result: none of them carry July's fixes.

We checked against the definition files hosted by the distributors themselves (Spring Boot 4.1.0's dependency definition, gRPC-Java 1.83.0's dependency definition). Spring Boot 3.4 deserves particular attention: it still pins 4.1.130.Final, so June's three DNS flaws are not closed there either. Waiting for the upper library will not get you there, which is why the "do it yourself" steps below matter.

A Closer Look at July's New Entry

CVE-2026-59921: A Line Break in an Outgoing Filename Adds Lines to the Header

Netty has a component (HttpPostRequestEncoder) that assembles data containing files and sends it out to another server. It attaches to each piece of data a small header (Content-Disposition) stating what the file is called. Each line of that header is delimited by a line break. But in CVE-2026-59921, the filename was pasted into the header as-is, so a filename containing a line break adds lines. The classification is "improper neutralization of CRLF sequences" (CWE-93).

The vendor's advisory carries the reporter's working proof-of-concept code and its output verbatim. Sending a filename of "innocent.txt"(line break)Content-Type: text/html(line break)X-Injected: true" produced an actual Content-Type: text/html line and an X-Injected: true line inside the assembled data. The verification was done on Netty 4.2.12.Final. If the receiving side trusts the first type declaration it encounters, a file sent as an image is handled as a web page, leaving room for embedded instructions to run. The advisory also shows how a forged delimiter can be used to insert an additional form field afterwards.

What is affected is a setup that uses Netty to send files outward from your side. Do not get this backwards. The common case of "receiving a file a user uploaded on your own server" is handled by a different component and is not in scope here. What is in scope: an upload endpoint that relays a received file, filename and all, on to another service; a gateway that assembles values arriving from outside and passes them to an internal API; microservices that hand files to each other; and test automation that builds filenames from user input. The component the vendor lists as affected is io.netty:netty-codec-http, covering everything before 4.1.136.Final and 4.2.0.Final through 4.2.15.Final.

We also confirmed the fix itself in the published source. In 4.1.136.Final, the entry point that sets the filename (setFilename) has been changed from a plain "is it non-null" check to a check called FileUploadUtil.validateFileNameForMultiPart. That check does not merely reject line breaks: it rejects any filename containing a control character, the delete character, a double quote (") or a backslash (\), throwing an error. It is stricter than the mitigation the reporter suggested.

That strictness creates one caveat when upgrading. Applications whose filenames legitimately contain quotes or backslashes may find processing stops with an IllegalArgumentException after the update. Code that passes a Windows path (C:\dir\file.txt) straight through as the name is one example that will trip. Take a look at wherever filenames are constructed before you upgrade, and you avoid the surprise. Note that the field name side has long had processing that strips line breaks and tabs, and it is unchanged between 4.1.135.Final and 4.1.136.Final. The actual hole was on the filename side.

Per the advisory, the reporter is Yu Bao of PayPal's Cyber Security Team. The vendor published the advisory on July 22 and NVD listed it on July 28, both after the fixed releases in early July. Because the fix came first and the number second, any organization that updated during July is already covered.

June's Three DNS Flaws (Traffic Redirected to a Fake Server)

Next, the three flaws published in June. All of them concern how "DNS", the internet's address lookup system, is handled. 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 that conversion result can be swapped for a fake one, the communication itself is redirected into the attacker's hands. Collectively these are known as "DNS cache poisoning." All three are closed in 4.1.135.Final / 4.2.15.Final, and naturally also in the July releases.

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 vendor rates the severity at CVSS 8.7. While it leads to eavesdropping and tampering, it is not the kind that takes a service down, so the impact on availability is rated as "none." As noted above, NVD assigned 10.0 to the same hole, so what you see depends on which value your scanner pulls.

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 vendor rates it at CVSS 8.7, the same as CVE-2026-45674, and NVD likewise assigned 10.0. The fix landed 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. The vendor rates the severity at CVSS 6.8.

The Other Flaws Closed by the Same 4.1.136 / 4.2.16

Here are the higher-rated items among the vulnerabilities the July releases carry. The rating column is the vendor's (GitHub's) classification. Including entries that did not fit the table, the vendor's announcement lists 21 items on the 4.1 line and 22 on the 4.2 line, two of which are written as "CVE-2026-XXXXX" because a number had not been assigned yet.

Laid out like this, most of July's batch is the "send a lot and stop the server" kind, and several carry a heavier rating than this month's addition, CVE-2026-59921. Flaws that let someone halt processing bite hardest at whatever endpoint accepts traffic from outside. The same pattern keeps repeating on the web server side: it is worth reading this alongside the Apache HTTP/2 flaw that burns CPU with very little traffic and the Apache MINA flaw, which sits in the same lineage of Java networking foundations. Similar issues on the server product side are collected in our Apache Tomcat vulnerability roundup.

How to Check Whether Your System Uses It

Netty is the poster child for components you use without realizing it. Start by printing the version actually present. With Maven, the following single line lists everything, transitive dependencies included. Passing just a group name to -Dincludes is sanctioned by the official documentation.

mvn dependency:tree -Dincludes=io.netty

With Gradle, naming the configuration used at runtime is the reliable approach. If you want to trace just one dependency to find "which library is dragging in the old Netty", use dependencyInsight. This syntax also follows the official Gradle documentation.

./gradlew dependencies --configuration runtimeClasspath

./gradlew dependencyInsight \
  --dependency io.netty:netty-codec-http \
  --configuration runtimeClasspath

Which component you look at in the output changes the verdict. CVE-2026-59921 involves netty-codec-http; June's three DNS flaws involve netty-resolver-dns; July's service-halting items involve netty-codec-stomp, netty-codec-haproxy, netty-codec-xml and others. In practice, rather than agonizing per component, it is faster to check just one thing: whether every number on the io.netty lines is 4.1.136.Final or later (or 4.2.16.Final or later). The approach to keeping dependency inventory running continuously is covered in our piece on OSS supply chain scanning, and the same method applies to Java dependencies.

Raising an Old Netty Buried Deep in Your Dependencies

As the table showed, waiting for the upper library's latest release will not close July's fixes. Even when you do not declare it directly, you can override the version in your build settings. With Maven, importing the bill of materials Netty itself publishes (netty-bom) first is the sturdy approach. Both 4.1.136.Final and 4.2.16.Final are distributed.

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.netty</groupId>
      <artifactId>netty-bom</artifactId>
      <version>4.1.136.Final</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

With Gradle, load the same bill of materials as a platform. You can also force individual versions with resolutionStrategy, but the bill of materials avoids version drift between components.

dependencies {
  implementation platform('io.netty:netty-bom:4.1.136.Final')
}

If you are on Spring Boot there is a more direct route. Spring Boot loads Netty's bill of materials through a value called netty.version in its own dependency definition, so overriding that one value swaps the whole set. With Maven, set it as a property in pom.xml; with Gradle, use ext as shown in the official plugin documentation.

<!-- Maven (Spring Boot 4.x, i.e. the Netty 4.2 line) -->
<properties>
  <netty.version>4.2.16.Final</netty.version>
</properties>

// Gradle (Groovy)
ext['netty.version'] = '4.2.16.Final'

Do not mix up the lines when you override. Spring Boot 3.5 pins the 4.1 line (4.1.135.Final) and Spring Boot 4.x pins the 4.2 line (4.2.15.Final). For 3.5 the target is 4.1.136.Final; for 4.x it is 4.2.16.Final. One more thing: Spring Boot's own documentation warns that "each Spring Boot release is designed and tested against a specific set of third-party dependencies, so overriding versions may cause compatibility issues." A small step within the same line is unlikely to break much, but run your networking tests after the override before shipping to production. The stricter filename check described above is one place this can bite.

How Urgent Is This, and What Does the Public Record Say

Look at the indicators of active abuse. The US government's CISA list of "vulnerabilities known to be exploited in the wild" (KEV) held 1,655 entries in its July 27, 2026 edition, and none of Netty's four flaws are on it. On EPSS, which estimates the probability of exploitation, June's three DNS flaws sit low at roughly 0.2 to 0.3 percent (around the bottom fifth overall), and this month's CVE-2026-59921 has no score yet. CISA's separate judgment (SSVC) also records CVE-2026-45674 as "no exploitation observed, not automatable." How to track KEV listings systematically is covered in our CISA KEV dashboard article.

The Japanese public record shows a sharp split between June and July. JVN iPedia, the vulnerability database run by Japan's IPA, has all three June DNS flaws registered in Japanese (JVNDB-2026-019795 for CVE-2026-45674, JVNDB-2026-019796 for CVE-2026-45673 and JVNDB-2026-019792 for CVE-2026-47691, all registered on June 15). For July, only three entries such as CVE-2026-44891 were registered, on July 24, and CVE-2026-59921 was still unregistered as of July 29. Neither JPCERT/CC nor IPA has issued an advisory. We also found no Japanese-language write-up covering July's batch.

Frequently Asked Questions

Q. I upgraded to 4.1.135.Final in June. Am I done?

Not done. 4.1.135.Final is the release that closed the three DNS flaws; July's 21 were closed in the later 4.1.136.Final. The newly published CVE-2026-59921 is among those 21. Take one more step, to 4.1.136.Final.

Q. I don't know whether my app uses Netty. How do I check?

With Maven run mvn dependency:tree -Dincludes=io.netty; with Gradle run ./gradlew dependencies --configuration runtimeClasspath. Both direct and transitive dependencies are listed. If an io.netty line appears, you use it. To trace which library drags in the old version, ./gradlew dependencyInsight --dependency io.netty:netty-codec-http --configuration runtimeClasspath is handy.

Q. My server accepts file uploads. Am I in scope for CVE-2026-59921?

Not if you only receive them. This hole is in the processing that uses Netty to send files outward from your side. You may be in scope if you relay a received file, filename and all, on to another service, or if you build a filename from externally supplied values and pass it to an internal API. If you are unsure, search your code for uses of HttpPostRequestEncoder.

Q. I use Spring Boot. Is updating Spring Boot enough?

No. Spring Boot 4.1.0, the latest as of July 29, 2026, pins Netty 4.2.15.Final, which does not carry July's fixes. Override the netty.version property to 4.2.16.Final (or 4.1.136.Final on the 3.5 line). Run your networking tests after the override before shipping to production.

Q. I heard the update starts throwing errors on filenames. Is that true?

It can happen. 4.1.136.Final and 4.2.16.Final add a filename check that rejects names containing control characters, the delete character, double quotes or backslashes with an IllegalArgumentException. Code that passes a Windows path straight through as a filename is one thing that will trip. Check wherever filenames are generated before you upgrade.

Q. My scanner reports severity 10.0. Should I take the service down?

That 10.0 is the value NVD assigned on its own to June's two DNS flaws (CVE-2026-45674 and CVE-2026-47691). The vendor rates the same holes at 8.7, and CISA's judgment records no observed exploitation. DNS spoofing needs the right timing and repeated attempts to succeed, so we do not see urgency at the level of taking a service down right now. The fixed releases exist, though, so a planned upgrade is needed.

Update History

References

• ▸ Netty official advisory - GHSA-gcjf-9mgh-3p7g (CVE-2026-59921 / CRLF injection via multipart filename)
• ▸ NVD - CVE-2026-59921 (CVSS 5.7 / CWE-93 / published July 28, 2026)
• ▸ Netty - 4.1.136.Final release announcement (list of 21 security fixes)
• ▸ Netty - 4.2.16.Final release announcement (list of 22 security fixes)
• ▸ GitHub - netty-4.1.136.Final release page (changelog and source)
• ▸ Netty official advisory - GHSA-676x-f7gg-47vc (CVE-2026-45674 / CNAME bailiwick not checked)
• ▸ NVD - CVE-2026-45674 (vendor 8.7 / NVD 10.0 / DNS cache poisoning)
• ▸ NVD - CVE-2026-47691 (vendor 8.7 / NVD 10.0 / NS record bailiwick not checked)
• ▸ NVD - CVE-2026-45673 (CVSS 6.8 / query ID predictability)
• ▸ JVN iPedia - JVNDB-2026-019795 (Japanese entry for CVE-2026-45674)
• ▸ JVN iPedia - JVNDB-2026-024925 (CVE-2026-44891, one of July's registered entries)
• ▸ CISA - Known Exploited Vulnerabilities Catalog (KEV / not listed as of the July 27, 2026 edition)
• ▸ FIRST - EPSS (estimated probability of exploitation)
• ▸ GitLab Advisory - io.netty/netty-resolver-dns (affected version list)
• ▸ Apache Maven - Filtering the dependency tree (the -Dincludes format)
• ▸ Gradle - Viewing and debugging dependencies (dependencies / dependencyInsight)
• ▸ Spring Boot - Customizing managed versions (setting netty.version)