CVE-2025-55163

What it actually does

This is a denial-of-service flaw in HTTP/2 stream accounting. By sending malformed HTTP/2 control frames, an attacker can cause affected implementations to mishandle the maximum concurrent streams limit, allowing more effective resource consumption than intended. The impact is exhaustion of server-side resources such as connection state, memory, CPU, worker/event-loop capacity, and upstream request handling capacity, potentially causing degraded performance or service unavailability. The issue is product- and implementation-dependent and is fixed in the listed package versions or commits.

Why it matters to the business

Successful exploitation can make internet-facing applications, APIs, gateways, or services that accept HTTP/2 traffic slow or unavailable, affecting customer access, transaction processing, service-level objectives, and incident response workload. Although this CVE is not currently in CISA KEV, is not associated with ransomware use, and has a low EPSS score, it is a protocol-level DDoS condition that can be amplified by distributed traffic and should be prioritized for externally reachable services and shared platform components. The presence of common networking libraries such as Netty increases downstream exposure where applications embed vulnerable versions indirectly.

How an attack unfolds

An attacker first identifies an endpoint that supports HTTP/2, often through TLS ALPN negotiation or prior knowledge of an API gateway, reverse proxy, application server, or service endpoint. The attacker then opens HTTP/2 connections and sends specially malformed control-frame sequences designed to confuse stream-limit enforcement. Instead of the endpoint reliably enforcing its configured maximum concurrent streams value, the vulnerable implementation can allocate or retain excessive per-stream or per-connection state. Repeating this across many connections, and especially from many source addresses, can consume CPU, memory, event-loop threads, or connection handling capacity until legitimate clients experience latency, errors, resets, or outages. The campaign label associated with this class of issue is MadeYouReset, but exploitation is fundamentally a DDoS technique rather than a data theft or code execution path.

How to fix it

Upgrade affected dependencies and downstream products to fixed versions. For Rust cargo packages, upgrade risc0-circuit-rv32im to 3.0.0 or later, risc0-zkvm to 2.2.0 or later, and risc0-circuit-rv32im-sys to 3.0.0 or later. For Netty, use a release or build that includes commit 7fefa5a9d6f2bf41b6b304cfe26b2e193d8f326a or a later vendor-advised fixed version. Regenerate lockfiles and redeploy applications that package vulnerable libraries. Where immediate upgrade is not possible, reduce exposure by disabling HTTP/2 on affected endpoints, terminating HTTP/2 at a patched CDN/load balancer/proxy, enforcing strict per-IP and per-connection rate limits, lowering idle and request timeouts, capping connection counts, and monitoring/limiting abnormal HTTP/2 control-frame behavior. Ensure mitigations are applied at every layer that independently accepts HTTP/2 traffic, not only at the outermost edge.

How to confirm the fix worked

Confirm fixed dependency versions using software composition analysis, SBOM review, cargo tree or lockfile inspection for Rust packages, and build/dependency inspection for Netty-based applications. Verify deployed artifacts, container images, and runtime classpaths contain the patched versions or a Netty build with commit 7fefa5a9d6f2bf41b6b304cfe26b2e193d8f326a or later. Confirm externally reachable services either no longer negotiate HTTP/2 where disabled or are fronted by a patched HTTP/2 terminator. Review load balancer, gateway, proxy, and application metrics to ensure active streams, HTTP/2 connection counts, reset rates, and error rates remain within expected limits under controlled testing. Use only authorized, rate-limited validation tests in non-production or approved production windows because aggressive HTTP/2 frame testing can itself cause denial of service.

Typical attack path

1. Identify services that negotiate HTTP/2, especially public APIs, web applications, gateways, proxies, or Java/Netty-based services.
2. Open one or more HTTP/2 connections to the target, commonly over TLS using ALPN value h2.
3. Send malformed or abnormal HTTP/2 control-frame sequences intended to disrupt concurrent stream accounting.
4. Create or manipulate stream state so the service exceeds expected per-connection concurrency controls.
5. Repeat the behavior across many connections or distributed clients to increase CPU, memory, and connection-state pressure.
6. Observe degraded service, elevated errors, connection resets, queue growth, or service unavailability for legitimate users.

How to detect it

To determine whether exploitation may have already occurred, review edge, CDN, load balancer, reverse proxy, API gateway, service mesh, and application logs for unusual HTTP/2 behavior correlated with resource saturation or availability incidents. Focus on bursts of HTTP/2 connections, abnormal control-frame errors, excessive stream creation, stream resets, GOAWAY frames, protocol errors, and cases where observed active streams appear to exceed configured maximum concurrent stream limits. For Netty-based services, inspect application logs for HTTP/2 codec exceptions, protocol errors, frame-size or stream-state errors, and event-loop starvation around the same time as latency, 5xx responses, container restarts, high CPU, high memory, or connection backlog growth. Network telemetry should be reviewed for many short-lived or long-held HTTP/2 connections, high RST_STREAM rates, repeated ALPN h2 negotiations, and distributed low-and-slow traffic patterns from many source IPs. Because this is a denial-of-service issue, evidence is more likely to appear as traffic and stability anomalies than as persistent files, new accounts, malware, or host-level persistence artifacts.

• MadeYouReset
• SETTINGS_MAX_CONCURRENT_STREAMS
• RST_STREAM
• GOAWAY
• PROTOCOL_ERROR
• ENHANCE_YOUR_CALM
• HTTP/2 protocol error
• http2 protocol error
• HTTP2 protocol error
• too many active streams
• maximum concurrent streams
• max concurrent streams
• Maximum active streams violated
• io.netty.handler.codec.http2.Http2Exception
• io.netty.handler.codec.http2.Http2FrameCodec
• io.netty.handler.codec.http2.Http2ConnectionHandler
• ALPN h2

What your security team should do

• Prioritize remediation for internet-facing HTTP/2 endpoints, API gateways, reverse proxies, and services using Netty or the affected Rust packages.
• Upgrade risc0-circuit-rv32im to 3.0.0 or later, risc0-zkvm to 2.2.0 or later, risc0-circuit-rv32im-sys to 3.0.0 or later, and Netty builds to include commit 7fefa5a9d6f2bf41b6b304cfe26b2e193d8f326a or a later fixed release.
• Run software composition analysis across source repositories, container images, and deployed artifacts to identify transitive dependency exposure.
• If patching cannot be completed quickly, disable HTTP/2 or terminate it at a confirmed-patched CDN, load balancer, or reverse proxy.
• Add monitoring for abnormal HTTP/2 frame errors, stream concurrency anomalies, RST_STREAM/GOAWAY spikes, and resource exhaustion indicators.
• Coordinate with network and DDoS protection providers to enforce connection, stream, and request-rate controls for HTTP/2 traffic.
• Review incident history since publication for unexplained HTTP/2-heavy traffic bursts, application restarts, resource saturation, or edge-layer 5xx spikes.