CVE-2026-81755 json
Apache bRPC: Uncontrolled Resource Consumption via Excessive Streams in a Single RPC Request
published 21d ago modified 12d ago also EUVD-2026-107189
- cvss
- 7.5
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.7%
- EPSS 0.7% chance of exploitation in 30 days, percentile 54%
- public exploits
- 0
- none known
Summary
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.
Patch / fix
- Apache Software Foundation Apache bRPC 1.18.0
Is CVE-2026-81755 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCISA SSVC
- Exploitation
- none
- Automatable
- yes
- Technical impact
- partial
- Assessed
- 12d ago
Exploit prediction
0.73% chance of exploitation in the next 30 days, higher than 54% of all scored CVEs (FIRST EPSS, 2026-11-11).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CISA ADP | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| CNA | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Affected products
- Apache Software Foundation Apache bRPC
Classification
- Weakness
-
- CWE-400 Uncontrolled Resource Consumption
References
-
lists.apache.org
/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb
vendor-advisory
Sources
- CVE List CVE-2026-81755
- NVD CVE-2026-81755
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.
CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.