CVE-2026-82425: Apache bRPC: Reachable Assertion in Socket::OnInputEvent Allows Remote Denial of Service
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/EVFILTREAD) 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 -crashonfatallog is enabled (CHECK always terminates in OFFICIALBUILD/NDEBUG builds as well).
Affected Scenarios: Applications using bRPC clients with health check enabled (-healthcheckinterval). 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache bRPCto a version that resolves this vulnerability.Fixed in 1.18.0Patch 3510
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service condition?
Applications using bRPC clients with health checking enabled through -health_check_interval are affected when running bRPC versions earlier than 1.18.0. The issue applies on all platforms.
What must an attacker be able to do to trigger the crash?
The attacker must control or act as a remote peer that the bRPC client connects to. They can abort connections and immediately accept health-check probes to race connection teardown against socket revival.
Does exploitation always terminate the client process?
The assertion terminates the process when bRPC is built with glog, when -crash_on_fatal_log is enabled, and in OFFICIAL_BUILD/NDEBUG builds where CHECK always terminates.