CVE-2026-82425 in bRPC
Summary
by MITRE • 10/22/2026
A reachable assertion in Apache bRPC (version < 1.18.0) on all platforms allows a malicious remote peer to crash the process, resulting in denial of service.
Root Cause: When a Socket with health checking enabled fails, Socket::WaitAndReset closes its file descriptor while the event dispatcher may still be delivering an input event (EPOLLIN/EVFILT_READ) that was fetched for the just-closed fd. If the health check then succeeds and revives the Socket, Socket::Address succeeds again while the fd is still -1 (the next write reconnects on demand). In that window, Socket::OnInputEvent hits CHECK(!(events & EPOLLIN)) (or the kqueue equivalent) because the Socket is addressable but has no fd. CHECK failures terminate the process when bRPC is built with glog or when the gflag -crash_on_fatal_log is enabled (CHECK always terminates in OFFICIAL_BUILD/NDEBUG builds as well).
Affected Scenarios: Applications using bRPC clients with health check enabled (-health_check_interval). A malicious remote peer that the client connects to can deliberately abort connections and immediately accept the health check probes, racing connection teardown against health check revival to trigger the assertion and abort the process.
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/3510
Note: After applying the fix, stale input events on a Socket revived without an fd are silently dropped instead of triggering the assertion. No user-visible interface or wire protocol is changed.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Apache bRPC versions prior to 1.18.0 represents a critical race condition within the socket management subsystem that leads to process termination and denial of service. This flaw specifically affects applications utilizing health checking features, where the system attempts to maintain connectivity with remote peers by periodically probing their availability. The core issue arises from an improper synchronization between connection teardown procedures initiated due to health check failures and subsequent reconnection logic triggered by successful health checks. When a socket fails its health check, the Socket::WaitAndReset function is invoked to close the associated file descriptor. However, this closure occurs while the event dispatcher may still be in the process of delivering an input event, such as EPOLLIN on Linux or EVFILT_READ on BSD systems, which was fetched for that now-closed file descriptor. This creates a temporal window where the socket object is considered addressable and valid by higher-level logic because it has successfully passed a subsequent health check, yet its underlying operating system resource, the file descriptor, remains invalid with a value of negative one.
The operational impact of this race condition is severe, resulting in an immediate crash of the bRPC process when specific conditions are met. The vulnerability manifests when Socket::OnInputEvent attempts to handle the stale input event associated with the revived socket. At this stage, the code executes a CHECK macro that verifies whether any read events are pending on the file descriptor. Since the file descriptor is closed and effectively non-existent, the check fails because it expects no read events but detects activity or simply validates against an invalid state depending on the build configuration. In environments built with glog logging enabled or when the crash_on_fatal_log flag is active, this CHECK failure triggers a fatal log entry followed by process termination. Furthermore, in production builds compiled without debug symbols (NDEBUG) or marked as OFFICIAL_BUILD, the CHECK macro invariably terminates the application regardless of logging settings. This behavior allows any malicious remote peer that supports health check protocols to deliberately cause denial of service against bRPC clients simply by rapidly aborting connections and immediately accepting new ones during the health check interval, effectively racing the connection teardown against revival logic.
From a technical classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution race conditions that lead to unintended system states. The specific mechanism involves a time-of-check-to-time-of-use flaw where the validity of the socket is assessed based on its logical state rather than its actual resource availability. In terms of offensive security frameworks, this can be mapped to MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically under the sub-category of Resource Exhaustion via application crashes. The attacker does not need to exploit a buffer overflow or code injection vulnerability; instead, they leverage legitimate protocol behaviors and timing windows to destabilize the target service. This highlights a significant gap in defensive programming practices where asynchronous event handling must strictly synchronize with resource lifecycle management to prevent access violations on closed handles.
Mitigation strategies for this vulnerability are straightforward but require immediate action due to its remote exploitability. The primary recommendation is to upgrade Apache bRPC to version 1.18.0 or later, which incorporates a fix that resolves the race condition by ensuring proper synchronization between socket closure and event dispatching. Alternatively, organizations running older versions can apply the patch provided in pull request number 3510 on the official Apache bRPC GitHub repository. This patch modifies the behavior of Socket::OnInputEvent to silently drop stale input events when a socket is revived without an associated file descriptor, thereby preventing the assertion failure and subsequent process crash. It is important to note that this fix does not alter any user-visible interfaces or wire protocols, ensuring compatibility with existing deployments while restoring stability. Administrators should verify their deployment configurations for enabled health checks and ensure that all client nodes are updated promptly to eliminate the window of opportunity for remote denial-of-service attacks.