{"api_version":"1","generated_at":"2026-10-21T16:50:02+00:00","cve":"CVE-2026-84747","urls":{"html":"https://cve.report/CVE-2026-84747","api":"https://cve.report/api/cve/CVE-2026-84747.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-84747","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-84747"},"summary":{"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.","state":"PUBLISHED","assigner":"apache","published_at":"2026-10-21 13:20:03","updated_at":"2026-10-21 13:20:03"},"problem_types":["CWE-436","CWE-436 CWE-436 Interpretation Conflict"],"metrics":[],"references":[{"url":"https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb","name":"https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb","refsource":"security@apache.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-84747","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-84747","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache bRPC","version":"affected 1.18.0 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Claude","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"collectionURL":"https://github.com","defaultStatus":"unaffected","packageName":"apache/brpc","packageURL":"pkg:github/apache/brpc","product":"Apache bRPC","vendor":"Apache Software Foundation","versions":[{"lessThan":"1.18.0","status":"affected","version":"0","versionType":"semver"}]}],"credits":[{"lang":"en","type":"finder","value":"Claude"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version &lt; 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.<br><br>Root Cause:<br>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.<br><br>Affected Scenarios:<br>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.<br><br>How to Fix:<br>(<span>Choose one of the following options)</span><br>1. Upgrade bRPC to version 1.18.0, which fixes this issue.<br><span>2. Apply this patch: </span><a target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3512\">https://github.com/apache/brpc/pull/3512</a><br><br>Note:<br>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."}],"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."}],"metrics":[{"other":{"content":{"text":"moderate"},"type":"Textual description of severity"},"scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-436","description":"CWE-436 Interpretation Conflict","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-21T12:13:28.033Z","orgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","shortName":"apache"},"references":[{"tags":["vendor-advisory"],"url":"https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"}],"source":{"discovery":"INTERNAL"},"title":"Apache bRPC: Access Control Bypass via HTTP Request Paths Containing Empty Path Segments","x_generator":{"engine":"Vulnogram 0.2.0"}}},"cveMetadata":{"assignerOrgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","assignerShortName":"apache","cveId":"CVE-2026-84747","datePublished":"2026-10-21T12:13:28.033Z","dateReserved":"2026-09-02T08:58:24.479Z","dateUpdated":"2026-10-21T12:13:28.033Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-21 13:20:03","lastModifiedDate":"2026-10-21 13:20:03","problem_types":["CWE-436","CWE-436 CWE-436 Interpretation Conflict"],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"84747","Ordinal":"1","Title":"Apache bRPC: Access Control Bypass via HTTP Request Paths Contai","CVE":"CVE-2026-84747","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"84747","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"Apache bRPC: Access Control Bypass via HTTP Request Paths Contai"}]}}}