CVE-2026-55831 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in io.netty:netty-codec-http. A fix is available for io.netty:netty-codec-http — see the affected versions and patch details below.
Netty SPDY SETTINGS frame count materializes unbounded settings map
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-55831.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-55831 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 391,411 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
io.netty:netty-codec-http☕io.netty:netty-codec-httpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Netty's SPDY SETTINGS decoder accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in DefaultSpdySettingsFrame without an implementation-level count cap. A remote SPDY/3.1 peer can send one syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries, amplifying network input into heap growth and ordered-map insertion work.
Details
Inbound SPDY bytes enter SpdyFrameCodec.decode() and are passed directly to the frame decoder. The decoder reads the peer-controlled flags and 24-bit frame length from the common header, then accepts SETTINGS frames with only length >= 4. For SETTINGS payloads, it reads the peer-controlled numSettings field and validates only that the remaining payload is divisible into 8-byte entries and exactly matches that count. Each accepted entry then supplies an attacker-controlled 24-bit ID and value, and the normal delegate path forwards it into spdySettingsFrame.setValue(). The sink is DefaultSpdySettingsFrame: it backs settings with a TreeMap, checks only that IDs fit the SPDY 24-bit maximum, and inserts a new Setting for each previously unseen ID. There is no count budget between the wire-format count validation and the TreeMap insertion site.
PoC
run with
bash ./poc/run.sh
expected output:
NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED settings_count=262144 wire_bytes=2097164 approx_heap_delta=17692272 first_value=1 last_value=262144
The NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED line means the harness decoded the crafted SETTINGS frame and observed all 262144 peer-selected IDs in the resulting settings map. The wire_bytes=2097164, first_value=1, and last_value=262144 fields distinguish this from a setup failure: they show the exact oversized frame was accepted and fully materialized.
Impact
remote unauthenticated network peer that can speak SPDY/3.1 to a Netty pipeline containing SpdyFrameCodec can trigger resource-exhaustion denial of service. The required guards are satisfied by a complete valid SETTINGS frame using the expected SPDY version, a length of 4 + numSettings * 8, and IDs within the accepted 24-bit range; the verified PoC uses numSettings=262144 and wire_bytes=2097164. On that input, Netty materializes 262144 attacker-controlled entries in a TreeMap-backed DefaultSpdySettingsFrame, with local runs observing about 17-18 MiB of heap growth per decoded frame plus CPU work for ordered-map insertion.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.netty:netty-codec-http | ≥ 4.2.0.Final&&< 4.2.16.Final | 4.2.16.Finalio.netty:netty-codec-http:4.2.16.Final |
| ☕Maven | io.netty:netty-codec-http | ≥ 4.1.0.Final&&< 4.1.136.Final | 4.1.136.Finalio.netty:netty-codec-http:4.1.136.Final |
Affected Products
nettynettyDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-http, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update io.netty:netty-codec-http to 4.2.16.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-55831 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This is an Important denial of service flaw in Netty's SPDY SETTINGS decoder, allowing a remote unauthenticated attacker to exhaust system resources. By sending a specially crafted SPDY/3.1 SETTINGS frame, an attacker can cause excessive memory allocation and CPU usage, leading to a denial of service. This…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for CVE-2026-55831 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Cryostat 4 on RHEL 9 | cryostat/cryostat-reports-rhel9:4.2.0-14 | RHSA-2026:68333 |
| Red Hat AMQ Broker 7.13.6 | netty-codec-http | RHSA-2026:66545 |
| Red Hat AMQ Broker 7.14.1 | netty-codec-http | RHSA-2026:66488 |
| Red Hat Build of Apache Camel 3.33.2.SP3 | io.netty/netty-codec-http:4.1.136.Final-redhat-00001 | RHSA-2026:48118 |
| Red Hat build of Apache Camel 4.18.3 for Spring Boot 3.5.16 | netty-codec-http | RHSA-2026:54622 |
| Red Hat build of Apicurio Registry 3.3.3 | netty-codec-http | RHSA-2026:76637 |
| Red Hat build of Quarkus 3.27.4.SP3 | netty-codec-http | RHSA-2026:47189 |
| Red Hat build of Quarkus 3.33.2.SP3 | netty-codec-http | RHSA-2026:47172 |
Frequently Asked Questions
Is CVE-2026-55831 in your dependencies?
Find it across Maven, including transitive dependencies.