CVE-2024-38809

What it actually does

The vulnerability is a network-exploitable denial-of-service condition in applications that parse ETag values from HTTP If-Match or If-None-Match request headers. An unauthenticated remote client can send specially crafted or excessively large conditional request headers that cause vulnerable ETag parsing logic to consume disproportionate CPU, memory, or request-processing resources. The flaw does not provide code execution, data disclosure, or privilege escalation, but it can degrade availability of affected HTTP endpoints.

Why it matters to the business

Successful exploitation can make web applications slow, unstable, or temporarily unavailable, causing failed user transactions, service disruption, degraded API reliability, and increased infrastructure load. Because exploitation requires only network access and no authentication, internet-facing applications that accept conditional HTTP requests are the highest priority. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but availability impact can still be material for high-traffic or business-critical services.

How an attack unfolds

An attacker identifies an HTTP endpoint backed by a vulnerable application stack that processes conditional request headers. The attacker then sends requests containing malformed, deeply nested, numerous, or oversized ETag values in If-Match or If-None-Match headers. When the vulnerable application attempts to parse those headers, request handling becomes inefficient and consumes excessive processing resources. Repeated requests, or a small number of large concurrent requests, can tie up application threads, increase latency, trigger memory pressure, exhaust worker pools, or cause upstream load balancers and clients to experience timeouts. The attack can be performed remotely without credentials and may blend into normal HTTP traffic unless header-size anomalies are monitored.

How to fix it

Upgrade affected application frameworks or libraries to the vendor-provided fixed versions for CVE-2024-38809 where applicable. If exact fixed versions are not centrally tracked, consult the relevant vendor advisory for the affected product line and upgrade to the corresponding maintained release. For older or unsupported versions, mitigate by enforcing strict maximum sizes for If-Match and If-None-Match request headers at the application, middleware, reverse proxy, API gateway, or web application firewall layer. Reject requests with excessively long conditional headers, excessive ETag counts, invalid ETag formatting, or abnormal quoted-string structures. Also ensure request header size limits, per-client rate limits, connection limits, and timeout controls are configured on edge infrastructure.

How to confirm the fix worked

Confirm that all affected application components have been upgraded to a fixed supported version or that compensating controls limit If-Match and If-None-Match header size and complexity. Validate exposure by sending benign test requests with oversized If-Match and If-None-Match headers in a controlled environment and confirming that the request is rejected quickly with a 400, 413, 414, or similar error rather than causing latency, CPU spikes, memory growth, thread exhaustion, or application errors. Review reverse proxy, API gateway, and application configurations to verify maximum header-size enforcement. Monitor application metrics during testing for stable CPU, heap, garbage collection, request latency, and worker-thread utilization.

Typical attack path

1. Discover an internet-facing application or API that accepts HTTP requests and uses ETag conditional request handling.
2. Send probing requests containing If-Match or If-None-Match headers to observe application behavior, status codes, and latency changes.
3. Craft requests with unusually large, numerous, or malformed ETag values in the conditional headers.
4. Repeat the crafted requests or run them concurrently to amplify CPU, memory, or worker-thread consumption.
5. Cause degraded performance, request timeouts, increased error rates, or partial service unavailability.

How to detect it

To determine whether exploitation was attempted or successful, review HTTP access logs, reverse proxy logs, API gateway logs, WAF events, and application logs for requests containing unusually long, repetitive, or malformed If-Match or If-None-Match headers. Correlate those requests with latency spikes, request timeouts, increases in 400, 413, 414, 429, 500, 502, 503, or 504 responses, thread-pool exhaustion messages, memory pressure, garbage collection pauses, container restarts, autoscaling events, or health-check failures. Look for single clients or small client sets sending many conditional requests with large quoted ETag lists, wildcard ETags combined with other values, excessive comma-separated ETag values, or headers approaching configured maximum header size. Because this is a denial-of-service issue, evidence of exploitation is more likely to appear as traffic anomalies and resource exhaustion than as persistent files or post-exploitation artifacts.

• If-Match:
• If-None-Match:
• HTTP 400
• HTTP 413
• HTTP 414
• HTTP 429
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504
• Request header too large
• Header size exceeded
• upstream timed out
• connection reset by peer
• java.lang.OutOfMemoryError
• java.lang.StackOverflowError
• GC overhead limit exceeded
• RejectedExecutionException
• Too many open files

What your security team should do

• Inventory internet-facing and business-critical applications that process HTTP If-Match or If-None-Match headers and map the underlying framework or library versions.
• Prioritize upgrades for exposed services, high-traffic APIs, and applications where availability disruption would have business impact.
• Apply vendor-fixed versions where available; otherwise enforce strict header-size and request-complexity limits at the edge and in application filters.
• Deploy WAF, API gateway, or reverse proxy rules to block abnormally large or malformed If-Match and If-None-Match headers.
• Add monitoring for spikes in conditional request headers, HTTP 400/413/5xx responses, application latency, CPU usage, memory pressure, garbage collection, and thread-pool exhaustion.
• Rate-limit clients that repeatedly send oversized or malformed conditional request headers.
• Review logs for historical attempts using unusually large If-Match or If-None-Match headers, especially around periods of unexplained application slowdown or service instability.