CVE-2026-45673: Netty DNS Cache Poisoning DOS Vulnerability

CVE-2026-45673 Overview

CVE-2026-45673 affects Netty, a widely used network application framework for building protocol servers and clients in Java. The vulnerability resides in Netty's Domain Name System (DNS) resolver, which generates DNS transaction IDs using a predictable pseudo-random number generator (PRNG) and defaults to a static User Datagram Protocol (UDP) source port. Attackers can exploit this reduced entropy to forge DNS responses and poison the resolver cache, a class of attack commonly known as the Kaminsky attack. Versions prior to 4.1.135.Final and 4.2.15.Final are affected. The issue is categorized under [CWE-330] Use of Insufficiently Random Values.

Critical Impact
Successful DNS cache poisoning lets attackers redirect application traffic to attacker-controlled hosts, undermining downstream integrity assumptions for any service relying on Netty's DNS resolver.

Affected Products

Netty versions prior to 4.1.135.Final
Netty versions prior to 4.2.15.Final
Applications and frameworks embedding Netty's DNS resolver component

Discovery Timeline

2026-06-12 - CVE-2026-45673 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-45673

Vulnerability Analysis

Netty's DNS resolver constructs outbound queries with two identifiers that an off-path attacker must guess to inject a forged response: the 16-bit DNS transaction ID and the UDP source port. The resolver derives transaction IDs from a predictable PRNG and binds outbound queries to a static UDP source port by default. The combined search space collapses to roughly the transaction ID alone, which is feasible to brute-force within the resolution window. An attacker who can trigger DNS lookups from a victim application and flood the resolver with spoofed responses can land a matching forgery before the legitimate authoritative answer arrives. Once cached, the poisoned record is served to subsequent lookups for the duration of its time-to-live (TTL), redirecting traffic such as Hypertext Transfer Protocol (HTTP) callbacks, microservice mesh calls, or webhook deliveries to attacker-chosen endpoints.

Root Cause

The root cause is a cryptographic weakness: the resolver relies on a non-cryptographic PRNG for transaction ID generation and does not randomize the UDP source port per query. Source port randomization and unpredictable transaction IDs are the standard defenses against DNS spoofing defined after the 2008 Kaminsky disclosure, and the absence of both controls in the same code path produces the predictable query fingerprint exploited here.

Attack Vector

The attack vector is network-based and does not require authentication or user interaction. An attacker positioned to send UDP traffic to the resolver, or able to induce the victim to resolve attacker-chosen names, races spoofed responses against the upstream resolver. The vulnerability is described in the GitHub Security Advisory GHSA-xmv7-r254-6q78.

No public proof-of-concept exploit code has been verified for CVE-2026-45673. Refer to the vendor advisory for protocol-level technical details.

Detection Methods for CVE-2026-45673

Indicators of Compromise

Outbound DNS queries from Netty-based applications consistently originating from the same UDP source port across many lookups.
Unusually high volumes of inbound UDP packets to the application's DNS source port, indicating a spoofing flood.
Cached DNS records resolving internal or third-party hostnames to unexpected IP addresses or autonomous systems.
Application connections to endpoints whose IPs do not match authoritative DNS data observed from an independent resolver.

Detection Strategies

Inventory Java dependencies for netty-resolver-dns and flag any version below 4.1.135.Final on the 4.1 branch or below 4.2.15.Final on the 4.2 branch.
Capture network telemetry at egress and alert on Netty processes binding repeatedly to a single ephemeral UDP port for DNS traffic.
Compare hostnames resolved by application logs against an out-of-band resolver to identify divergent answers indicative of cache poisoning.

Monitoring Recommendations

Forward DNS query and response logs from application hosts to a centralized analytics platform and baseline source-port entropy per process.
Monitor for spikes in malformed or duplicate DNS responses on resolver hosts, which signal active spoofing attempts.
Track software composition analysis (SCA) findings continuously so new Netty versions surface in build pipelines.

How to Mitigate CVE-2026-45673

Immediate Actions Required

Upgrade Netty to 4.1.135.Final or 4.2.15.Final across all services, container images, and shaded dependencies.
Rebuild and redeploy applications that bundle Netty transitively, including frameworks such as gRPC, Vert.x, and reactive HTTP clients.
Flush DNS caches on hosts running vulnerable Netty versions to remove any potentially poisoned entries.
Review recent outbound traffic for connections to unexpected destinations that may indicate prior exploitation.

Patch Information

The Netty maintainers fixed the vulnerability in Netty 4.1.135.Final and Netty 4.2.15.Final. The patched releases use unpredictable transaction IDs and randomize the UDP source port for each outbound query. The remediation is documented in the vendor security advisory.

Workarounds

Route Netty DNS traffic through a trusted local resolver that enforces DNS over Transport Layer Security (DoT) or DNS over HTTPS (DoH) to authenticate responses.
Restrict egress UDP/53 traffic so only the trusted resolver is reachable, reducing exposure to off-path spoofers.
Configure the application to use the Java Naming and Directory Interface (JNDI) or operating system resolver instead of Netty's DnsNameResolver until upgrades are deployed.

bash

# Verify the resolved Netty version in a Maven project
mvn dependency:tree -Dincludes=io.netty:netty-resolver-dns

# Verify in a Gradle project
./gradlew dependencyInsight --dependency netty-resolver-dns