CVE-2026-45673

What it actually does

Netty versions before 4.1.135.Final and 4.2.15.Final generate DNS transaction IDs with a predictable pseudo-random number generator and use a static UDP source port by default in the DNS resolver. This significantly reduces DNS query entropy and can allow an off-path attacker to win a DNS race by sending forged DNS responses that match the expected transaction ID and source port. Successful exploitation can poison DNS cache entries used by Netty-based applications, causing them to resolve legitimate hostnames to attacker-controlled IP addresses. The primary impact is integrity compromise of outbound network destinations; confidentiality or availability impact depends on what the affected application does after following the poisoned DNS response.

Why it matters to the business

Applications using vulnerable Netty DNS resolution may be redirected to malicious infrastructure without the application or user intentionally changing configuration. This can lead to service-to-service traffic interception, credential or token exposure if additional protections are weak, connection to fraudulent upstream services, supply-chain or update-channel manipulation, and operational disruption from incorrect DNS resolution. The CVSS score is moderate and exploitation complexity is high, EPSS is currently low, and it is not listed in CISA KEV; however, the issue affects a widely used Java networking framework, so exposure can be indirect through downstream products and dependencies.

How an attack unfolds

An attacker first identifies a Netty-based application that performs DNS lookups using the vulnerable resolver and determines or induces a lookup for a target hostname. Because the resolver uses a predictable transaction ID generator and a static UDP source port, the attacker has a much smaller search space than expected for spoofed DNS replies. The attacker then floods forged DNS responses for the target name, attempting to beat the legitimate authoritative DNS response. If a forged response is accepted, the resolver caches or uses the attacker-supplied address. Subsequent application connections to the affected hostname may be sent to infrastructure controlled by the attacker, enabling traffic redirection, service impersonation, data manipulation, or credential capture depending on transport protections such as TLS validation.

How to fix it

Upgrade Netty to a fixed release: 4.1.135.Final or later for the 4.1.x line, or 4.2.15.Final or later for the 4.2.x line. Because Netty is often brought in transitively, review dependency trees and ensure all packaged, shaded, vendor-bundled, or containerized copies are updated. If immediate upgrade is not possible, mitigate by using a secure external resolver path that randomizes UDP source ports and transaction IDs, avoiding vulnerable Netty DNS resolver code paths, preferring DNS over TCP/TLS through trusted resolvers where feasible, and enforcing strict TLS certificate and hostname validation for all outbound connections so DNS redirection alone cannot impersonate trusted services. Do not rely on network perimeter controls alone, because exploitation can target normal DNS behavior.

How to confirm the fix worked

Confirm the resolved Netty artifact versions in build manifests, software composition analysis results, lockfiles, runtime classpaths, container images, and packaged application archives. Verify that io.netty:netty-resolver-dns and related Netty modules are at 4.1.135.Final or later, or 4.2.15.Final or later. For Java applications, inspect dependency output such as Maven dependency:tree or Gradle dependencies and check for shaded Netty copies inside fat JARs. In staging, observe DNS queries from affected services and confirm source port randomization and non-predictable transaction behavior where applicable. Validate that outbound connections continue to enforce TLS certificate and hostname verification, and that applications do not accept redirected endpoints without authentication.

Typical attack path

1. Identify an application or service using affected Netty versions for DNS resolution.
2. Find a hostname the application resolves, or trigger the application to resolve an attacker-chosen or target hostname.
3. Predict or brute-force likely DNS transaction IDs while relying on the static UDP source port behavior.
4. Send a high volume of forged DNS responses containing attacker-controlled IP addresses before the legitimate DNS response arrives.
5. Cause the vulnerable resolver to accept and cache or use the forged DNS answer.
6. Receive redirected application traffic at attacker-controlled infrastructure and attempt service impersonation, interception, or downstream exploitation.

How to detect it

Historical exploitation is difficult to prove from application logs alone because successful DNS cache poisoning may look like a normal DNS response followed by ordinary outbound connections. Review recursive resolver logs, host DNS telemetry, packet captures, egress firewall logs, proxy logs, and application connection logs for the affected period. Look for bursts of forged or duplicate DNS responses, unusually high DNS response rates for the same query, mismatched answers from expected authoritative resolvers, sudden changes in resolved IPs for stable domains, short-lived redirections to unfamiliar autonomous systems or geographies, and application connections to IP addresses not normally associated with expected service domains. Where packet capture exists, examine whether multiple DNS replies with different answers arrived for the same transaction, especially when one response was not from the configured resolver. Also investigate downstream signs of redirection, including TLS certificate validation failures, unexpected certificate issuers, hostname mismatch errors, authentication failures after DNS resolution, and unusual outbound connections immediately after DNS lookups. No public threat actors or exploitation campaigns are currently associated with this CVE in the provided data.

What your security team should do

• Inventory applications, appliances, SDKs, and third-party products that bundle Netty, especially those using Netty DNS resolver functionality.
• Prioritize upgrades for internet-facing, multi-tenant, service-mesh, API gateway, proxy, messaging, and control-plane components that make outbound DNS lookups.
• Upgrade to Netty 4.1.135.Final or later, or 4.2.15.Final or later, and rebuild/redeploy all dependent artifacts and containers.
• Use software composition analysis to identify transitive or shaded Netty dependencies that normal package inventories may miss.
• Harden DNS resolution by using trusted recursive resolvers, response validation where available, source-port randomization, DNSSEC validation where practical, and egress controls for DNS traffic.
• Ensure all outbound service connections use strong TLS certificate and hostname validation to reduce the impact of DNS redirection.
• Monitor DNS telemetry for suspicious answer changes, spoofing patterns, repeated transaction failures, and unexpected resolution of trusted domains to unfamiliar IP space.
• Because EPSS is low and there is no known KEV listing, handle through normal vulnerability management unless the affected component resolves sensitive upstream services or sits in a high-trust network path.