CVE-2025-58057

What it actually does

The flaw is a denial-of-service condition in Netty decompression handling. Specially crafted compressed input processed by BrotliDecoder and some other decompressing decoders can cause allocation of a large number of reachable byte buffers. Because the buffers remain reachable, normal garbage collection may not quickly reclaim them, resulting in excessive heap or direct-memory consumption, garbage-collection pressure, event-loop stalls, OutOfMemoryError conditions, and potential process termination. The issue impacts availability; it does not inherently provide code execution or data disclosure.

Why it matters to the business

Applications and gateways built on affected Netty code may be taken offline or degraded by malicious compressed traffic, causing service interruptions, failed requests, latency spikes, autoscaling cost increases, and operational incident response. Although this vulnerability is not listed in CISA KEV, is not currently associated with ransomware use, and has a low EPSS score, it has been public for 341 days and affects a widely used networking framework, so exposed services that accept Brotli or other compressed untrusted input should still be prioritized for upgrade or mitigation.

How an attack unfolds

An attacker identifies an internet-facing or otherwise reachable service that uses Netty with BrotliDecoder or another affected decompression decoder enabled in the request-processing pipeline. The attacker sends specially crafted compressed payloads, commonly through HTTP requests or streams that advertise compressed content. When the service attempts to decode the input, the vulnerable decoder allocates many byte buffers and keeps them reachable. Repeated or concurrent attempts increase memory pressure until the JVM experiences severe garbage-collection churn, direct-memory exhaustion, heap exhaustion, event-loop starvation, or process failure. Reported threat context includes MadeYouReset, so defenders should treat suspicious reset-heavy or compression-abuse traffic patterns as relevant during triage, even though broad weaponization is not indicated by the provided exploit maturity.

How to fix it

Upgrade Netty to a version that includes the fix, or apply the upstream source fix identified as commit 9d804c54ce962408ae6418255a83a13924f7145d. For source builds of netty/netty, verify that this commit or an equivalent backport is present. If consuming Netty through package managers or transitive dependencies, update all dependent components to releases that incorporate the fixed Netty code and rebuild/redeploy affected services. As interim mitigations, disable Brotli decompression for untrusted request bodies where not required, restrict accepted Content-Encoding values, enforce strict compressed and decompressed body-size limits, cap per-connection and per-request memory use, apply request-rate and concurrency limits, and place externally exposed services behind load balancers or gateways that can reject abnormal compressed payloads before they reach Netty.

How to confirm the fix worked

Confirm dependency exposure using software composition analysis, dependency trees, SBOMs, build manifests, or source review to identify Netty versions or source builds containing vulnerable decompression code. For source-based deployments, verify that commit 9d804c54ce962408ae6418255a83a13924f7145d or an equivalent patch is present. For binary deployments, confirm the running artifact was rebuilt against a fixed Netty release or patched commit, not only that the repository was updated. In staging, send representative valid and malformed compressed requests and confirm memory usage remains bounded, the service returns controlled errors for rejected payloads, and no OutOfMemoryError, direct-memory exhaustion, event-loop stalls, or abnormal garbage-collection behavior occurs. Validate that edge controls enforce request-size, decompressed-size, encoding, rate, and concurrency limits.

Typical attack path

1. Reconnoiter services that expose Netty-based HTTP, proxy, API gateway, or streaming endpoints.
2. Confirm that the service accepts compressed request bodies or streams, especially Brotli-encoded input.
3. Send specially crafted compressed input that reaches BrotliDecoder or another affected decompression decoder.
4. Trigger excessive allocation of reachable byte buffers during decompression.
5. Repeat the requests or open concurrent streams to accelerate heap or direct-memory exhaustion.
6. Cause latency spikes, garbage-collection pressure, request failures, event-loop stalls, or process termination.
7. Optionally continue sending traffic to prevent recovery or repeatedly crash restarted instances.

How to detect it

To determine whether exploitation already occurred, correlate application access logs, reverse-proxy logs, load-balancer logs, JVM logs, container orchestration events, and infrastructure metrics. Look for bursts of requests using compressed request bodies, especially Content-Encoding: br, followed by high heap or direct-memory usage, long garbage-collection pauses, request timeouts, 5xx responses, pod or process restarts, or OutOfMemoryError events. Review application logs for Netty decompression stack traces involving BrotliDecoder or ByteBuf allocation failures. Examine edge telemetry for high request concurrency, abnormal compressed payload sizes, repeated connection resets, or reset-heavy patterns consistent with the provided MadeYouReset threat context. If available, inspect preserved heap dumps for unusually large numbers of Netty ByteBuf, byte array, or direct-buffer objects retained by decompression paths. Successful exploitation may leave few durable file artifacts because the primary effect is memory exhaustion, so time-based correlation between compressed traffic and service instability is critical.

• Content-Encoding: br
• content-encoding: br
• io.netty.handler.codec.compression.BrotliDecoder
• io.netty.handler.codec.compression
• io.netty.buffer.ByteBuf
• io.netty.util.internal.OutOfDirectMemoryError
• java.lang.OutOfMemoryError: Direct buffer memory
• java.lang.OutOfMemoryError: Java heap space
• Cannot reserve memory
• failed to allocate
• LEAK: ByteBuf.release() was not called
• TooLongFrameException
• OutOfMemoryError
• Killed process
• OOMKilled
• CrashLoopBackOff

What your security team should do

• Inventory applications, gateways, proxies, and services that use Netty and accept compressed untrusted input.
• Prioritize externally reachable systems and high-availability services where Brotli or automatic decompression is enabled.
• Upgrade or rebuild affected components with the Netty fix containing commit 9d804c54ce962408ae6418255a83a13924f7145d or a release that includes it.
• Temporarily disable Brotli request decompression or restrict Content-Encoding to required values only until patching is complete.
• Enforce maximum compressed body size, decompressed output size, request duration, connection concurrency, and per-client rate limits.
• Add monitoring for JVM heap exhaustion, direct-memory exhaustion, garbage-collection spikes, Netty decoder exceptions, and sudden increases in compressed requests.
• Review historical logs for suspicious Brotli/compressed traffic correlated with memory pressure, process restarts, or availability incidents.
• Ensure incident runbooks include rapid rollback, traffic filtering, heap dump preservation, and restart throttling to avoid repeated crash loops.