Live › vulnerability › CVE-2026-82425
Go to dashboardA race in bRPC's socket health checking can trigger a failed assertion when a remote peer aborts connections while health checks revive them. The client process terminates, causing denial of service.
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.
Applications that run bRPC clients with health checking enabled () and connect to peers that may be malicious or untrusted. The crash needs a peer that deliberately aborts connections and answers health probes at the right moment. Servers only, or clients with health checking off, are not described as exposed.
-health_check_intervalNo product ranges from the sources yet.
unknown for the exact command, the sources do not say how it is pinned-health_check_interval set to a positive value-crash_on_fatal_log is enabled or bRPC is built with glog1.18.0Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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)
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-82425")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.