---
id: "CVE-2026-82425"
kind: "vulnerability"
aliases: ["CVE-2026-82425"]
title: "Apache bRPC: assertion lets a remote peer crash the client process"
severity: "unknown"
cvss: null
epss: 0.00147
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["brpc", "c++", "package", "rpc-clients", "self-hosted"]
not_affected_if: ["health-check-disabled", "trusted-peers-only"]
published_at: "2026-10-21T13:20:03+00:00"
first_seen_at: "2026-10-23T21:57:28+00:00"
updated_at: "2026-10-25T05:02:30+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82425", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-82425", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Apache bRPC: assertion lets a remote peer crash the client process

A 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, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the bRPC version in use: `unknown` for the exact command, the sources do not say how it is pinned
- Check whether clients start with `-health_check_interval` set to a positive value
- Check whether `-crash_on_fatal_log` is enabled or bRPC is built with glog

## Fix

- Upgrade bRPC to `1.18.0`
- Or apply the patch from https://github.com/apache/brpc/pull/3510

## Timeline

- 2026-10-23T21:57:28+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-82425
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-82425

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_