CVE-2024-2653

What it actually does

This vulnerability is an HTTP/2 denial-of-service flaw in amphp/http. A remote unauthenticated client can send HEADERS followed by a large or endless sequence of CONTINUATION frames without setting END_HEADERS. The library buffers those frames without enforcing a size limit until END_HEADERS is received, allowing attacker-controlled memory growth that can exhaust PHP or host memory and crash the service. The primary impact is high availability loss; confidentiality is not directly affected.

Why it matters to the business

Internet-facing services that use vulnerable amphp/http code paths for HTTP/2 can be crashed remotely with low effort and no authentication, causing outages, failed transactions, degraded customer experience, and possible cascading failures if workers are repeatedly exhausted. The EPSS score is high, indicating elevated likelihood of exploitation in the wild even though this issue is not currently listed in CISA KEV and is not marked as ransomware-related.

How an attack unfolds

An attacker first identifies a service that negotiates HTTP/2 and uses a vulnerable amphp/http implementation. They open one or more HTTP/2 connections and send a header block that is intentionally never terminated with END_HEADERS. They then continue sending CONTINUATION frames, causing the server-side implementation to append the frame data to an internal buffer. Because the size check is deferred until END_HEADERS is seen, memory consumption grows with each frame. Once memory limits are reached, the PHP process, worker, container, or host may terminate or become unresponsive. The attacker can repeat the connection pattern to keep the service unavailable.

How to fix it

Upgrade amphp/http to a version that includes the fix for CVE-2024-2653 as published by the upstream project or your distribution/package maintainer. If an exact fixed version is not available in internal package metadata, update to the latest stable release and verify the advisory is closed for that version. Regenerate and deploy dependency lockfiles, rebuild containers or artifacts, and restart affected services. As interim mitigations, disable HTTP/2 where it is not required, terminate HTTP/2 at a reverse proxy that enforces strict header-list-size and CONTINUATION-frame limits, cap request header sizes, limit per-connection memory and request duration, and apply connection rate limits for clients producing malformed HTTP/2 traffic.

How to confirm the fix worked

Confirm exposure by inventorying applications and images for amphp/http in Composer manifests and lockfiles, then verify the deployed version is fixed using package manager output such as `composer show amphp/http`. Confirm whether HTTP/2 is enabled on exposed listeners using ALPN checks or web server configuration review. After patching, run controlled non-production HTTP/2 robustness tests that send incomplete header blocks with repeated CONTINUATION frames and verify the service terminates the stream or connection without unbounded memory growth. Monitor production after deployment for stable worker memory, absence of PHP out-of-memory errors, and no recurrence of HTTP/2 parser crashes.

Typical attack path

1. Identify an exposed HTTP/2 endpoint backed by software using vulnerable amphp/http code.
2. Establish an HTTP/2 session, commonly over TLS via ALPN h2 negotiation.
3. Send a HEADERS frame without the END_HEADERS flag set.
4. Send many CONTINUATION frames while continuing to omit END_HEADERS.
5. Force unbounded buffering in the vulnerable parser until memory is exhausted.
6. Repeat across connections or workers to sustain denial of service.

How to detect it

Look for evidence of prior exploitation in application logs, PHP error logs, web server or reverse-proxy logs, load balancer telemetry, process supervisor logs, container runtime events, and host memory metrics. Strong signals include PHP fatal memory exhaustion errors, worker or container OOM kills, repeated service restarts, and spikes of HTTP/2 connections that end abnormally without completing requests. If HTTP/2 frame-level logging is available, search for repeated CONTINUATION frames, header blocks missing END_HEADERS, stream resets, GOAWAY frames, or connections terminated due to header parsing errors. Correlate these events with short bursts of traffic from the same source IPs, many concurrent HTTP/2 sessions, elevated 5xx responses, and memory growth leading directly to crashes.

• Allowed memory size of
• PHP Fatal error: Allowed memory size
• Out of memory
• OOMKilled
• Killed process
• memory exhausted
• CONTINUATION frame
• END_HEADERS
• HTTP/2 stream error
• HTTP/2 connection error
• GOAWAY
• RST_STREAM
• upstream prematurely closed connection
• worker process exited on signal
• AH02919
• http2 error
• h2 protocol error

What your security team should do

• Prioritize patching internet-facing services that use amphp/http and support HTTP/2 because the flaw is remotely reachable, unauthenticated, and has a high EPSS score.
• Inventory Composer dependencies, container images, and deployed artifacts for amphp/http, including transitive dependencies.
• If immediate patching is not possible, disable HTTP/2 or place affected services behind a proxy/load balancer that enforces HTTP/2 header and CONTINUATION-frame limits.
• Add monitoring for sudden PHP worker memory growth, process restarts, 5xx spikes, and abnormal HTTP/2 connection patterns.
• Review historical logs around service crashes for evidence of repeated HTTP/2 sessions with incomplete headers or malformed frame behavior.
• Ensure process supervisors, container orchestrators, and autoscaling controls are configured to recover safely without amplifying the outage.