---
id: "CVE-2026-86147"
kind: "vulnerability"
aliases: ["CVE-2026-86147"]
title: "Apache bRPC: builtin services let remote users write files and stall profilers"
severity: "unknown"
cvss: null
epss: 0.00203
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["apache-brpc", "b\u0580pc", "c++", "package", "self-hosted"]
not_affected_if: ["bvar-dump-disabled", "internal-network-only", "version-1.18.0-or-later"]
published_at: "2026-10-21T13:20:04+00:00"
first_seen_at: "2026-10-23T21:57:28+00:00"
updated_at: "2026-10-25T05:02:23+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86147", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-86147", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Apache bRPC: builtin services let remote users write files and stall profilers

Apache bRPC versions before 1.18.0 expose builtin /flags and /pprof services on the RPC port, letting a remote attacker repoint the bvar dump path to create directories and overwrite files as the server process. The same services let an attacker hold the process-wide CPU or contention profiler for an arbitrarily long time.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the bRPC version the server links against, for example `grep -r brpc` in the build files or the version in the package manifest, and see whether it is below `1.18.0`
- Check whether the builtin services are reachable from untrusted networks on the RPC port, for example with `curl http://<host>:<port>/flags`

## Fix

- Upgrade bRPC to `1.18.0`
- Or apply the patch from https://github.com/apache/brpc/pull/3523
- Restrict access to the builtin service port from untrusted networks until upgraded

## Timeline

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

## From the sources

External control of file name or path and uncontrolled resource consumption in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers who can reach the builtin service port to create directories and truncate/overwrite files with the privileges of the server process, or to hold the process-wide CPU/contention profiler for an arbitrarily long time.

Root Cause:
1. The builtin /flags service allows gflags carrying a validator to be modified at runtime via ?setvalue=. The bvar/mbvar dump path gflags (bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) were registered with an accept-anything validator whose only purpose was to wake the dumping thread. A remote attacker could therefore repoint the dump path (e.g. GET /flags/bvar_dump_file?setvalue=/victim/dir/target followed by GET /flags/bvar_dump?setvalue=true, or the equivalent for mbvar_dump_file, which is used verbatim without a forced suffix), making the dumping thread recursively create directories and open/truncate files at attacker-chosen locations. Tab names in bvar_dump_tabs were appended to the path without sanitization, allowing '..' to escape the configured directory.
2. The /pprof builtin service did not clamp the ?seconds= parameter to FLAGS_max_profiling_seconds (a limit that /hotspots enforced). A single request such as ?seconds=2147483647 made the handler sleep for decades while holding the process-wide gperftools CPU profiler or bthread contention profiler, so /hotspots/cpu and /hotspots/contention returned 503 for everyone else during that time.

Affected Scenarios:
Any Apache bRPC server exposing the builtin services (enabled by default on the same port as normal RPC traffic) to untrusted networks.

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

Note:
After the fix, bvar_dump_file, bvar_dump_tabs and mbvar_dump_file can no longer be modified at runtime through the /flags builtin service. They can still be changed programmatically via google::SetCommandLineOption(), taking effect on the next dump cycle. The profiling duration of /pprof is now capped by the -max_profiling_seconds gflag (default 300 seconds), which can be adjusted by the server owner.

---

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