CVE-2026-84727 in bRPC
Summary
by MITRE • 10/21/2026
Use-after-free in the RTMP protocol implementation in Apache bRPC (version < 1.18.0) on all platforms allows a malicious RTMP peer to crash the process or potentially corrupt memory via a crafted Abort message.
Root Cause: When processing an RTMP Abort (protocol control message type 2), the RTMP policy implementation deleted the target RtmpChunkStream object. The send path (RtmpUnsentMessage::AppendAndDestroySelf -> RtmpChunkStream::SerializeMessage) runs concurrently on sender threads and dereferences the same RtmpChunkStream object without synchronization. If a remote peer sends an Abort message naming a chunk stream that is concurrently being used to serialize an outgoing message, the stream object is freed while still in use, resulting in a use-after-free. Additionally, deleting the chunk stream discarded its previous message header, so subsequent compressed (type-3) chunk headers on that stream could no longer be decoded.
Affected Scenarios: Any application using the bRPC RTMP protocol implementation (rtmp policy), either as an RTMP server or as an RTMP client, where the remote endpoint is untrusted. The attacker needs to send an Abort message targeting a chunk stream id that is concurrently used for sending, which can crash the process or lead to memory corruption.
How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3515
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in Apache bRPC versions prior to 1.18.0 represents a critical use-after-free flaw within the Real-Time Messaging Protocol implementation, specifically affecting all supported platforms. This security defect arises from improper synchronization mechanisms when handling protocol control messages, allowing an untrusted remote peer to trigger memory corruption or process termination through crafted network traffic. The core of the issue lies in the concurrent execution paths involved in processing incoming RTMP Abort messages and serializing outgoing data. When a malicious actor sends an Abort message targeting a specific chunk stream identifier, the bRPC implementation immediately deletes the corresponding RtmpChunkStream object to release resources associated with that stream. However, this deletion occurs without adequate locking or reference counting safeguards relative to other threads actively utilizing the same stream for outbound communication.
The technical root cause is rooted in a race condition between the message processing thread and the sender serialization threads. Specifically, when an Abort control message is received, the system invokes logic within RtmpUnsentMessage::AppendAndDestroySelf which subsequently calls RtmpChunkStream::SerializeMessage on concurrent sender threads. These sender threads attempt to dereference the same RtmpChunkStream object that has just been freed by the processing thread handling the Abort command. Because there is no synchronization mechanism preventing access to a deallocated memory region, this results in a classic use-after-free vulnerability. The attacker exploits this timing window by ensuring their crafted Abort message targets a chunk stream id that is currently being used for serialization of outgoing messages. This lack of atomicity allows the remote peer to corrupt heap memory or cause an immediate denial of service through segmentation faults when the application attempts to access invalid pointers.
Beyond simple process crashes, this vulnerability poses significant risks related to memory corruption and potential code execution depending on the specific allocator behavior and exploitability context. The destruction of the chunk stream object also discards its previous message header state. Consequently, subsequent compressed type-3 chunk headers sent by or received for that stream can no longer be decoded correctly due to missing historical context required for delta compression decoding in RTMP. This leads to protocol desynchronization and further instability within the connection session. The impact is severe because it affects any application utilizing the bRPC RTMP policy, whether acting as an RTMP server accepting connections or as a client initiating streams where the remote endpoint cannot be fully trusted.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, which describes situations where memory is accessed after it has been freed, leading to undefined behavior and potential security breaches. In terms of attack vectors, this falls under ATT&CK technique T1059, Command and Scripting Interpreter, if the corruption leads to code execution, or more broadly as a Denial of Service vector via resource exhaustion and process instability. The vulnerability highlights critical gaps in thread safety within high-performance networking libraries that prioritize throughput over strict synchronization overheads.
To mitigate this risk, organizations must take immediate action to update their dependencies. The primary remediation strategy is to upgrade Apache bRPC to version 1.18.0 or later, where the developers have implemented proper synchronization mechanisms to prevent concurrent access during stream deallocation. Alternatively, if upgrading is not immediately feasible due to compatibility constraints, administrators can apply a specific patch available via pull request number 3515 on the official Apache brpc GitHub repository. This patch introduces necessary locking logic around chunk stream operations to ensure that streams are only freed when no other threads hold references to them for serialization or processing purposes. Until these updates are applied, systems relying on this version of bRPC remain exposed to remote exploitation by any network peer capable of injecting RTMP control messages into the communication channel.