{"id":"CVE-2026-84747","state":"PUBLISHED","title":"Apache bRPC: Access Control Bypass via HTTP Request Paths Containing Empty Path Segments","description":"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.","publishedAt":"2026-10-21T12:13:28.033Z","updatedAt":"2026-10-30T14:39:07.800Z","severity":{"score":7.5,"label":"High","version":"3.1","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","source":"CISA-ADP"},"assigner":"apache","products":["Apache Software Foundation Apache bRPC"],"affected":[{"vendor":"Apache Software Foundation","product":"Apache bRPC","packageName":"apache/brpc","packageURL":"pkg:github/apache/brpc","defaultStatus":"unaffected","versions":[{"version":"0","status":"affected","lessThan":"1.18.0","versionType":"semver"}],"collectionURL":"https://github.com"}],"references":["https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"],"weaknesses":["CWE-436"],"ingestedAt":"2026-10-30T14:42:06.476Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2026/84xxx/CVE-2026-84747.json","commit":"0ff1733868ef02c01656a9ecae3f9062c2a9ae12","baselineCommit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-84747","state":"PUBLISHED","datePublished":"2026-10-21T12:13:28.033Z","dateUpdated":"2026-10-30T14:39:07.800Z","assignerShortName":"apache","assignerOrgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","dateReserved":"2026-09-02T08:58:24.479Z"},"containers":{"cna":{"title":"Apache bRPC: Access Control Bypass via HTTP Request Paths Containing Empty Path Segments","descriptions":[{"lang":"en","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."}],"affected":[{"vendor":"Apache Software Foundation","product":"Apache bRPC","packageName":"apache/brpc","packageURL":"pkg:github/apache/brpc","defaultStatus":"unaffected","versions":[{"version":"0","status":"affected","lessThan":"1.18.0","versionType":"semver"}],"collectionURL":"https://github.com"}],"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"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-436","description":"CWE-436 Interpretation Conflict","lang":"en","type":"CWE"}]}],"providerMetadata":{"shortName":"apache","orgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","dateUpdated":"2026-10-21T12:13:28.033Z"},"source":{"discovery":"INTERNAL"},"credits":[{"lang":"en","value":"Claude","type":"finder"}],"x_generator":{"engine":"Vulnogram 0.2.0"}},"adp":[{"title":"CISA ADP Vulnrichment","metrics":[{"cvssV3_1":{"scope":"UNCHANGED","version":"3.1","baseScore":7.5,"attackVector":"NETWORK","baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","integrityImpact":"HIGH","userInteraction":"NONE","attackComplexity":"LOW","availabilityImpact":"NONE","privilegesRequired":"NONE","confidentialityImpact":"NONE"}},{"other":{"type":"ssvc","content":{"timestamp":"2026-10-30T14:38:39.421022Z","id":"CVE-2026-84747","options":[{"Exploitation":"none"},{"Automatable":"yes"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}}],"providerMetadata":{"shortName":"CISA-ADP","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","dateUpdated":"2026-10-30T14:39:07.800Z"}}]}}}