CVE-2026-1605
📋 TL;DR
This vulnerability in Eclipse Jetty's GzipHandler causes a memory leak when processing compressed HTTP requests without compressed responses. Attackers can exploit this to cause denial of service by exhausting server memory. Systems running affected Jetty versions with GzipHandler enabled are vulnerable.
💻 Affected Systems
- Eclipse Jetty
📦 What is this software?
Jetty by Eclipse
Jetty by Eclipse
⚠️ Risk & Real-World Impact
Worst Case
Complete denial of service through memory exhaustion, potentially crashing the Jetty server and disrupting all hosted applications.
Likely Case
Gradual performance degradation leading to eventual service disruption as memory leaks accumulate over time.
If Mitigated
Minimal impact with proper monitoring and memory limits, though some performance degradation may still occur.
🎯 Exploit Status
Exploitation requires sending specially crafted HTTP requests with Content-Encoding: gzip header to trigger the memory leak condition.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Jetty 12.0.32 and 12.1.6
Vendor Advisory: https://github.com/jetty/jetty.project/security/advisories/GHSA-xxh7-fcf3-rj7f
Restart Required: Yes
Instructions:
1. Upgrade to Jetty 12.0.32 or 12.1.6. 2. Update dependencies in your project. 3. Restart the Jetty server. 4. Verify the fix by checking the version.
🔧 Temporary Workarounds
Disable GzipHandler for request decompression
allConfigure Jetty to not use GzipHandler for decompressing incoming requests while maintaining response compression if needed.
Modify jetty.xml or programmatic configuration to remove GzipHandler from request processing chain
Implement memory monitoring and limits
allSet strict memory limits and implement monitoring to detect and restart services when memory usage exceeds thresholds.
Set JVM options: -Xmx to limit heap, -XX:MaxMetaspaceSize for metaspace
Implement monitoring with tools like JMX or Prometheus
🧯 If You Can't Patch
- Implement network filtering to block requests with Content-Encoding: gzip header at load balancer or firewall level.
- Deploy memory monitoring with automated alerts and restart procedures when memory leaks are detected.
🔍 How to Verify
Check if Vulnerable:
Check if GzipHandler is configured in your Jetty deployment and verify the Jetty version is within affected ranges.Check Version:
java -jar jetty-home-*.jar --version or check server logs for version informationVerify Fix Applied:
After patching, verify the Jetty version is 12.0.32+ or 12.1.6+ and test with compressed requests to ensure no memory leaks occur.📡 Detection & Monitoring
Log Indicators:
- Unusual memory growth patterns in JVM metrics
- Frequent garbage collection events
- OutOfMemoryError in logs
Network Indicators:
- HTTP requests with Content-Encoding: gzip header to endpoints with GzipHandler enabled
- Increased request rate to trigger memory leak
SIEM Query:
source="jetty.logs" AND ("OutOfMemoryError" OR "java.lang.OutOfMemoryError") OR (metric="jvm_memory_used" AND value>threshold)