CVE-2026-82231 in bRPC
Summary
by MITRE • 10/21/2026
A Thrift client in Apache bRPC (version < 1.18.0, built with WITH_THRIFT which is off by default) can be crashed by the server peer it talks to. When the server returns a T_EXCEPTION reply whose exception struct is malformed, the client decodes it without catching what Apache Thrift throws (TProtocolException, TTransportException or std::length_error). The exception unwinds out of the bthread task function and the process calls std::terminate(), terminating the whole process along with every other in-flight RPC.
This is the client response path, so the adversary is the server peer, which THREAT_MODEL.md treats as untrusted. It requires a WITH_THRIFT build (off by default).
How to Fix: 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3500
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Apache bRPC versions prior to 1.18.0 represents a critical reliability flaw within the Thrift client implementation, specifically when the library is compiled with the WITH_THRIFT flag enabled. Although this build configuration is disabled by default, any deployment that explicitly enables it exposes systems to a denial of service attack vector originating from untrusted server peers. The core technical issue lies in the exception handling mechanism during the decoding of server responses. When an Apache Thrift client receives a T_EXCEPTION reply containing a malformed exception structure, the underlying C++ standard library or Thrift runtime may throw exceptions such as TProtocolException, TTransportException, or std::length_error due to invalid data parsing. However, the bRPC implementation fails to catch these specific exceptions within the appropriate scope of the response processing logic.
This lack of proper error containment allows the unhandled exception to propagate up the call stack and unwind out of the bthread task function. In C++ applications utilizing thread-local storage or fiber-based concurrency models like those in bRPC, an uncaught exception escaping a worker thread typically triggers std::terminate(). This results in the immediate termination of the entire process rather than just failing the specific RPC request. Consequently, this flaw leads to a complete service outage for all concurrent operations handled by that process instance, effectively causing a denial of service against any clients relying on the affected bRPC server or proxy nodes.
From a threat modeling perspective, this vulnerability aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions and CWE-248: Unhandled Exception. The attack requires no authentication if the adversary controls the server peer, which is consistent with standard security assumptions where network peers are considered untrusted entities capable of sending malformed payloads to exploit parsing logic flaws. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1499: Endpoint Denial of Service, specifically through resource exhaustion via application crash, and potentially relates to TA0005: Defense Evasion if the attacker uses this to disrupt logging or monitoring systems by crashing security agents running on the same host.
The operational impact is severe for any production environment that relies on Thrift-based communication within bRPC. A single malformed response from a compromised or buggy server can take down an entire application instance, leading to significant downtime and potential data loss if in-flight transactions are not properly managed during the crash recovery phase. Mitigation strategies must prioritize upgrading Apache bRPC to version 1.18.0 or later, where this exception handling logic has been corrected to catch and handle these errors gracefully without terminating the process. Alternatively, organizations can apply the specific patch provided by the Apache community via pull request #3500 if an immediate upgrade is not feasible. Additionally, reviewing build configurations to ensure WITH_THRIFT remains disabled unless strictly necessary reduces the attack surface for this specific vulnerability class.