Live › vulnerability › CVE-2026-84747
Go to dashboardApache 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 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.
Deployments of Apache bRPC that sit behind a proxy or gateway making access control decisions on the literal request path, and that accept HTTP or HTTP/2 traffic from that proxy. A bRPC server reached directly without such a proxy in front of it has no ACL to bypass, so the flaw does not change its exposure.
No product ranges from the sources yet.
grep -i brpc in the dependency manifest or the version reported by the server./flags.//flags through the proxy and see whether the bRPC server answers it.1.18.0.-http_allow_empty_path_segments on servers exposed to untrusted traffic.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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)
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-84747")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.