CVE-2024-8184

What it actually does

This vulnerability affects Eclipse Jetty's ThreadLimitHandler.getRemote() logic. An unauthenticated remote client can send repeated crafted HTTP requests that cause Jetty to retain or allocate excessive memory while resolving or tracking remote request information for thread limiting. Sustained exploitation can trigger Java OutOfMemoryError conditions, destabilize the JVM, and make the Jetty-based service stop processing legitimate requests. The impact is availability loss rather than code execution or data disclosure.

Why it matters to the business

Successful exploitation can make Jetty-hosted applications unavailable, causing service outages, failed transactions, degraded customer experience, and operational incident response costs. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association, but internet-facing Jetty services remain exposed to low-cost denial-of-service attempts because exploitation does not require authentication. Because Jetty is commonly embedded inside Java products and custom applications, exposure may exist indirectly through packaged software, not only where Jetty is explicitly deployed.

How an attack unfolds

An attacker first identifies an HTTP or HTTPS service backed by a vulnerable Jetty version or by software embedding vulnerable Jetty components. The attacker then repeatedly sends crafted requests designed to exercise the vulnerable ThreadLimitHandler.getRemote() path. Each request contributes to abnormal memory consumption or retention inside the Jetty process. As the request volume continues, heap usage rises, garbage collection becomes increasingly frequent and ineffective, request latency increases, and the JVM may eventually throw OutOfMemoryError. Once memory is exhausted, the service may reject new connections, return 5xx errors, restart repeatedly under a supervisor, or crash until the process is manually recovered or traffic is blocked.

How to fix it

Upgrade Eclipse Jetty to a fixed build that includes commit efe8023327e67287f9bfd006700e6a71d45b5dd6, or to the vendor-released Jetty version containing that fix for the affected release line. For applications that embed Jetty, update the Jetty dependency through the build system and redeploy the application; for third-party products that bundle Jetty, apply the vendor's patched product release. If immediate upgrade is not possible, reduce exposure by restricting access to Jetty services, placing services behind a reverse proxy or WAF with request-rate limits, enforcing per-client connection and request limits, tuning JVM heap and restart behavior to reduce outage duration, and monitoring for abnormal heap growth. Mitigations should be treated as temporary because they do not correct the vulnerable code path.

How to confirm the fix worked

Confirm the deployed Jetty artifact or embedded dependency includes the fixed code from commit efe8023327e67287f9bfd006700e6a71d45b5dd6 or a vendor release that documents this fix. Review dependency manifests such as Maven/Gradle lockfiles, SBOMs, container image package inventories, and application startup logs to identify Jetty versions. Validate that patched artifacts are present in the runtime image, not only in source control. After patching, perform controlled load testing with representative request patterns while monitoring JVM heap, garbage collection, Jetty request handling, and process stability. Exposure can also be checked by inventorying internet-facing HTTP services and correlating them with Jetty fingerprints or application dependency data.

Typical attack path

1. Discover an exposed HTTP/HTTPS service running Eclipse Jetty or an application embedding Jetty.
2. Confirm the target uses a vulnerable build or infer vulnerability from banners, behavior, dependency metadata, or product version information.
3. Generate repeated crafted HTTP requests that reach Jetty's ThreadLimitHandler.getRemote() code path.
4. Sustain or parallelize the request stream to increase heap pressure and garbage collection activity.
5. Cause the Jetty JVM to throw OutOfMemoryError or become unresponsive due to memory exhaustion.
6. Maintain pressure to keep the service unavailable or repeatedly crash it after automatic restart.

How to detect it

To determine whether exploitation already occurred, review application logs, Jetty logs, JVM stderr/stdout, container logs, service manager logs, APM telemetry, reverse-proxy logs, and load balancer metrics for periods of rapid heap growth followed by OutOfMemoryError, long garbage collection pauses, elevated 5xx responses, connection resets, or process restarts. Correlate these events with spikes in repeated HTTP requests from one or more source IPs, unusual request rates, repeated requests to the same endpoints, or requests with abnormal remote-address-related headers if the deployment trusts proxy headers. Look for restart loops in systemd, Kubernetes, Docker, or process supervisors around the same time as memory exhaustion. Because this vulnerability is a denial-of-service condition, evidence is more likely to appear as resource-exhaustion telemetry and request floods than as persistent files, new processes, privilege changes, or malware artifacts.

• java.lang.OutOfMemoryError
• OutOfMemoryError: Java heap space
• OutOfMemoryError
• GC overhead limit exceeded
• org.eclipse.jetty.server.handler.ThreadLimitHandler
• ThreadLimitHandler.getRemote
• Killed process java
• OOMKilled
• ExitCode 137
• CrashLoopBackOff
• HTTP 503
• HTTP 502
• HTTP 504
• java.lang.OutOfMemoryError: Java heap space

What your security team should do

• Prioritize patching internet-facing Jetty services and products that embed Jetty, especially where unauthenticated users can send arbitrary HTTP requests.
• Update Jetty dependencies to a release containing commit efe8023327e67287f9bfd006700e6a71d45b5dd6 and rebuild/redeploy affected Java applications and containers.
• Ask third-party vendors whether their products embed vulnerable Jetty versions and obtain patched releases where applicable.
• Apply temporary rate limiting, connection limiting, and reverse-proxy filtering for exposed services until all affected Jetty runtimes are patched.
• Enable JVM and Jetty health monitoring for heap usage, garbage collection pressure, request rates, 5xx responses, and process restarts.
• Search historical logs and monitoring data for unexplained OutOfMemoryError events, heap exhaustion, restart loops, and request floods against Jetty-backed services.
• Keep the vulnerability on a standard remediation timeline rather than emergency KEV handling unless local exposure is high or active exploitation is observed.