CVE-2026-42579

What it actually does

Netty's DNS codec fails to enforce RFC 1035 domain-name limits when both parsing DNS messages and constructing DNS messages. Specifically, malformed or non-compliant domain names, such as labels longer than allowed or names exceeding protocol limits, may be accepted during decoding or emitted during encoding. This creates two exposure paths: a malicious DNS response can reach applications that decode DNS traffic with Netty, and attacker-influenced hostnames can cause applications to encode invalid DNS queries or records. The primary impact is integrity: applications, resolvers, proxies, service-discovery components, or other DNS-aware systems may process DNS data that should have been rejected.

Why it matters to the business

Applications that depend on affected Netty versions may make incorrect routing, resolution, service-discovery, or trust decisions based on malformed DNS data. Because Netty is commonly embedded as a library in Java networking products, exposure may exist indirectly through downstream frameworks or packaged applications, not only where Netty is explicitly deployed. The vulnerability is not listed in CISA KEV, has low and stable EPSS, and has no reported exploit maturity in the provided data, but it is remotely reachable in affected DNS-processing paths and has been public for 91 days, so internet-facing or DNS-sensitive services should be upgraded as part of normal vulnerability remediation priority.

How an attack unfolds

An attacker first identifies an application or product that uses an affected Netty DNS codec version before 4.2.13.Final or 4.1.133.Final. The attacker then chooses one of two paths. In the decoder path, they position themselves to provide or influence DNS responses, for example by operating an authoritative DNS server for a queried domain, influencing upstream resolution, or otherwise delivering crafted DNS traffic. They send DNS messages containing domain names that violate RFC 1035 constraints. Because vulnerable Netty versions do not properly reject those names during decoding, the application may consume malformed DNS data. In the encoder path, the attacker supplies or influences a hostname that the application later passes to Netty for DNS message creation. Netty encodes the invalid name instead of rejecting it, potentially causing downstream systems to receive or act on non-compliant DNS messages. Successful exploitation depends on how the affected application uses decoded or encoded DNS names, but the expected consequence is manipulation of DNS-related application behavior rather than code execution.

How to fix it

Upgrade Netty to a fixed release: 4.2.13.Final or later for the 4.2.x line, or 4.1.133.Final or later for the 4.1.x line. Because Netty is often pulled in transitively, review dependency trees, shaded JARs, packaged vendor components, container images, and application server bundles for embedded vulnerable versions. If an immediate upgrade is not possible, reduce exposure by rejecting untrusted hostnames before they reach Netty, enforcing RFC 1035 limits at application boundaries, avoiding use of affected DNS codec paths with untrusted DNS data, and constraining outbound DNS resolution to trusted resolvers. Mitigations should be treated as temporary; the durable fix is to consume a patched Netty version.

How to confirm the fix worked

Confirm that runtime and packaged dependencies resolve to Netty 4.2.13.Final or later, or 4.1.133.Final or later. For Maven or Gradle projects, inspect dependency output and lockfiles for io.netty artifacts, especially netty-codec-dns and related Netty modules. For packaged applications, inspect JAR manifests, software bills of materials, container layers, and vendor advisories for embedded Netty versions. Functional validation should include negative tests that submit DNS names with labels longer than 63 octets and fully qualified names longer than 255 octets; patched builds should reject these inputs during DNS encoding or decoding rather than processing them normally.

Typical attack path

1. Find a Java application, framework, gateway, resolver, proxy, or service-discovery component that uses vulnerable Netty DNS codec versions before 4.2.13.Final or 4.1.133.Final.
2. Determine whether the application decodes DNS responses, encodes DNS queries, or accepts user-controlled hostnames that are later resolved or serialized into DNS messages.
3. For decoder-side exploitation, arrange to return a crafted DNS response, such as by controlling an authoritative DNS zone queried by the target or influencing the resolver path.
4. For encoder-side exploitation, submit a malformed hostname through an exposed input path that the application later uses for DNS resolution or DNS message construction.
5. Use domain names that violate RFC 1035 constraints, such as overlong labels or overlong fully qualified names.
6. Rely on the vulnerable Netty DNS codec accepting or producing malformed DNS names instead of rejecting them.
7. Trigger incorrect application behavior, such as invalid DNS data being trusted, routed, cached, forwarded, or used in service-selection logic.

How to detect it

There are no specific public indicators of compromise, threat actors, ransomware usage, or known exploit artifacts in the provided intelligence. Detection should focus on evidence of attempted malformed DNS-name handling. Review application logs, DNS resolver logs, packet captures, WAF or gateway logs, and service-discovery logs for DNS names with labels exceeding 63 characters, full names exceeding 255 characters, unusual repeated DNS parsing failures, malformed DNS packets, or application errors occurring immediately after resolving attacker-controlled domains. For Java applications, correlate suspicious DNS activity with Netty-related stack traces, DNS codec exceptions, resolver warnings, or unexpected service-routing decisions. Network detection can flag DNS queries or responses containing invalid label lengths or oversized fully qualified domain names, but absence of such logs does not prove non-exploitation because exploitation effects depend on application-specific handling.

What your security team should do

• Inventory applications and products that include Netty, prioritizing externally exposed services, DNS resolvers, proxies, API gateways, service-discovery systems, and applications that resolve user-supplied hostnames.
• Upgrade affected Netty dependencies to 4.2.13.Final or later, or 4.1.133.Final or later, and verify that dependency management does not retain an older transitive version.
• Check vendor advisories and updates for commercial or packaged products that embed Netty, because the vulnerable code may not appear as a direct application dependency.
• Add or confirm input validation for user-supplied hostnames, including RFC 1035 label and total-name length checks.
• Review DNS egress controls so application servers use trusted resolvers and cannot be easily coerced into resolving attacker-controlled domains without monitoring.
• Monitor for malformed DNS traffic and abnormal DNS codec parsing errors, while recognizing that there are no known public exploit IOCs in the provided intelligence.
• Track this vulnerability through normal remediation SLAs; raise priority where DNS parsing or user-controlled hostname resolution is exposed to untrusted networks.