---
id: "CVE-2026-82942"
kind: "vulnerability"
aliases: ["CVE-2026-82942"]
title: "Apache bRPC: RDMA data race lets a remote client crash the server"
severity: "high"
cvss: null
epss: 0.0014
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["brpc", "c++", "package", "rdma", "self-hosted"]
not_affected_if: ["default-config", "no-rdma"]
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:27+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82942", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-82942", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Apache bRPC: RDMA data race lets a remote client crash the server

A race between the TCP and RDMA input paths in Apache bRPC's RDMA transport corrupts a shared input buffer and parser state. A remote unauthenticated client that completed the RDMA handshake can crash the server process (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, e.g. `grep -rn 'brpc' CMakeLists.txt` or the lock file, and see whether it is below `1.18.0`
- Check whether the server was built with `BRPC_WITH_RDMA` and serves `rdma://` or `SOCKET_MODE_RDMA` sockets
- Deployments without RDMA are not affected

## Fix

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

## Timeline

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

## From the sources

A data race in the RDMA transport of Apache bRPC (versions < 1.18.0) allows a remote client to crash the server process (denial of service) when RDMA is enabled at build time and runtime.

Root Cause:
When a bRPC server negotiates RDMA with a client, the handshake completes on the TCP fd, but the server kept parsing that fd afterwards as if it were still an RPC channel. The TCP-fd input stream and the RDMA QP input stream (driven by CQ events) shared the same Socket::_read_buf, preferred_index and parsing_context without synchronization. In addition, CQ event processing could start while the handshake parsing was still in progress, and the handshake ACK phase could consume bytes belonging to the next protocol. A remote, unauthenticated client that has completed the RDMA handshake can send data on the TCP fd at the same time RDMA messages are being processed, corrupting the shared input buffer and parser state and crashing the server process (CWE-362, availability impact).

Affected Scenarios:
Use a bRPC server with RDMA support enabled (built with BRPC_WITH_RDMA and serving rdma:// / SOCKET_MODE_RDMA sockets) and accept connections from untrusted clients. Deployments without RDMA are not affected.

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/3505

---

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