Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package apache-hive version 4.2.0-r5 fixes 21 vulnerabilities: CVE-2026-44249, CVE-2026-44250, CVE-2026-44890, CVE-2026-44893, CVE-2026-45416...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "apache-hive"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0-r5"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"4.2.0-r5"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package apache-hive version 4.2.0-r5 fixes 21 vulnerabilities: CVE-2026-44249, CVE-2026-44250, CVE-2026-44890, CVE-2026-44893, CVE-2026-45416...",
"id": "CLEANSTART-2026-PX22838",
"modified": "2026-07-30T09:32:00Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://hive.apache.org/"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in apache-hive 4.2.0-r5",
"upstream": [
"CVE-2026-44249",
"CVE-2026-44250",
"CVE-2026-44890",
"CVE-2026-44893",
"CVE-2026-45416",
"CVE-2026-45536",
"CVE-2026-45673",
"CVE-2026-45674",
"CVE-2026-46340",
"CVE-2026-47691",
"ghsa-3244-j874-rhc2",
"ghsa-3qp7-7mw8-wx86",
"ghsa-5pvg-856g-cp85",
"ghsa-5x3r-wrvg-rp6q",
"ghsa-5xrh-qmmq-w6ch",
"ghsa-676x-f7gg-47vc",
"ghsa-6ghj-frrj-jjj3",
"ghsa-cc37-9q2j-3hfv",
"ghsa-w573-9ffj-6ff9",
"ghsa-x4gw-5cx5-pgmh",
"ghsa-xmv7-r254-6q78"
]
}
GHSA-3244-J874-RHC2
Vulnerability from github – Published: 2026-06-08 19:01 – Updated: 2026-06-12 19:27Summary
An attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError.
Details
io.netty.handler.codec.redis.RedisArrayAggregator aggregates RedisMessage parts into ArrayRedisMessage. It uses a Deque<AggregateState> to keep track of nested arrays. However, it does not limit the maximum depth of nested arrays. When an attacker sends a continuous stream of nested array headers (e.g., *1\r\n*1\r\n*1\r\n...), RedisArrayAggregator pushes a new AggregateState onto the stack and allocates a new ArrayList for each header. Because there is no depth limit, an attacker can send millions of such headers. This consumes a massive amount of heap memory for the AggregateState instances and their backing ArrayLists, eventually resulting in an OutOfMemoryError.
Impact
Denial of Service due to memory exhaustion. Any application using Netty's RedisArrayAggregator to handle untrusted Redis traffic is vulnerable.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44250"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:01:52Z",
"nvd_published_at": "2026-06-11T22:16:56Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError.\n\n### Details\nio.netty.handler.codec.redis.RedisArrayAggregator aggregates RedisMessage parts into ArrayRedisMessage. It uses a `Deque\u003cAggregateState\u003e` to keep track of nested arrays. However, it does not limit the maximum depth of nested arrays. When an attacker sends a continuous stream of nested array headers (e.g., `*1\\r\\n*1\\r\\n*1\\r\\n...`), RedisArrayAggregator pushes a `new AggregateState` onto the stack and allocates a `new ArrayList` for each header. Because there is no depth limit, an attacker can send millions of such headers. This consumes a massive amount of heap memory for the AggregateState instances and their backing ArrayLists, eventually resulting in an OutOfMemoryError.\n\n### Impact\nDenial of Service due to memory exhaustion. Any application using Netty\u0027s RedisArrayAggregator to handle untrusted Redis traffic is vulnerable.",
"id": "GHSA-3244-j874-rhc2",
"modified": "2026-06-12T19:27:12Z",
"published": "2026-06-08T19:01:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-3244-j874-rhc2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44250"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty: Memory Exhaustion in RedisArrayAggregator due to Deeply Nested Arrays"
}
GHSA-3QP7-7MW8-WX86
Vulnerability from github – Published: 2026-06-08 19:00 – Updated: 2026-06-12 19:27Summary
An attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.
Details
io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress) method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask.
Impact
Access Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44249"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:00:33Z",
"nvd_published_at": "2026-06-11T22:16:56Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.\n\n### Details\n`io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress)` method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask.\n\n### Impact\nAccess Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.",
"id": "GHSA-3qp7-7mw8-wx86",
"modified": "2026-06-12T19:27:07Z",
"published": "2026-06-08T19:00:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-3qp7-7mw8-wx86"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44249"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty has an IPv6 Subnet Filter Bypass via Incorrect Comparator Masking"
}
GHSA-5PVG-856G-CP85
Vulnerability from github – Published: 2026-06-08 23:02 – Updated: 2026-08-04 15:32Summary
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-resolver-dns"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-resolver-dns"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47691"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:02:48Z",
"nvd_published_at": "2026-06-12T16:16:30Z",
"severity": "HIGH"
},
"details": "### Summary\nNetty\u0027s `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`).\n\n### Details\nIn `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record\u0027s name is a suffix of the questionName.\n\nThis 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\u0027s 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..\n\nThe `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#cache` method only prevents caching if the record is for the root zone (dots == 1).\n\n### Impact\nDNS Cache Poisoning. Any application using Netty\u0027s DNS resolver is impacted.",
"id": "GHSA-5pvg-856g-cp85",
"modified": "2026-08-04T15:32:11Z",
"published": "2026-06-08T23:02:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-5pvg-856g-cp85"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47691"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-47691.json"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2488439"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-47691"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49701"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49700"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:48151"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41951"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37390"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34608"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26586"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26018"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26017"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty has Insufficient Bailiwick Validation for NS Records"
}
GHSA-5X3R-WRVG-RP6Q
Vulnerability from github – Published: 2026-06-08 23:02 – Updated: 2026-06-12 19:30Impact
DefaultHttp2Connection.DefaultEndpoint initialises maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default (Http2Settings.java:305-307 only clamps a user-supplied value). Unless the application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server advertises no limit and enforces none locally. Each open stream allocates a DefaultStream object, PropertyMap slots, flow-controller state and IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP connection can create hundreds of thousands of long-lived stream objects. This is also the precondition for CVE-2023-44487-style Rapid-Reset amplification, where the absence of a low concurrent cap multiplies backend work.
Resources
https://www.rfc-editor.org/rfc/rfc7540.html#section-6.5.2
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47244"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:02:40Z",
"nvd_published_at": "2026-06-12T15:16:29Z",
"severity": "MODERATE"
},
"details": "### Impact\nDefaultHttp2Connection.DefaultEndpoint initialises maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default (Http2Settings.java:305-307 only clamps a user-supplied value). Unless the application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server advertises no limit and enforces none locally. Each open stream allocates a DefaultStream object, PropertyMap slots, flow-controller state and IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP connection can create hundreds of thousands of long-lived stream objects. This is also the precondition for CVE-2023-44487-style Rapid-Reset amplification, where the absence of a low concurrent cap multiplies backend work.\n\n### Resources\nhttps://www.rfc-editor.org/rfc/rfc7540.html#section-6.5.2",
"id": "GHSA-5x3r-wrvg-rp6q",
"modified": "2026-06-12T19:30:17Z",
"published": "2026-06-08T23:02:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-5x3r-wrvg-rp6q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47244"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Netty HTTP/2: Advertised MAX_CONCURRENT_STREAMS are not enforced"
}
GHSA-5XRH-QMMQ-W6CH
Vulnerability from github – Published: 2026-06-08 23:02 – Updated: 2026-06-12 19:29For each non-complete SctpMessage fragment the handler does fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf)), wrapping the previous accumulator and the new slice into a new CompositeByteBuf every time. After N fragments the accumulator is an N-deep chain of composites, each holding references and component arrays; readableBytes()/getBytes() on the final buffer recurse N levels. There is no limit on N, on total bytes, or on the number of streamIdentifiers an attacker can open (each gets its own map entry). A peer that never sets the complete flag can grow this structure indefinitely from tiny 1-byte DATA chunks.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-sctp"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-sctp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46340"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:02:33Z",
"nvd_published_at": "2026-06-12T15:16:27Z",
"severity": "HIGH"
},
"details": "For each non-complete SctpMessage fragment the handler does `fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))`, wrapping the previous accumulator and the new slice into a *new* CompositeByteBuf every time. After N fragments the accumulator is an N-deep chain of composites, each holding references and component arrays; readableBytes()/getBytes() on the final buffer recurse N levels. There is no limit on N, on total bytes, or on the number of streamIdentifiers an attacker can open (each gets its own map entry). A peer that never sets the `complete` flag can grow this structure indefinitely from tiny 1-byte DATA chunks.",
"id": "GHSA-5xrh-qmmq-w6ch",
"modified": "2026-06-12T19:29:38Z",
"published": "2026-06-08T23:02:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-5xrh-qmmq-w6ch"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46340"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty: SCTP reassembly nests buffers without bound"
}
GHSA-676X-F7GG-47VC
Vulnerability from github – Published: 2026-06-08 23:02 – Updated: 2026-08-04 15:32Summary
Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses.
Details
In io.netty.resolver.dns.DnsResolveContext#buildAliasMap, the resolver processes the ANSWER section of a DNS response and blindly caches all CNAME records it finds.
According to https://datatracker.ietf.org/doc/html/rfc5452#section-6
Care must be taken to only accept
data if it is known that the originator is authoritative for the
QNAME or a parent of the QNAME.
One very simple way to achieve this is to only accept data if it is
part of the domain for which the query was intended.
Impact
DNS Cache Poisoning (Bailiwick Bypass). Any application using Netty's DNS resolver is impacted.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-resolver-dns"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-resolver-dns"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45674"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:02:26Z",
"nvd_published_at": "2026-06-12T15:16:27Z",
"severity": "HIGH"
},
"details": "### Summary\nNetty\u0027s DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses.\n\n### Details\nIn `io.netty.resolver.dns.DnsResolveContext#buildAliasMap`, the resolver processes the ANSWER section of a DNS response and blindly caches all CNAME records it finds.\n\nAccording to https://datatracker.ietf.org/doc/html/rfc5452#section-6 \n\n```\nCare must be taken to only accept\n data if it is known that the originator is authoritative for the\n QNAME or a parent of the QNAME.\n One very simple way to achieve this is to only accept data if it is\n part of the domain for which the query was intended.\n```\n\n### Impact\nDNS Cache Poisoning (Bailiwick Bypass). Any application using Netty\u0027s DNS resolver is impacted.",
"id": "GHSA-676x-f7gg-47vc",
"modified": "2026-08-04T15:32:10Z",
"published": "2026-06-08T23:02:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-676x-f7gg-47vc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45674"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45674.json"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2488400"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-45674"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49701"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49700"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:48151"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41951"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37390"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34608"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26586"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26018"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26017"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty Vulnerable to DNS Cache Poisoning via Missing Bailiwick Checks in CNAME Records"
}
GHSA-6GHJ-FRRJ-JJJ3
Vulnerability from github – Published: 2026-06-08 19:02 – Updated: 2026-06-12 19:27Summary
An attacker can cause DoS by sending crafted Redis payloads across multiple connections without \r\n. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed.
Details
io.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the decodeLength method. This method reads bytes from the network until it encounters a \n character. However, it does not enforce any maximum length check while buffering the bytes if the \n character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., $1111...) without ever sending a \n.
To cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them.
According to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with \r\n. Furthermore, the length prefix itself is an integer representation that must fit within standard numeric limits (e.g., a 64-bit signed integer). Therefore, a stream of digits exceeding these bounds without \r\n is a protocol violation and should be rejected immediately rather than buffered indefinitely.
Impact
Denial of Service due to memory exhaustion. Any application using Netty's RedisDecoder to handle untrusted Redis traffic is vulnerable.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-redis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44890"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:02:09Z",
"nvd_published_at": "2026-06-11T22:16:56Z",
"severity": "HIGH"
},
"details": "### Summary\nAn attacker can cause DoS by sending crafted Redis payloads across multiple connections without `\\r\\n`. This exhausts the server\u0027s direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed.\n\n### Details\nio.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the `decodeLength` method. This method reads bytes from the network until it encounters a `\\n` character. However, it does not enforce any maximum length check while buffering the bytes if the `\\n` character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., `$1111...`) without ever sending a `\\n`.\n\nTo cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them.\n\nAccording to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with `\\r\\n`. Furthermore, the length prefix itself is an integer representation that must fit within standard numeric limits (e.g., a 64-bit signed integer). Therefore, a stream of digits exceeding these bounds without `\\r\\n` is a protocol violation and should be rejected immediately rather than buffered indefinitely.\n\n### Impact\nDenial of Service due to memory exhaustion. Any application using Netty\u0027s RedisDecoder to handle untrusted Redis traffic is vulnerable.",
"id": "GHSA-6ghj-frrj-jjj3",
"modified": "2026-06-12T19:27:16Z",
"published": "2026-06-08T19:02:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-6ghj-frrj-jjj3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44890"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty has Unbounded Direct Memory Consumption in its RedisDecoder"
}
GHSA-CC37-9Q2J-3HFV
Vulnerability from github – Published: 2026-06-08 19:02 – Updated: 2026-06-12 19:29When decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls header.retainedSlice(header.readerIndex(), length) and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-haproxy"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-haproxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44893"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T19:02:21Z",
"nvd_published_at": "2026-06-12T15:16:26Z",
"severity": "HIGH"
},
"details": "When decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls `header.retainedSlice(header.readerIndex(), length)` and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released.",
"id": "GHSA-cc37-9q2j-3hfv",
"modified": "2026-06-12T19:29:14Z",
"published": "2026-06-08T19:02:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-cc37-9q2j-3hfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44893"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty: HAProxy SSL TLV parsing leaks retained slice on invalid TLV length"
}
GHSA-W573-9FFJ-6FF9
Vulnerability from github – Published: 2026-06-08 23:01 – Updated: 2026-06-12 19:29netty_unix_socket_recvFd sets msg_control to char control[CMSG_SPACE(sizeof(int))] (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check cmsg->cmsg_len == CMSG_LEN(sizeof(int)) (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-epoll"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-kqueue"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-kqueue"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-transport-native-epoll"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45536"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-772"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:01:33Z",
"nvd_published_at": "2026-06-12T15:16:27Z",
"severity": "MODERATE"
},
"details": "netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) \u2014 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg-\u003ecmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking \u2192 EAGAIN \u2192 Java maps to 0 \u2192 read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).",
"id": "GHSA-w573-9ffj-6ff9",
"modified": "2026-06-12T19:29:26Z",
"published": "2026-06-08T23:01:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-w573-9ffj-6ff9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45536"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Netty: Unix-socket fd receive leaks descriptors when peer sends two at once"
}
GHSA-X4GW-5CX5-PGMH
Vulnerability from github – Published: 2026-06-08 23:01 – Updated: 2026-06-12 19:29SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates ctx.alloc().buffer(handshakeLength) (line 161). The guard at line 140 is handshakeLength > maxClientHelloLength && maxClientHelloLength != 0, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.14.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45416"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:01:04Z",
"nvd_published_at": "2026-06-12T15:16:26Z",
"severity": "HIGH"
},
"details": "SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength \u003e maxClientHelloLength \u0026\u0026 maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.",
"id": "GHSA-x4gw-5cx5-pgmh",
"modified": "2026-06-12T19:29:22Z",
"published": "2026-06-08T23:01:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-x4gw-5cx5-pgmh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45416"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty: SNI handler pre-allocates up to 16 MiB from nine attacker bytes"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.