CVE-2026-84747 in bRPC
Summary
by MITRE • 10/21/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability in Apache bRPC versions prior to 1.18.0 represents a critical interpretation conflict within the HTTP protocol implementation that enables remote attackers to bypass access control rules enforced by front-end proxies. This flaw stems from a fundamental discrepancy between how the bRPC server normalizes request paths and how external security gateways evaluate them for authorization decisions. Specifically, the method dispatch function FindMethodPropertyByURI utilizes a string splitting mechanism that inherently skips empty fields when processing the URL path. Consequently, distinct URI structures containing consecutive slashes, such as //flags or /flags//port, are internally normalized to their collapsed form, effectively treating them identically to standard paths like /flags. This normalization behavior directly contradicts RFC 3986, which mandates that these paths be treated as distinct entities due to the presence of empty path segments between delimiters.
The operational impact of this vulnerability is severe in deployments where Apache bRPC operates behind a front proxy or gateway responsible for enforcing Access Control Lists. In such architectures, security policies are typically applied based on the literal request path received from the client before forwarding it to the backend service. If an administrator configures the front proxy to block access to sensitive internal endpoints like /flags by matching against that specific string, the protection mechanism fails when confronted with a maliciously crafted URI containing empty segments. Because the front proxy matches only the collapsed form or standard literal without accounting for normalization differences, it permits requests using padded literals such as //flags?setvalue= to pass through unimpeded. Once these requests reach the bRPC server, they are dispatched to the very method that was intended to be restricted, effectively circumventing the perimeter security controls and exposing internal services to unauthorized access.
Furthermore, the HTTP/2 implementation within affected versions exhibits an additional layer of vulnerability due to insufficient validation of the :path pseudo-header. According to RFC 9113 section 8.3.1, valid :path values must either begin with a forward slash or be the asterisk-form used for OPTIONS requests. However, the bRPC HTTP/2 handler fails to reject connections where this header is missing or contains invalid formats that do not adhere to these standards. This lack of strict validation allows attackers to exploit edge cases in path parsing further compounding the risk of unauthorized access and potentially facilitating other forms of protocol abuse by sending malformed requests that bypass standard routing logic entirely.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as well as CWE-697, Incorrect Comparison, because the system incorrectly equates distinct URI structures based on a flawed normalization algorithm rather than strict string comparison or proper RFC compliance. From an ATT&CK perspective, this technique is consistent with T1059 Command and Scripting Interpreter subcategories involving web protocols, specifically leveraging protocol-level ambiguities to evade detection mechanisms like WAFs or reverse proxy ACLs. The attack vector allows for remote exploitation without authentication, making it a high-severity issue that compromises the integrity of access control boundaries in microservice architectures relying on bRPC.
To mitigate this risk, organizations must upgrade Apache bRPC to version 1.18.0 or later, which resolves these parsing inconsistencies by enforcing stricter adherence to RFC standards for both HTTP and HTTP/2 traffic. Alternatively, applying the specific patch available via GitHub pull request #3512 provides a targeted fix without requiring a full version upgrade. It is important to note that after implementing either solution, the server will reject requests containing empty path segments or invalid :path values by default. Deployments relying on legacy lenient behavior can technically restore it using the gflag -http_allow_empty_path_segments, but this practice is strongly discouraged for any service exposed to untrusted networks as it re-introduces the vulnerability and undermines security best practices regarding strict input validation and path normalization.