CVE-2026-78058 in bRPC
Summary
by MITRE • 10/22/2026
Uncontrolled resource consumption in the HTTP/2 (h2) receive path of Apache bRPC (version < 1.18.0) on all platforms allows a remote unauthenticated attacker to crash the server or grow its memory without bound by sending crafted HTTP/2 frames.
Root Cause: The h2 parser, enabled by default on every bRPC server port and used by h2/gRPC clients, trusts the peer to respect receive-side limits that bRPC advertises but never enforces: 1. SETTINGS_MAX_CONCURRENT_STREAMS defaulted to unlimited and was never checked on the server, letting a peer pin an unbounded number of pending streams per connection (~100x memory amplification). 2. SETTINGS_MAX_HEADER_LIST_SIZE defaulted to unlimited and was never enforced; 1-byte HPACK indexed references amplify a small HEADERS frame ~4000x into an unbounded decoded header list ("HPACK bomb"), and a never-completed HEADERS/CONTINUATION block accumulates memory without limit. 3. Control-frame acks (PING/SETTINGS acks, RST_STREAM, GOAWAY, WINDOW_UPDATE) unconditionally bypassed the -socket_max_unwritten_bytes write cap, so a PING flood combined with withheld TCP reads grew the connection buffer without the documented bound. 4. The HPACK dynamic table size update was validated against the protocol default (4096) instead of the advertised SETTINGS_HEADER_TABLE_SIZE, which together with the dynamic-table queue/accounting issue can desynchronize the decoder and dereference NULL (crash).
Affected scenarios: Any bRPC server serving HTTP/h2/gRPC to an untrusted network, and any bRPC h2/gRPC client connecting to an untrusted backend. The h2 parser runs before any Authenticator check on the shared port.
How to fix: Upgrade bRPC, or apply the patch in https://github.com/apache/brpc/pull/3474.
Note: After applying the fix the following limits are enforced by default: - max_concurrent_streams: 1024 per connection (4294967295 restores unlimited). - max_header_list_size: 1 MiB decoded size per stream (4294967295 restores unlimited; -h2_client_max_header_list_size for clients). - h2 control-frame acks respect -socket_max_unwritten_bytes (-h2_ack_ignore_eovercrowded restores the old behavior). Requests exceeding these limits are rejected (RST_STREAM(REFUSED_STREAM) or a connection error).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Apache bRPC versions prior to 1.18.0 represents a critical failure in resource management within the HTTP/2 receive path, classified under CWE-400 as Uncontrolled Resource Consumption. This flaw allows remote unauthenticated attackers to cause denial of service by crashing the server or inducing unbounded memory growth through crafted HTTP/2 frames. The root cause lies in the fundamental design decision where the h2 parser trusts peer-advertised limits without enforcing them, creating a significant attack surface for resource exhaustion attacks. Because the HTTP/2 parser operates before any authentication checks on shared ports, this vulnerability is accessible to unauthenticated actors, aligning with ATT&CK technique T1498 Network Denial of Service where an attacker disrupts service availability by consuming resources faster than they can be reclaimed or managed.
The first major component of this flaw involves the handling of concurrent streams via SETTINGS_MAX_CONCURRENT_STREAMS. By default, this setting was configured to unlimited and never enforced on the server side. This oversight allows a malicious peer to open an unbounded number of pending streams per connection. In practice, this can lead to approximately one hundred times memory amplification as each stream consumes system resources for state tracking and buffer allocation without any upper bound or throttling mechanism in place. The lack of enforcement means that the server cannot effectively limit the concurrency level, leading to rapid resource depletion under sustained attack conditions where an attacker opens thousands of streams simultaneously.
A second critical area of vulnerability is related to header processing and HPACK compression. The SETTINGS_MAX_HEADER_LIST_SIZE was also defaulted to unlimited and never enforced. Attackers can exploit this by sending small HEADERS frames containing one-byte HPACK indexed references that expand into massive decoded header lists, a technique known as an HPACK bomb. This expansion factor can reach approximately four thousand times the original frame size. Furthermore, incomplete or fragmented HEADERS and CONTINUATION blocks accumulate memory without limit because there is no timeout or size cap to discard partial data structures. This mechanism allows attackers to consume significant amounts of server memory with minimal network bandwidth usage, effectively starving legitimate traffic and degrading system performance until a crash occurs due to out-of-memory conditions.
The third vector involves control frame acknowledgments such as PING, SETTINGS acks, RST_STREAM, GOAWAY, and WINDOW_UPDATE updates. These frames unconditionally bypassed the socket_max_unwritten_bytes write cap, which is designed to prevent excessive buffering on network sockets. When an attacker floods the server with PING requests while withholding TCP reads from their end, the connection buffer grows without limit. This behavior defeats the purpose of flow control mechanisms intended to protect against backpressure issues and allows for unbounded memory growth in the kernel or application buffers associated with the socket I/O operations.
The fourth aspect concerns HPACK dynamic table management where size updates were validated against a hardcoded protocol default rather than the advertised SETTINGS_HEADER_TABLE_SIZE value. This discrepancy, combined with accounting errors in the dynamic-table queue, can cause desynchronization between the encoder and decoder states. Such state mismatch leads to null pointer dereferences during decoding operations, resulting in immediate server crashes. This specific failure mode highlights how subtle logic errors in protocol implementation can lead to stability issues that are easily exploitable for denial of service purposes without requiring complex payload construction beyond standard control frames or header manipulations.
The operational impact extends to any bRPC server serving HTTP/2 or gRPC traffic over untrusted networks, as well as clients connecting to potentially malicious backends. Since the parser runs before authentication, even restricted endpoints are vulnerable if they accept HTTP/2 connections from unknown sources. The combination of memory amplification through streams and headers, along with buffer overflow via control frames, creates a multi-vector attack path that is difficult to mitigate at the network perimeter alone due to its reliance on application-layer protocol semantics.
To remediate this vulnerability, organizations must upgrade Apache bRPC to version 1.18.0 or later, which incorporates patches from pull request 3474 in the official repository. The updated implementation enforces strict limits by default: maximum concurrent streams are capped at one thousand twenty-four per connection unless explicitly set otherwise; header list size is limited to one megabyte of decoded data per stream; and control frame acknowledgments now respect socket write capacity constraints. These defaults can be adjusted if necessary, but leaving them at their new secure values provides robust protection against the described resource exhaustion attacks. Requests that exceed these enforced limits are properly rejected with appropriate HTTP/2 error codes such as REFUSED_STREAM or connection errors, ensuring graceful degradation rather than uncontrolled failure.