{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 7.5,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "NONE",
              "integrityImpact": "HIGH",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-84747",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T14:38:39.421022Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-30T14:39:07.800Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "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 \u0026lt; 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.\u003cbr\u003e\u003cbr\u003eRoot Cause:\u003cbr\u003eThe method dispatch function FindMethodPropertyByURI() in bRPC\u0027s 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 \u0027/\u0027 nor is the asterisk-form \u0027*\u0027, contrary to RFC 9113 section 8.3.1, were not rejected.\u003cbr\u003e\u003cbr\u003eAffected Scenarios:\u003cbr\u003eDeployments 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.\u003cbr\u003e\u003cbr\u003eHow to Fix:\u003cbr\u003e(\u003cspan\u003eChoose one of the following options)\u003c/span\u003e\u003cbr\u003e1. Upgrade bRPC to version 1.18.0, which fixes this issue.\u003cbr\u003e\u003cspan\u003e2. Apply this patch: \u003c/span\u003e\u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://github.com/apache/brpc/pull/3512\"\u003ehttps://github.com/apache/brpc/pull/3512\u003c/a\u003e\u003cbr\u003e\u003cbr\u003eNote:\u003cbr\u003eAfter 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 \u0027/\u0027 nor equal \u0027*\u0027 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 \u003c 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\u0027s 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 \u0027/\u0027 nor is the asterisk-form \u0027*\u0027, 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 \u0027/\u0027 nor equal \u0027*\u0027 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-30T14:39:07.800Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"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\": {\"id\": \"CVE-2026-84747\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-10-30T14:38:39.421022Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-10-30T14:37:27.767Z\"}}], \"cna\": {\"title\": \"Apache bRPC: Access Control Bypass via HTTP Request Paths Containing Empty Path Segments\", \"source\": {\"discovery\": \"INTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Claude\"}], \"metrics\": [{\"other\": {\"type\": \"Textual description of severity\", \"content\": {\"text\": \"moderate\"}}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"vendor\": \"Apache Software Foundation\", \"product\": \"Apache bRPC\", \"versions\": [{\"status\": \"affected\", \"version\": \"0\", \"lessThan\": \"1.18.0\", \"versionType\": \"semver\"}], \"packageURL\": \"pkg:github/apache/brpc\", \"packageName\": \"apache/brpc\", \"collectionURL\": \"https://github.com\", \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb\", \"tags\": [\"vendor-advisory\"]}], \"x_generator\": {\"engine\": \"Vulnogram 0.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version \u003c 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\u0027s 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 \u0027/\u0027 nor is the asterisk-form \u0027*\u0027, 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 \u0027/\u0027 nor equal \u0027*\u0027 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.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version \u0026lt; 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.\u003cbr\u003e\u003cbr\u003eRoot Cause:\u003cbr\u003eThe method dispatch function FindMethodPropertyByURI() in bRPC\u0027s 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 \u0027/\u0027 nor is the asterisk-form \u0027*\u0027, contrary to RFC 9113 section 8.3.1, were not rejected.\u003cbr\u003e\u003cbr\u003eAffected Scenarios:\u003cbr\u003eDeployments 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.\u003cbr\u003e\u003cbr\u003eHow to Fix:\u003cbr\u003e(\u003cspan\u003eChoose one of the following options)\u003c/span\u003e\u003cbr\u003e1. Upgrade bRPC to version 1.18.0, which fixes this issue.\u003cbr\u003e\u003cspan\u003e2. Apply this patch: \u003c/span\u003e\u003ca target=\\\"_blank\\\" rel=\\\"nofollow\\\" href=\\\"https://github.com/apache/brpc/pull/3512\\\"\u003ehttps://github.com/apache/brpc/pull/3512\u003c/a\u003e\u003cbr\u003e\u003cbr\u003eNote:\u003cbr\u003eAfter 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 \u0027/\u0027 nor equal \u0027*\u0027 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.\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-436\", \"description\": \"CWE-436 Interpretation Conflict\"}]}], \"providerMetadata\": {\"orgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"shortName\": \"apache\", \"dateUpdated\": \"2026-10-21T12:13:28.033Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-84747\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-10-30T14:39:07.800Z\", \"dateReserved\": \"2026-09-02T08:58:24.479Z\", \"assignerOrgId\": \"f0158376-9dc2-43b6-827c-5f631a4d8d09\", \"datePublished\": \"2026-10-21T12:13:28.033Z\", \"assignerShortName\": \"apache\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}