CVE-2024-30255

What it actually does

The described flaw affects Envoy's downstream HTTP/2 handling before versions 1.29.3, 1.28.2, 1.27.4, and 1.26.8. Envoy permits a client to continue sending HTTP/2 CONTINUATION frames after header map limits should have been enforced, especially when the attacker withholds the END_HEADERS flag. This forces Envoy to repeatedly process an unbounded header block and consumes CPU, causing service degradation or denial of service. The impact is availability-only: it does not directly provide code execution, data disclosure, or privilege escalation.

Why it matters to the business

Internet-facing or high-traffic Envoy deployments can be made slow or unavailable by unauthenticated remote clients using relatively simple HTTP/2 traffic. This can disrupt APIs, ingress gateways, service mesh edges, load balancers, and customer-facing applications that rely on Envoy for request routing. Although it is not listed in CISA KEV and is not associated with ransomware in the provided data, the EPSS score is high, indicating elevated likelihood of exploitation attempts. Organizations should prioritize remediation for exposed Envoy listeners that allow downstream HTTP/2.

How an attack unfolds

An attacker identifies an Envoy listener that accepts HTTP/2 connections, such as an ingress proxy, API gateway, edge proxy, or service mesh gateway. The attacker opens one or more HTTP/2 sessions and sends a HEADERS frame followed by many CONTINUATION frames without setting END_HEADERS. Because vulnerable Envoy versions continue processing these frames even after header map limits are exceeded, CPU consumption grows with the volume of malicious traffic. Sustained streams from one or more clients can consume CPU cores, increase latency, trigger health-check failures, and ultimately make proxied services unavailable. Access logs may be sparse because requests may never complete header processing.

How to fix it

Upgrade Envoy to a fixed release: 1.29.3 or later, 1.28.2 or later, 1.27.4 or later, or 1.26.8 or later, depending on the deployed branch. If immediate upgrade is not possible, disable HTTP/2 for downstream connections on exposed listeners until patched. Also consider rate limiting new connections, limiting concurrent HTTP/2 streams, placing upstream DDoS protections in front of exposed proxies, and monitoring Envoy CPU saturation. The supplied affected-product metadata references ImageMagick GIT commits, which does not align with the Envoy HTTP/2 CONTINUATION-frame issue described here; vulnerability management teams should validate scanner mappings against the Envoy advisory and not rely solely on the mismatched package names.

How to confirm the fix worked

Confirm deployed Envoy versions with runtime inventory, container image manifests, package metadata, or `envoy --version`, and verify they are at or above 1.29.3, 1.28.2, 1.27.4, or 1.26.8. Review listener configuration to determine whether downstream HTTP/2 is enabled, including ALPN `h2` on TLS listeners and explicit HTTP/2 protocol options. Validate mitigation by confirming exposed listeners no longer negotiate HTTP/2 if using the workaround. After patching, perform controlled HTTP/2 negative testing in a non-production or approved test environment to ensure excessive CONTINUATION frames are rejected or connection handling remains stable without sustained CPU growth.

Typical attack path

1. Discover an Envoy endpoint that negotiates HTTP/2 over TLS or cleartext HTTP/2.
2. Open HTTP/2 connections to the downstream listener.
3. Begin a header block with a HEADERS frame.
4. Send a long sequence of CONTINUATION frames without the END_HEADERS flag.
5. Repeat across multiple streams or connections to increase CPU pressure.
6. Maintain the flood until Envoy worker threads saturate and legitimate traffic is delayed or dropped.

How to detect it

Look for evidence of denial-of-service activity rather than compromise. Primary sources include Envoy metrics, proxy access logs, L4/L7 load balancer logs, WAF or DDoS telemetry, packet captures, NetFlow, IDS HTTP/2 decoders, host CPU metrics, container orchestration events, and service health-check logs. Indicators include sharp Envoy CPU increases without a proportional increase in completed requests, many HTTP/2 connections that do not produce access-log entries, repeated connection resets or protocol errors, high downstream connection counts from a small set of source IPs, and packet captures showing HEADERS frames followed by many CONTINUATION frames with END_HEADERS unset. Because the malicious request may never complete header parsing, absence of normal HTTP request fields in access logs does not rule out exploitation. Correlate attack windows with Envoy worker saturation, 5xx/503 spikes, upstream health-check failures, autoscaling events, and network captures containing abnormal HTTP/2 CONTINUATION-frame sequences.

• HTTP/2 CONTINUATION frame flood
• CONTINUATION frames without END_HEADERS
• END_HEADERS=0
• type=CONTINUATION
• http2.type == 9
• http2.flags.end_headers == 0
• HEADERS followed by repeated CONTINUATION
• downstream_cx_destroy_remote_active_rq
• downstream_rq_5xx
• downstream_rq_503
• envoy --version

What your security team should do

• Prioritize patching internet-facing Envoy gateways, ingress controllers, API gateways, and service mesh edge proxies that accept downstream HTTP/2.
• Upgrade to Envoy 1.29.3, 1.28.2, 1.27.4, 1.26.8, or a later supported version for the deployed release branch.
• If patching is delayed, temporarily disable downstream HTTP/2 on exposed listeners where business requirements allow.
• Add monitoring for sudden Envoy CPU saturation, worker thread pressure, connection spikes, and HTTP/2 protocol anomalies.
• Tune edge controls to rate limit abusive clients and cap excessive concurrent connections or streams.
• Review load balancer, WAF, reverse proxy, and DDoS telemetry for HTTP/2 CONTINUATION-frame floods, especially because application access logs may not show completed requests.
• Validate vulnerability scanner results against vendor advisories because the provided affected-product list appears inconsistent with the Envoy vulnerability description.