---
id: "CVE-2026-84747"
kind: "vulnerability"
aliases: ["CVE-2026-84747"]
title: "Apache bRPC: padded URL paths bypass front-proxy access control rules"
severity: "medium"
cvss: null
epss: 0.00215
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["apache-brpc", "c++", "http", "package", "reverse-proxy", "self-hosted"]
not_affected_if: ["direct-exposure-only", "no-front-proxy-acl", "patched-1.18.0"]
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-84747", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-84747", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Apache bRPC: padded URL paths bypass front-proxy access control rules

Apache bRPC before 1.18.0 treats paths with empty segments such as //flags as the collapsed /flags when dispatching HTTP requests, while a front proxy checks only the literal path. A remote attacker can therefore reach builtin services the proxy was meant to block, such as /flags?setvalue=.

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

## How to check

- Check the bRPC version in the deployed build, for example `grep -i brpc` in the dependency manifest or the version reported by the server.
- Confirm whether a front proxy or gateway applies ACL rules to bRPC builtin paths such as `/flags`.
- Send a request to `//flags` through the proxy and see whether the bRPC server answers it.

## Fix

- Upgrade Apache bRPC to `1.18.0`.
- Or apply the patch from https://github.com/apache/brpc/pull/3512.
- Do not enable `-http_allow_empty_path_segments` on servers exposed to untrusted traffic.

## Timeline

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

## From the sources

Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.

Root Cause:
The method dispatch function FindMethodPropertyByURI() in bRPC's HTTP protocol splits the request path with a string splitter that skips empty fields, so paths containing empty path segments (consecutive slashes), such as //flags, /flags// and /flags//port, are dispatched to the same method as their collapsed form /flags. Per RFC 3986 these are distinct paths. A front proxy that enforces an ACL (e.g. blocking access to builtin services such as /flags) matches the collapsed form only, and therefore forwards the padded literal to the bRPC server, where it is dispatched as if it were the collapsed form. This differential allows //flags?setvalue= to reach a builtin service that /flags is not allowed to reach. Additionally, the HTTP/2 implementation never validated the :path pseudo-header, so requests without a :path, or with a :path that neither begins with '/' nor is the asterisk-form '*', contrary to RFC 9113 section 8.3.1, were not rejected.

Affected Scenarios:
Deployments of Apache bRPC behind a front proxy or gateway that performs access control (ACL) decisions on the literal request path, where the bRPC server accepts HTTP or HTTP/2 traffic from that proxy. In such deployments an attacker can send a path containing empty path segments to reach a resource that the front proxy intended to block.

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

Note:
After applying the fix, HTTP and HTTP/2 request paths containing empty path segments (consecutive slashes) are rejected by default, and HTTP/2 :path values that are empty or neither begin with '/' nor equal '*' are rejected. Deployments that depend on the previous lenient behavior can restore it by turning on the gflag -http_allow_empty_path_segments, which is not recommended for servers exposed to untrusted traffic.

---

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