153 lines
9.8 KiB
JSON
153 lines
9.8 KiB
JSON
{
|
|
"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-30T14:39:07.800Z"
|
|
},
|
|
"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.<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."
|
|
}
|
|
]
|
|
}
|
|
],
|
|
"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"
|
|
}
|
|
},
|
|
"adp": [
|
|
{
|
|
"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"
|
|
}
|
|
}
|
|
}
|
|
],
|
|
"title": "CISA ADP Vulnrichment",
|
|
"providerMetadata": {
|
|
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
|
|
"shortName": "CISA-ADP",
|
|
"dateUpdated": "2026-10-30T14:39:07.800Z"
|
|
}
|
|
}
|
|
]
|
|
}
|
|
} |