CVE-2026-1605: 
Java vulnerability analysis and mitigation

CVE-2026-1605 is a memory leak (resource exhaustion) vulnerability in Eclipse Jetty's GzipHandler class that can be exploited to cause denial of service via off-heap out-of-memory errors (OOMEs). It affects Eclipse Jetty versions 12.0.0–12.0.31 and 12.1.0–12.1.5 (Maven artifact org.eclipse.jetty:jetty-server). The vulnerability was published on March 5, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, Red Hat).

The root cause is a missing resource release (CWE-401 / CWE-772) leading to uncontrolled resource consumption (CWE-400) in GzipHandler.handle(). When a compressed HTTP request (Content-Encoding: gzip) is received, a JDK Inflater object is allocated via GzipRequest to decompress the request body. However, gzipRequest.destroy() — which returns the Inflater to the pool — is only invoked when the response is also compressed (i.e., when GzipResponseAndCallback is created). If the response is not compressed (no Accept-Encoding: gzip from the client or the handler does not compress the response), the destroy callback is never triggered, causing the Inflater to leak. Repeated exploitation accumulates thousands of java.util.zip.Inflater objects consuming both Java heap and native memory, ultimately crashing the JVM with an OOME. The fix requires wrapping the callback whenever a GzipRequest is created, not only when deflation is also needed (Github Advisory).

Successful exploitation results in progressive memory exhaustion — both Java heap and native off-heap memory — leading to JVM crashes with OutOfMemoryError. The impact is limited to availability (no confidentiality or integrity loss), but the denial of service can render the affected Jetty server completely unavailable. Downstream products embedding Jetty (e.g., IBM Business Automation Insights, IBM EDB PGAI Hybrid Management, Red Hat AMQ Broker) are also affected (Red Hat Bugzilla, IBM Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been observed as of the time of reporting (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.033% (10th percentile), indicating a low near-term exploitation probability. However, the attack requires no authentication, no user interaction, and low complexity — any network-accessible attacker can trigger the leak by sending gzip-compressed HTTP requests.

1. Reconnaissance: Identify internet-facing Eclipse Jetty servers running versions 12.0.0–12.0.31 or 12.1.0–12.1.5 using tools like Shodan, Censys, or HTTP banner grabbing (e.g., Server: Jetty/12.x.x response header).
2. Confirm GzipHandler is active: Send a test HTTP request with Accept-Encoding: gzip and observe whether the response includes Content-Encoding: gzip. If so, GzipHandler is likely enabled.
3. Craft the exploit request: Prepare an HTTP POST (or other body-bearing method) request with a gzip-compressed body (Content-Encoding: gzip) but without Accept-Encoding: gzip in the request headers, ensuring the server will not compress its response.
4. Flood the server: Repeatedly send these crafted requests in a loop or using a tool like curl, ab, or a custom script. Each request causes a new java.util.zip.Inflater object to be allocated and never released.
5. Trigger OOM: After sufficient requests, the accumulated unreleased Inflater objects exhaust Java heap and native memory, causing the JVM to crash with an OutOfMemoryError, resulting in service unavailability (Github Advisory).

• Network: High volume of HTTP requests with Content-Encoding: gzip but lacking Accept-Encoding: gzip headers from a single or small set of source IPs; unusual sustained POST/PUT traffic to Jetty endpoints.
• Logs: Jetty access logs showing repeated compressed-body requests without corresponding compressed responses; Java exception logs containing java.lang.OutOfMemoryError or GC overhead limit exceeded errors.
• Process/JVM: Rapidly growing JVM heap and native memory usage observable via JVM monitoring tools (e.g., JConsole, VisualVM, Prometheus JMX exporter); heap dumps revealing thousands of java.util.zip.Inflater instances.
• System: Unexpected Jetty process crashes or restarts; OS-level memory exhaustion alerts from monitoring systems.

Upgrade Eclipse Jetty to version 12.0.32 (for the 12.0.x branch) or 12.1.6 (for the 12.1.x branch), which contain the fix ensuring gzipRequest.destroy() is always called upon request completion (Github Advisory). As an immediate workaround if patching is not possible, disable GzipHandler entirely, or implement network-level rate limiting on gzip-compressed HTTP requests. Additionally, monitor JVM memory consumption for unexpected growth patterns that may indicate exploitation. Downstream product users should apply vendor-specific patches: Red Hat AMQ Broker 7.14.0 via RHSA-2026:8509, and IBM products via their respective security bulletins (Red Hat Bugzilla, IBM Advisory).

The vulnerability was reported by community researchers glebashnik and bjorncs via the Jetty project's security advisory process (Github Advisory). Red Hat triaged it as high severity and tracked it via Bugzilla with a broad CC list spanning multiple product teams, indicating wide internal impact assessment (Red Hat Bugzilla). Social media activity was limited to automated CVE tracking posts on Bluesky and Mastodon. The Apache Kafka community also referenced the vulnerability in the context of a KIP proposal to shadow Jetty dependencies.