Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final,…
GitHub_M·CWE-345·Published 2026-06-08
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
### Summary Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). ### Details In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. This means if the resolver queries evil.co.uk., it will accept an NS record claiming authority over co.uk.. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key (co.uk.). This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under co.uk.. The `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#cache` method only prevents caching if the record is for the root zone (dots == 1). ### Impact DNS Cache Poisoning. Any application using Netty's DNS resolver is impacted.
### Summary Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). ### Details In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. This means if the resolver queries evil.co.uk., it will accept an NS record claiming authority over co.uk.. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key (co.uk.). This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under co.uk.. The `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#cache` method only prevents caching if the record is for the root zone (dots == 1). ### Impact DNS Cache Poisoning. Any application using Netty's DNS resolver is impacted.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 3.1 | Primary | NVD | 10.0 | 3.9 | 5.8 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Primary | cve.org | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Secondary | NVD | 8.7 | 2.2 | 5.8 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Secondary | NVD | 8.7 | 2.2 | 5.8 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Secondary | ENISA EUVD | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |
| 3.1 | Secondary | GHSA | 8.7 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N |