Apache bRPC up to 1.17.x HTTP Protocol FindMethodPropertyByURI access control

Summaryinfo

A vulnerability described as critical has been identified in Apache bRPC up to 1.17.x. The impacted element is the function FindMethodPropertyByURI of the component HTTP Protocol. Such manipulation leads to access control. This vulnerability is uniquely identified as CVE-2026-84747. The attack can be launched remotely. No exploit exists. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability was found in Apache bRPC up to 1.17.x. It has been rated as critical. Affected by this issue is the function FindMethodPropertyByURI of the component HTTP Protocol. The manipulation with an unknown input leads to a access control vulnerability. Using CWE to declare the problem leads to CWE-284. The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Impacted is confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at lists.apache.org. This vulnerability is handled as CVE-2026-84747 since 09/02/2026. The exploitation is known to be easy. The attack may be launched remotely. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 10/21/2026). The MITRE ATT&CK project declares the attack technique as T1068.

Upgrading to version 1.18.0 eliminates this vulnerability.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• Apache

Name

• bRPC

Version

• 1.0
• 1.1
• 1.2
• 1.3
• 1.4
• 1.5
• 1.6
• 1.7
• 1.8
• 1.9
• 1.10
• 1.11
• 1.12
• 1.13
• 1.14
• 1.15
• 1.16
• 1.17

License

• open-source

Website

• Vendor: https://www.apache.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion