CVE-2025-55181: Facebook Proxygen DOS Vulnerability

CVE-2025-55181 Overview

CVE-2025-55181 affects Facebook Proxygen, an open-source C++ HTTP library used to build high-performance HTTP servers and clients. The vulnerability exists in proxygen::coro::HTTPQuicCoroSession and is triggered when an HTTP request or response body exceeds 2^31 bytes (approximately 2 GiB). Processing such a body forces the session into an infinite loop that blocks the backing event loop and unconditionally appends data to a std::vector on every loop iteration. The result is unbounded memory growth that ends in an out-of-memory (OOM) condition and process termination. The issue is classified as [CWE-834] (Excessive Iteration) and represents a network-reachable denial-of-service condition against services built on Proxygen's HTTP/3 (QUIC) stack.

Critical Impact
A remote, unauthenticated attacker can exhaust server memory and crash Proxygen-based HTTP/3 services by sending a single oversized HTTP body, causing service-wide denial of service.

Affected Products

Facebook Proxygen (versions prior to commit 17689399ef99b7c3d3a8b2b768b1dba1a4b72f8f)
Applications and services embedding Proxygen's HTTPQuicCoroSession for HTTP/3 handling
Downstream projects built on the affected Proxygen coroutine HTTP stack

Discovery Timeline

2025-12-02 - CVE-2025-55181 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-55181

Vulnerability Analysis

Proxygen implements HTTP/3 session handling through the HTTPQuicCoroSession class inside its coroutine-based HTTP stack. When an incoming HTTP body exceeds 2^31 bytes, the egress path fails to reconcile flow control state with the amount of data buffered for the stream. Instead of yielding or applying backpressure, the session repeatedly re-enters the write loop, appending body bytes to an internal std::vector on each iteration without ever draining it. This behavior stalls the event loop hosting the session, preventing other connections from making progress. Memory usage grows linearly with attacker-supplied data until the operating system kills the process. The impact is limited to availability, but a single connection is sufficient to degrade or terminate the service.

Root Cause

The root cause is a missing flow-control synchronization step in the egress path of HTTPQuicCoroSession. After bytes were written, the code failed to simulate a window update to advance stream state, so the session continued to observe an unwritten backlog and looped indefinitely. Combined with unbounded buffer appends, this iteration defect ([CWE-834]) produces both event-loop starvation and memory exhaustion from a single oversized message.

Attack Vector

The vulnerability is reachable over the network by any client capable of establishing an HTTP/3 (QUIC) session with the target. No authentication, privileges, or user interaction are required. An attacker sends an HTTP request whose body is larger than 2^31 bytes, or induces the server to emit such a response, and the receiving Proxygen process enters the runaway state. The oversized body can be streamed incrementally, so the attacker does not need to transmit the full payload before impact begins.

cpp

// Fix applied in HTTPCoroSession.cpp - simulate window update after egress
                                 std::move(fieldSectionInfo),
                                 stream->observedBodyLength(),
                                 stream->getWriteBuf().chainLength());
+        stream->onWindowUpdate(bytesWritten); // simulate window update
       }
       XLOG(DBG4) << "Egressed len=" << bytesWritten << " id=" << stream->getID()
                  << " sess=" << *this;
// Source: https://github.com/facebook/proxygen/commit/17689399ef99b7c3d3a8b2b768b1dba1a4b72f8f

The patch inserts an onWindowUpdate(bytesWritten) call after each egress iteration, advancing stream state so the loop terminates and buffers are released.

Detection Methods for CVE-2025-55181

Indicators of Compromise

Sustained single-connection HTTP/3 sessions transferring or advertising body sizes at or above 2 GiB
Rapid, monotonic memory growth in Proxygen worker processes correlated with a specific QUIC connection ID
Event-loop stalls or missed timers on Proxygen threads, followed by OOM-killer termination of the server process

Detection Strategies

Instrument Proxygen deployments to log HTTP body length per stream and alert when a single body exceeds a configured threshold well below 2^31 bytes
Correlate resident-set-size (RSS) growth with active QUIC stream IDs to identify sessions responsible for memory pressure
Monitor for HTTPQuicCoroSession egress loops that produce many Egressed len= debug entries for the same stream without completion

Monitoring Recommendations

Track process-level metrics such as RSS, page faults, and OOM-kill events on hosts running Proxygen-based services
Emit histograms of HTTP request and response body sizes at the load balancer or edge proxy to spot outlier payloads
Alert on abnormal client behavior sending very large HTTP/3 bodies from a single source IP or QUIC connection

How to Mitigate CVE-2025-55181

Immediate Actions Required

Upgrade Proxygen to a build that includes commit 17689399ef99b7c3d3a8b2b768b1dba1a4b72f8f from the facebook/proxygen repository
Rebuild and redeploy any downstream applications that statically link or vendor the affected Proxygen sources
Enforce maximum HTTP request and response body size limits at upstream proxies or load balancers to reject payloads approaching 2^31 bytes

Patch Information

The fix is committed to the Proxygen repository at commit 17689399, which adds the missing stream->onWindowUpdate(bytesWritten) call in proxygen/lib/http/coro/HTTPCoroSession.cpp. Additional details are available in the Facebook Security Advisory for CVE-2025-55181.

Workarounds

Terminate HTTP/3 traffic at an upstream proxy that enforces a Content-Length and streamed-body ceiling below 2^31 bytes
Configure per-connection and per-process memory limits (for example, cgroup memory.max) so a single runaway session cannot exhaust host memory
Disable HTTP/3 (QUIC) endpoints on Proxygen-based services until the patched version is deployed, if operationally feasible

bash

# Example: enforce a 512 MiB request body limit at an NGINX proxy fronting Proxygen
http {
    client_max_body_size 512m;
    client_body_buffer_size 128k;
    client_body_timeout 30s;
}

# Example: constrain the Proxygen service memory footprint via systemd
# /etc/systemd/system/proxygen.service.d/limits.conf
[Service]
MemoryMax=4G
MemoryHigh=3G