Skip to main content

Netty HTTP codec CVE-2026-42587

HIGH
Uncontrolled Resource Consumption (CWE-400)
2026-05-07 https://github.com/netty/netty GHSA-f6hv-jmp6-3vwv
Denial Of Service Python Java
7.5
CVSS 3.1 · Vendor: https://github.com/netty/netty
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Send HTTP POST with Content-Encoding: br header
  2. Delivery
    Netty routes to BrotliDecoder bypassing maxAllocation
  3. Exploit
    Decompressor expands compressed bomb payload
  4. Execution
    Heap memory exhaustion
  5. Persist
    OutOfMemoryError triggers JVM crash or GC thrashing
  6. Impact
    Service becomes unavailable

Vulnerability Assessment

Weakness
CWE
CWE-400
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK

1 technique across 1 tactic: Impact

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Sign in to read
Exploitation Conditions

Exploitation requires the target Netty server to enable HTTP content decompression via HttpContentDecompressor (HTTP/1.1) or DelegatingDecompressorFrameListener (HTTP/2), which is common for APIs and reverse proxies handling client-submitted data. The server must support at least one of the affected encodings: brotli (br), zstd, or snappy, which are enabled by default in Netty when the corresponding codec libraries (netty-codec-compression-brotli, netty-codec-compression-zstd, or built-in snappy support) are present on the classpath. No authentication or special permissions are required (PR:N). No user interaction is needed (UI:N). The attack works against default configurations and does not require the server to be in any special mode. Exploitation succeeds as long as the decompressed output can exhaust available heap memory before Netty's other resource limits (e.g., HttpObjectAggregator maxContentLength) trigger, which depends on configured JVM heap size and concurrent request load. The vulnerability is NOT exploitable if the server application explicitly validates Content-Encoding headers and rejects brotli/zstd/snappy, or if decompression is disabled entirely. Attack complexity is low (AC:L) because the attacker only needs to craft a Content-Encoding header and compressed payload, both trivial operations with standard tools.
Impact

Real-world risk is HIGH despite moderate CVSS base score of 7.5. The CVSS vector AV:N/AC:L/PR:N/UI:N indicates trivial remote exploitation with no authentication, user interaction, or complex preconditions. Attack complexity is genuinely low - exploitation requires only swapping a single HTTP header value from 'gzip' to 'br', making this easier to exploit than most high-severity vulnerabilities. The vulnerability affects a critical availability protection mechanism specifically designed to prevent resource exhaustion attacks, creating a false sense of security for developers who explicitly configured maxAllocation believing all encodings were protected. EPSS and KEV data not provided, but public proof-of-concept exists per GitHub advisory, significantly lowering exploitation barrier. The impact is limited to availability (C:N/I:N/A:H) but can cause complete service disruption via out-of-memory crashes. SSVC technical impact is high (service unavailability), automatable (simple HTTP request modification), and while not yet confirmed exploited in the wild, the low barrier makes weaponization highly likely. Key risk amplifier: this is a protection bypass rather than a novel bug class, meaning defenders who implemented maxAllocation controls are unknowingly vulnerable. Mitigation priority should be IMMEDIATE for any Netty-based HTTP service handling untrusted compressed content, especially public-facing APIs and proxies.
Exploit ScenarioDerived

An attacker identifies a public-facing Netty-based API server (e.g., a microservices gateway or REST API) that accepts compressed POST requests. The defender has configured HttpContentDecompressor with maxAllocation=1048576 (1MB) believing this protects against decompression bombs. The attacker generates a brotli-compressed payload using 1KB of compressed data that expands to 1GB when decompressed, using high compression ratio techniques (e.g., long runs of zeros). The attacker sends a POST request with 'Content-Encoding: br' and the malicious payload. Netty's HttpContentDecompressor routes the request to BrotliDecoder, which ignores maxAllocation and decompresses the full 1GB into heap memory, causing an OutOfMemoryError and crashing the server process or triggering JVM garbage collection storms that render the service unresponsive.
This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 07, 2026

Decompression bomb protection bypass in Netty's HttpContentDecompressor and DelegatingDecompressorFrameListener allows remote unauthenticated attackers to trigger out-of-memory denial of service by switching Content-Encoding from gzip to brotli, zstd, or snappy. The configured maxAllocation parameter correctly limits gzip/deflate decompression but is silently ignored for these alternative encodings, enabling attackers to decompress gigabytes of data from kilobyte-sized payloads. Affects both HTTP/1.1 (netty-codec-http) and HTTP/2 (netty-codec-http2) implementations. CVSS 7.5 (High) with network vector, low complexity, and no authentication required. Vendor-released patches available: versions 4.1.133.Final and 4.2.13.Final. No active exploitation confirmed at time of analysis, but publicly disclosed proof-of-concept demonstrates trivial header-based bypass requiring only changing 'Content-Encoding: gzip' to 'Content-Encoding: br'.

