Netty decoder CVEs: what Java teams need to check now

TL;DR: Three Netty CVEs show how protocol decoders can turn syntactically valid input into denial-of-service conditions through unbounded STOMP headers and SPDY resource growth, according to Corgea. The lesson for application and platform teams is that module reachability and runtime limits matter as much as version numbers when transport plumbing is exposed.

NHIMG editorial — based on content published by Corgea: the Netty decoder CVE analysis covering STOMP and SPDY resource exhaustion

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Questions worth separating out

Q: What breaks when protocol decoders allow attacker-controlled resource growth?

A: When decoders trust input cardinality or keep processing after a size limit is crossed, a small payload can expand into large heap allocations or heavy CPU work.

Q: Why do transitive Java dependencies create hidden availability risk?

A: Because a framework can expose reachable protocol handlers even when the application never imports them directly.

Q: How do security teams know whether a vulnerable decoder is actually exposed?

A: Check the running dependency tree, inspect protocol pipelines, and trace whether the decoder class is instantiated in reachable code paths.

Practitioner guidance

• Map reachable decoder paths in runtime dependencies Inspect the deployed dependency tree, not just source manifests, and identify whether StompSubframeDecoder or SpdyFrameCodec can be reached in live services.
• Enforce aggregate input ceilings in protocol handlers Add limits for total header count, cumulative header bytes, and SETTINGS entry cardinality so the decoder cannot keep allocating after a syntactic check passes.
• Treat oversize decode events as hard stops Ensure that truncated or over-limit frames terminate processing immediately, rather than continuing zlib inflate or map insertion work.

What's in the full report

Corgea's full article covers the operational detail this post intentionally leaves for the source:

• The exact CVE-to-module mapping for the affected Netty packages and fixed versions.
• The proof-of-concept fingerprints showing how the STOMP and SPDY decoders are driven into resource exhaustion.
• Dependency-tree and ripgrep commands for locating reachable classes in Maven and Gradle builds.
• The article's remediation sequence for patching, disabling unused SPDY support, and prioritising externally reachable services.

👉 Read Corgea's analysis of the Netty decoder CVEs and affected Java modules →

Netty decoder CVEs: what Java teams need to check now?

Explore further

View Full Forum →  |  NHI Foundation Course →