{
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"cveMetadata": {
"cveId": "CVE-2026-84747",
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"state": "PUBLISHED",
"assignerShortName": "apache",
"dateReserved": "2026-09-02T08:58:24.479Z",
"datePublished": "2026-10-21T12:13:28.033Z",
"dateUpdated": "2026-10-21T12:13:28.033Z"
},
"containers": {
"cna": {
"providerMetadata": {
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache",
"dateUpdated": "2026-10-21T12:13:28.033Z"
},
"title": "Apache bRPC: Access Control Bypass via HTTP Request Paths Containing Empty Path Segments",
"problemTypes": [
{
"descriptions": [
{
"description": "CWE-436 Interpretation Conflict",
"lang": "en",
"cweId": "CWE-436",
"type": "CWE"
}
]
}
],
"source": {
"discovery": "INTERNAL"
},
"affected": [
{
"vendor": "Apache Software Foundation",
"product": "Apache bRPC",
"packageURL": "pkg:github/apache/brpc",
"versions": [
{
"status": "affected",
"version": "0",
"lessThan": "1.18.0",
"versionType": "semver"
}
],
"defaultStatus": "unaffected",
"collectionURL": "https://github.com",
"packageName": "apache/brpc"
}
],
"descriptions": [
{
"value": "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.\n\nRoot Cause:\nThe 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.\n\nAffected Scenarios:\nDeployments 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.\n\nHow to Fix:\n(Choose one of the following options)\n1. Upgrade bRPC to version 1.18.0, which fixes this issue.\n2. Apply this patch: https://github.com/apache/brpc/pull/3512 \n\nNote:\nAfter 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.",
"lang": "en",
"supportingMedia": [
{
"type": "text/html",
"base64": false,
"value": "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."
}
]
}
],
"references": [
{
"url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb",
"tags": [
"vendor-advisory"
]
}
],
"metrics": [
{
"other": {
"type": "Textual description of severity",
"content": {
"text": "moderate"
}
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"credits": [
{
"lang": "en",
"value": "Claude",
"type": "finder"
}
],
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
}
}