RemediationAI

Upgrade to Netty 4.1.133.Final (for 4.1.x users) or 4.2.13.Final (for 4.2.x users) as documented in GitHub Security Advisory GHSA-f6hv-jmp6-3vwv (https://github.com/netty/netty/security/advisories/GHSA-f6hv-jmp6-3vwv). The patches modify HttpContentDecompressor and DelegatingDecompressorFrameListener to pass the maxAllocation parameter to all decoder constructors including BrotliDecoder, ZstdDecoder, and SnappyFrameDecoder, ensuring consistent enforcement across all supported content encodings. If immediate upgrade is not feasible, implement explicit Content-Encoding allowlisting at the application layer to reject brotli, zstd, and snappy encodings, forcing clients to use gzip/deflate where maxAllocation protection is effective. This workaround can be implemented via custom ChannelHandler that inspects Content-Encoding headers before HttpContentDecompressor processes them. Trade-off: rejecting modern compression algorithms may reduce bandwidth efficiency and break clients that only support brotli. Alternative compensating control: deploy memory limits at container/JVM level (e.g., -Xmx with aggressive monitoring) to constrain blast radius of OOM conditions, though this provides crash containment rather than prevention and may cause legitimate request failures. For HTTP/2 deployments, also review settings for SETTINGS_MAX_FRAME_SIZE and stream concurrency limits as defense-in-depth against resource exhaustion, though these do not directly mitigate the decompression bomb scenario.

Affected Packages

maven io.netty:netty-codec-http fix: 4.1.133.Final, 4.2.13.Final
maven io.netty:netty-codec-http2 fix: 4.1.133.Final, 4.2.13.Final

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in maven

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Sign in to check
Technical ContextAI · show details

Netty is an asynchronous event-driven network application framework for Java, widely used for building high-performance HTTP/1.1 and HTTP/2 servers. The HttpContentDecompressor class provides transparent HTTP content decompression by inserting decoder handlers into the Netty pipeline based on the Content-Encoding header. The maxAllocation constructor parameter is intended as a defense against decompression bombs (CWE-400: Uncontrolled Resource Consumption) by capping buffer expansion during decompression. For gzip and deflate encodings, this limit is enforced via ZlibCodecFactory.newZlibDecoder(), which passes maxAllocation to ZlibDecoder's buffer allocation logic. However, for brotli, zstd, and snappy encodings, the respective decoders (BrotliDecoder, ZstdDecoder, SnappyFrameDecoder) are instantiated with no-argument constructors, completely bypassing the configured limit. BrotliDecoder lacks any maxAllocation parameter in its API, while ZstdDecoder's default 4MB limit applies per-buffer rather than total output, allowing unbounded accumulation across multiple decode iterations. The same architectural flaw exists in DelegatingDecompressorFrameListener for HTTP/2 DATA frames. Affected CPE packages are pkg:maven/io.netty:netty-codec-http and pkg:maven/io.netty:netty-codec-http2.

Know when Java gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources
Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/netty/netty) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
SUSE HIGH
Red Hat 7.5 HIGH

Primary rating from Vendor (https://github.com/netty/netty).

CVSS VectorVendor: https://github.com/netty/netty

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

DescriptionCVE.org

Summary

HttpContentDecompressor accepts a maxAllocation parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via ZlibDecoder, but is silently ignored when the content encoding is br (Brotli), zstd, or snappy. An attacker can bypass the configured decompression limit by sending a compressed payload with Content-Encoding: br instead of Content-Encoding: gzip, causing unbounded memory allocation and out-of-memory denial of service.

The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections.

Details

HttpContentDecompressor stores the maxAllocation value at construction time (HttpContentDecompressor.java:89) and uses it in newContentDecoder() to create the appropriate decompression handler.

For gzip/deflate, maxAllocation is forwarded to ZlibCodecFactory.newZlibDecoder():

java
// HttpContentDecompressor.java:101 - maxAllocation IS enforced
.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))

ZlibDecoder.prepareDecompressBuffer() enforces this as a hard cap by setting the buffer's maxCapacity and throwing DecompressionException when the limit is reached:

java
// ZlibDecoder.java:68 - hard limit on buffer capacity
return ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);
// ZlibDecoder.java:80 - throws when exceeded
throw new DecompressionException("Decompression buffer has reached maximum size: " + buffer.maxCapacity());

For brotli, zstd, and snappy, the decoders are created without any size limit:

java
// HttpContentDecompressor.java:120 - maxAllocation IGNORED
.handlers(new BrotliDecoder())

// HttpContentDecompressor.java:129 - maxAllocation IGNORED
.handlers(new SnappyFrameDecoder())

// HttpContentDecompressor.java:138 - maxAllocation IGNORED
.handlers(new ZstdDecoder())

BrotliDecoder has no maxAllocation parameter at all - there is no way to constrain its output. It streams decompressed data in chunks via fireChannelRead with no total limit.

ZstdDecoder() defaults to a 4MB maximumAllocationSize, but this only constrains individual buffer allocations, not total output. The decode loop (ZstdDecoder.java:100-114) creates new buffers and fires channelRead repeatedly, so total decompressed output is unbounded.

The identical pattern exists in DelegatingDecompressorFrameListener.newContentDecompressor() at lines 188-210 for HTTP/2.

PoC

  1. Configure a Netty HTTP server with decompression bomb protection:
java
pipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max
pipeline.addLast(new HttpObjectAggregator(1048576));     // 1MB max
  1. Generate a brotli-compressed bomb (~1KB compressed → 1GB decompressed):
python
import brotli
bomb = b'\x00' * (1024 * 1024 * 1024)
# 1GB of zeros
compressed = brotli.compress(bomb, quality=11)
with open('bomb.br', 'wb') as f:
    f.write(compressed)
# compressed size: ~1KB
  1. Send the bomb with gzip encoding (BLOCKED by maxAllocation):
bash
# This is caught - ZlibDecoder enforces the 1MB limit
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: gzip' \
  --data-binary @bomb.gz
# Result: DecompressionException thrown at 1MB
  1. Send the same bomb with brotli encoding (BYPASSES maxAllocation):
bash
# This bypasses the limit - BrotliDecoder has no maxAllocation
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: br' \
  --data-binary @bomb.br
# Result: Full 1GB decompressed into memory → OOM
  1. The same bypass works with Content-Encoding: zstd and Content-Encoding: snappy.

Impact

  • Denial of Service: An attacker can cause out-of-memory conditions on any Netty server that relies on maxAllocation for decompression bomb protection, by simply using a non-gzip content encoding.
  • False sense of security: Developers who explicitly configure maxAllocation to protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered.
  • Trivial bypass: The attacker only needs to change one HTTP header (Content-Encoding: br instead of Content-Encoding: gzip) to circumvent the protection entirely.
  • Both HTTP/1.1 and HTTP/2: The vulnerability exists in both HttpContentDecompressor (HTTP/1.1) and DelegatingDecompressorFrameListener (HTTP/2).

Recommended Fix

Pass maxAllocation to all decoder constructors. For BrotliDecoder, which currently has no maxAllocation support, add the parameter:

HttpContentDecompressor.java - pass maxAllocation to all decoders:

java
// Line 120: BrotliDecoder - add maxAllocation support
.handlers(new BrotliDecoder(maxAllocation))

// Line 129: SnappyFrameDecoder - add maxAllocation support
.handlers(new SnappyFrameDecoder(maxAllocation))

// Line 138: ZstdDecoder - forward the configured maxAllocation
.handlers(new ZstdDecoder(maxAllocation))

DelegatingDecompressorFrameListener.java - same fix at lines 188-210.

BrotliDecoder - add maxAllocation parameter with the same semantics as ZlibDecoder.prepareDecompressBuffer(): set buffer maxCapacity and throw DecompressionException when the total decompressed output exceeds the limit.

SnappyFrameDecoder - add maxAllocation parameter with equivalent enforcement.

ZstdDecoder - ensure that when maxAllocation is set, total output across all buffers is bounded (not just per-buffer allocation size).

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 11 maven packages depend on io.netty:netty-codec-http (11 direct, 0 indirect)
  • 5 maven packages depend on io.netty:netty-codec-http2 (5 direct, 0 indirect)

Ecosystem-wide dependent count for version 4.2.0.Alpha1 and other introduced versions.

Executive ViewAI

Why It Matters

Netty versions prior to 4.1.133.Final and 4.2.13.Final contain a decompression bomb protection bypass that allows remote attackers to exhaust server memory through specially crafted HTTP requests, potentially causing denial of service for any application using affected Netty HTTP codec libraries. Organizations running Netty-based services face immediate risk of service disruption without patching, as the vulnerability requires no authentication and can be triggered by simple header manipulation.

Business Impact: High
Compensating Controls

Apply vendor patch. If immediate patching is not possible, implement reverse proxy or load balancer request filtering to reject or limit Content-Encoding headers for alternative compression formats (brotli, zstd, snappy) and enforce strict Content-Length validation; however, patching is the required remediation.

