CVE-2026-45674: Netty SSRF Vulnerability

CVE-2026-45674 Overview

Netty is a network application framework used to build protocol servers and clients in Java. A flaw in the DnsResolveContext component allows attackers to abuse missing bailiwick validation on Canonical Name (CNAME) records in Domain Name System (DNS) responses. The framework accepts CNAME records that originate outside the authority of the queried domain, enabling DNS cache poisoning and response redirection. The issue affects all releases prior to 4.1.135.Final and 4.2.15.Final. The flaw is categorized under [CWE-345] (Insufficient Verification of Data Authenticity).

Critical Impact
Remote attackers can inject forged CNAME records into Netty's DNS resolver, redirecting application traffic to attacker-controlled hosts without authentication or user interaction.

Affected Products

Netty netty versions prior to 4.1.135.Final (4.1.x branch)
Netty netty versions prior to 4.2.15.Final (4.2.x branch)
Any Java application or service embedding the vulnerable netty-resolver-dns module

Discovery Timeline

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

Technical Details for CVE-2026-45674

Vulnerability Analysis

The vulnerability resides in Netty's asynchronous DNS resolver, specifically the DnsResolveContext class within the netty-resolver-dns module. When the resolver receives a DNS response containing CNAME records, it follows the alias chain to obtain the final A or AAAA records. The resolver fails to verify that each CNAME record falls within the bailiwick — the authoritative zone — of the server that returned it.

A bailiwick check ensures that a nameserver only supplies records for domains it is authoritative for. Without this check, an attacker controlling or impersonating an upstream DNS server can return CNAME records pointing to arbitrary domains. The Netty resolver then follows these forged aliases as if they were legitimate.

This weakness enables off-path and on-path attackers to redirect outbound connections initiated by any Netty-based client, including HTTP clients, gRPC stubs, database drivers, and reactive frameworks built on Netty.

Root Cause

The root cause is missing input validation on DNS response data. DnsResolveContext processes CNAME answers without comparing the record owner name against the original query name or against the delegation chain of the responding nameserver. Trusted-by-default handling of upstream responses violates the principle of validating data authenticity prescribed by [CWE-345].

Attack Vector

The attack is performed over the network and requires no privileges or user interaction. An attacker positioned to respond to DNS queries — through a rogue resolver, DNS spoofing on shared networks, or compromise of an authoritative server in the resolution chain — returns a crafted response containing a CNAME record pointing the queried host to an attacker-controlled domain. Netty follows the alias and resolves the attacker's chosen address. Subsequent application traffic, including TLS sessions if certificate validation is misconfigured or hostnames are reused, may flow to the attacker.

The vulnerability mechanism is described in the GitHub Security Advisory GHSA-676x-f7gg-47vc. No public proof-of-concept exploit has been published at the time of writing.

Detection Methods for CVE-2026-45674

Indicators of Compromise

DNS responses containing CNAME records whose owner name differs from the queried label and whose target lies outside the responding server's authoritative zone.
Unexpected outbound connections from Java services to hosts that do not appear in application allowlists or service discovery configuration.
Java process dependency listings showing netty-resolver-dns at versions below 4.1.135.Final or 4.2.15.Final.

Detection Strategies

Inventory Java applications and container images for io.netty:netty-resolver-dns artifacts using software composition analysis tooling and flag versions earlier than the fixed releases.
Capture DNS traffic from application hosts and inspect responses for out-of-bailiwick CNAME chains using a passive DNS analyzer or IDS rule set.
Correlate DNS resolution events with subsequent TCP/TLS connection telemetry to identify resolution-to-connection mismatches.

Monitoring Recommendations

Forward DNS query and response logs from internal resolvers and host-level capture to a centralized analytics platform for bailiwick anomaly detection.
Alert on Java process command lines that load vulnerable netty-resolver-dns JAR paths after patch deadlines.
Monitor egress connections from application servers for new or low-reputation destinations following CNAME resolutions.

How to Mitigate CVE-2026-45674

Immediate Actions Required

Upgrade all instances of Netty to 4.1.135.Final or 4.2.15.Final or later, matching your existing 4.1.x or 4.2.x branch.
Rebuild and redeploy container images and uber-JARs that bundle Netty, including transitive dependencies pulled in by frameworks such as Reactor Netty, gRPC-Java, Vert.x, and Elasticsearch clients.
Restrict outbound DNS to trusted, validating resolvers and block direct UDP/53 egress from application subnets.

Patch Information

Netty maintainers released fixes in netty-4.1.135.Final and netty-4.2.15.Final. Both releases add bailiwick validation in DnsResolveContext so that CNAME records originating outside the queried zone are rejected. Full remediation details are available in the GitHub Security Advisory GHSA-676x-f7gg-47vc.

Workarounds

Configure Netty-based applications to use the JDK default resolver (DefaultAddressResolverGroup) instead of DnsAddressResolverGroup until the upgrade is applied.
Route all DNS lookups through a hardened recursive resolver that enforces bailiwick checks and DNSSEC validation, reducing exposure to forged upstream responses.
Enforce strict TLS hostname verification and certificate pinning on outbound connections to limit impact when resolution is redirected.

bash

# Configuration example: pin Netty to a fixed version via Maven dependency management
# pom.xml fragment
# <dependencyManagement>
#   <dependencies>
#     <dependency>
#       <groupId>io.netty</groupId>
#       <artifactId>netty-bom</artifactId>
#       <version>4.1.135.Final</version>
#       <type>pom</type>
#       <scope>import</scope>
#     </dependency>
#   </dependencies>
# </dependencyManagement>

# Verify resolved Netty versions in a built project
mvn dependency:tree -Dincludes=io.netty:netty-resolver-dns

# Gradle equivalent
./gradlew dependencyInsight --dependency netty-resolver-dns