CVE-2026-81755 in bRPC
Summary
by MITRE • 10/22/2026
Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version < 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams.
Root Cause: In the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field `stream_settings.extra_stream_ids` of the RPC meta. On the server side, `StreamAccept` creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by `max_body_size` (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service.
Affected Scenarios: Use a bRPC server that serves streaming RPC and calls `StreamAccept` to accept streams from untrusted clients.
How to Fix: (Choose one of the following options) 1. Upgrade bRPC to the 1.18.0 version. 2. Apply this patch: https://github.com/apache/brpc/pull/3493
Note: The fix adds a new gflag `stream_max_streams_per_request` with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that legitimately need to accept more than 64 streams in one RPC must raise this flag; otherwise such requests will fail after applying the fix.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified as an uncontrolled resource consumption flaw within the Apache bRPC framework, specifically affecting versions prior to 1.18.0, represents a significant security risk for services relying on streaming Remote Procedure Call mechanisms. This issue allows a remote attacker to trigger a denial of service condition by exhausting server memory resources through a single, carefully crafted RPC request. The core technical flaw resides in the handling of stream identifiers within the streaming RPC component. When a client initiates an RPC call that utilizes multiple streams, it can populate the repeated field `stream_settings.extra_stream_ids` with an arbitrary number of stream identifiers. On the server side, the function responsible for accepting these connections, known as StreamAccept, iterates through this list and creates a distinct response stream for every identifier provided by the client without implementing any upper limit on the quantity of streams accepted per single RPC invocation.
The operational impact of this vulnerability is severe due to the resource-intensive nature of each created stream within the bRPC architecture. Each accepted stream requires the allocation of its own bthread execution queue and associated system resources, including memory for context switching and state management. While the request body size is constrained by a configurable parameter called max_body_size, which defaults to 64 megabytes, this limit is insufficient to prevent abuse because it allows for the transmission of millions of stream identifiers within a single packet or message frame. Consequently, an attacker can send one such oversized request containing hundreds of thousands or even millions of stream IDs, forcing the server to allocate memory for that many concurrent streams simultaneously. This rapid and massive allocation quickly depletes available system memory, leading to application crashes, service unavailability, or complete host-level denial of service as the operating system may begin swapping or killing processes due to out-of-memory conditions.
From a threat modeling perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, and is particularly relevant in scenarios where services are exposed to untrusted clients over public networks. The attack vector corresponds to techniques found in the MITRE ATT&CK framework under Denial of Service (T1499), specifically involving endpoint or network resource exhaustion via volumetric attacks that do not necessarily require high bandwidth but rather exploit inefficient resource allocation logic on the target system. This is particularly dangerous for microservices architectures where bRPC servers often handle high volumes of concurrent connections, as a single malicious request can destabilize an entire service instance without requiring persistent connection maintenance or complex multi-stage exploitation chains.
To mitigate this vulnerability, organizations must take immediate action to either upgrade their infrastructure or apply specific code patches. The recommended primary solution is to upgrade the Apache bRPC library to version 1.18.0 or later, which incorporates a fix that introduces strict limits on stream creation per request. Alternatively, for environments where upgrading immediately is not feasible, applying the patch associated with GitHub pull request number 3493 provides immediate protection. This mitigation strategy involves introducing a new configuration flag named `stream_max_streams_per_request`, which defaults to a value of sixty-four streams. With this fix in place, any RPC request that declares more stream identifiers than the configured limit will be rejected by the server before any response streams are allocated or created, thereby preventing the resource exhaustion attack vector from succeeding.
It is critical for system administrators and developers to note that while the default limit of sixty-four streams protects against abuse, it may inadvertently impact legitimate high-throughput applications. Applications with a genuine business requirement to accept more than sixty-four concurrent streams within a single RPC invocation must explicitly increase this flag value in their configuration settings after applying the patch or upgrading. Failure to adjust this parameter for such specific use cases will result in those valid requests being rejected, potentially causing functional regressions despite improved security posture. Therefore, a thorough review of application requirements is necessary before deploying the fix in production environments that rely on massive parallel stream handling within single RPC calls.