Threat Intelligence Overview

EPSS Score
0.0%
Top 88% exploitable
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High
NVD CVE.org EPSS GHSA Vendor GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service MEDIUM

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

Affected Products (CPE)CVE.org

pkg:maven/io.netty:netty-codec-http
pkg:maven/io.netty:netty-codec-http2
pkg:maven/io.netty:netty-codec-http
pkg:maven/io.netty:netty-codec-http2

Related Vulnerabilities in Netty HTTP Codec Vulnerabilities

View all 10
CVE-2026-42582 HIGH
7.5
CVE-2026-42584 CRITICAL
9.1
CVE-2026-42583 HIGH
7.5
CVE-2026-42585 HIGH
7.5
CVE-2026-42579 CRITICAL
9.1
CVE-2026-42580 MEDIUM
6.5
CVE-2026-42578 LOW
2.9
CVE-2026-42581 CRITICAL
9.8
CVE-2026-42586 HIGH
7.1

More in Java

View all
CVE-2012-4681 CRITICAL POC
9.8 Aug 28

Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
CVE-2015-7450 CRITICAL POC
9.8 Jan 02

Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
CVE-2013-2465 CRITICAL POC
9.8 Jun 18

Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
CVE-2011-3544 CRITICAL POC
9.8 Oct 19

Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
CVE-2010-1871 HIGH POC
8.8 Aug 05

JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
CVE-2012-1723 CRITICAL POC
9.8 Jun 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
CVE-2013-0422 CRITICAL POC
9.8 Jan 10

Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
CVE-2012-0507 CRITICAL POC
9.8 Jun 07

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
CVE-2015-4852 CRITICAL POC
9.8 Nov 18

The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers

CVE-2012-5076 CRITICAL POC
9.8 Oct 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
CVE-2017-3066 CRITICAL POC
9.8 Apr 27

Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
CVE-2012-0391 CRITICAL POC
9.8 Jan 08

The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during

Same weakness CWE-400 – Uncontrolled Resource Consumption

View all
CVE-2023-44487 HIGH POC
7.5
CVE-2021-21341 HIGH POC
7.5
CVE-2022-29885 HIGH POC
7.5
CVE-2026-45498 HIGH POC
7.5
CVE-2016-8610 HIGH
7.5
CVE-2026-28318 HIGH POC
7.5
CVE-2023-38180 HIGH
7.5
CVE-2025-26673 HIGH
7.5

Same technique Denial Of Service

View all
CVE-2015-5119 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2011-0611 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8
CVE-2014-1761 HIGH POC
7.8
CVE-2015-5122 CRITICAL POC
9.8
CVE-2011-0609 HIGH POC
7.8

Vendor StatusVendor

SUSE

Severity: High
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise High Performance Computing 15 SP4-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS Affected

References

Advisories & patches
ADVISORY https://github.com/netty/netty/security/advisories/GHSA-f6hv-jmp6-3vwv ADVISORY https://vuldb.com/vuln/363697 REF https://access.redhat.com/errata/RHSA-2026:23808 REF https://access.redhat.com/errata/RHSA-2026:24502 REF https://access.redhat.com/errata/RHSA-2026:25123 REF https://access.redhat.com/errata/RHSA-2026:28010 REF https://access.redhat.com/errata/RHSA-2026:34608 REF https://access.redhat.com/errata/RHSA-2026:36820 REF https://access.redhat.com/errata/RHSA-2026:37390 REF https://access.redhat.com/errata/RHSA-2026:41951 REF https://access.redhat.com/errata/RHSA-2026:42644 REF https://access.redhat.com/errata/RHSA-2026:49700 REF https://access.redhat.com/errata/RHSA-2026:49701 REF https://access.redhat.com/errata/RHSA-2026:50085 REF https://access.redhat.com/errata/RHSA-2026:53644 REF https://access.redhat.com/errata/RHSA-2026:53645 REF https://access.redhat.com/errata/RHSA-2026:53646 REF https://access.redhat.com/errata/RHSA-2026:53806 REF https://access.redhat.com/errata/RHSA-2026:54435 REF https://access.redhat.com/errata/RHSA-2026:65126 REF https://access.redhat.com/errata/RHSA-2026:66488 REF https://access.redhat.com/errata/RHSA-2026:66545 REF https://access.redhat.com/security/cve/CVE-2026-42587 REF https://bugzilla.redhat.com/show_bug.cgi?id=2477220 REF https://github.com/advisories/GHSA-f6hv-jmp6-3vwv REF https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42587.json

Search Externally

GitHub PoC Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy