Live › vulnerability › CVE-2026-79704
Go to dashboardA bRPC client that creates several streams in one RPC reads past the end of the server's response list when the server returns too few stream identifiers. A malicious or compromised server, or an on-path attacker, can crash the client process or leak unintended memory into later stream handling.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only bRPC clients that use multi-stream RPC, creating more than one stream in a single call, are exposed. The danger comes from the server side of the connection, so clients that talk only to trusted servers over a trusted network are at lower risk, but a malicious server or an on-path attacker is enough to trigger it. Services that use bRPC only as a server or that never create multiple streams per RPC can skip it.
No product ranges from the sources yet.
grep -r brpc in the build files or ldd on the client binary, and see whether it falls in 1.11.0 through 1.17.0.1.18.0.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
An out-of-bounds read vulnerability exists in the streaming RPC client of Apache bRPC (versions 1.11.0 through 1.17.0) on all platforms. A client that creates multiple streams in a single RPC expects the server response to carry exactly one extra_stream_id for every additional stream. The response handling path indexed the returned identifiers using the locally created stream count without first validating the size of the returned list, so a malicious or compromised server (or an on-path attacker) can trigger an out-of-bounds read in the client by returning a malformed StreamSettings response with fewer extra_stream_ids than expected. This may crash the client process (denial of service) or leak unintended memory contents into subsequent stream handling; surplus identifiers have no valid client-stream mapping and are processed inconsistently.
Root Cause: Since bRPC 1.11.0, a client can create multiple streams in one RPC via batch StreamCreate. The expected behavior is that the server response must return exactly (N-1) extra_stream_ids, where N is the number of locally created streams. In Controller::HandleStreamConnection, the response path reads extra_stream_ids[i-1] for each additional local stream without first comparing the returned list size with (N-1). If the server returns fewer identifiers, the read runs past the end of the returned list (out-of-bounds read); if it returns more, the surplus identifiers have no corresponding client-side stream.
Affected Scenarios: A bRPC client using multi-stream RPC (creating more than one stream in a single RPC) that connects to an untrusted, malicious, or compromised server or to a server reached through an untrusted network path. The server sends a malformed StreamSettings response to trigger the issue.
How to Fix: (Choose one of the following options)
Note: The fix makes the client reject responses whose extra_stream_ids count does not exactly match the number of additional client streams. Such mismatched responses now fail the RPC with ERESPONSE and go through the existing stream cleanup path, instead of being partially processed.
This page as .md · .json · in your agent: get_signal("CVE-2026-79704")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.