Vulnerability-Lookup

CVE-2026-84747 (GCVE-0-2026-84747)

Vulnerability from cvelistv5 – Published: 2026-10-21 12:13 – Updated: 2026-10-30 14:39

Title

Apache bRPC: Access Control Bypass via HTTP Request Paths Containing Empty Path Segments

Summary

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.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-30 14:38 UTC

CWE

CWE-436 - Interpretation Conflict

Assigner

apache CNA under the mitre root

CNA scorecard B 76/100 over 1236 records in the last 180 days details

References

1 reference

URL	Tags
https://lists.apache.org/thread/2pf15ojj0vr7rtx95…	vendor-advisory

Impacted products

1 product

Vendor	Product	Version	CPE status
Apache Software Foundation	Apache bRPC	Affected: 0 , < 1.18.0 (semver)	guessed

Credits

Claude

Show details on NVD website

JSON

To clipboard

{
  "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": {
    "epss": {
      "cve": "CVE-2026-84747",
      "date": "2026-11-10",
      "epss": "0.0046",
      "percentile": "0.40147"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "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"
                  }
                ]
              }
            ],
            "source": "security@apache.org"
          }
        ],
        "cveTags": [],
        "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."
          },
          {
            "lang": "es",
            "value": "Conflicto de interpretaci\u00f3n en la implementaci\u00f3n del protocolo HTTP de Apache bRPC (versiones anteriores a la 1.18.0) en todas las plataformas permite a atacantes remotos eludir las reglas de control de acceso impuestas por un proxy frontal.\\n\\nCausa ra\u00edz:\\nLa funci\u00f3n de despacho de m\u00e9todos FindMethodPropertyByURI() en el protocolo HTTP de bRPC divide la ruta de la solicitud con un separador de cadenas que omite los campos vac\u00edos, de modo que las rutas que contienen segmentos de ruta vac\u00edos (barras consecutivas), como //flags, /flags// y /flags//port, se despachan al mismo m\u00e9todo que su forma colapsada /flags. Seg\u00fan la RFC?3986, estas son rutas distintas. Un proxy frontal que aplica una ACL (p.?ej., bloqueando el acceso a servicios incorporados como /flags) coincide solo con la forma colapsada y, por lo tanto, reenv\u00eda el literal con relleno al servidor bRPC, donde se despacha como si fuera la forma colapsada. Esta diferencia permite que //flags?setvalue= acceda a un servicio incorporado al que /flags no tiene permitido acceder. Adem\u00e1s, la implementaci\u00f3n de HTTP/2 nunca valid\u00f3 el pseudo?header :path, de modo que las solicitudes sin un :path, o con un :path que no comienza con \u2019/\u2019 ni es la forma de asterisco \u2019*\u2019, contrarias a la RFC?9113 secci\u00f3n?8.3.1, no fueron rechazadas.\\n\\nEscenarios afectados:\\nImplementaciones de Apache bRPC detr\u00e1s de un proxy frontal o pasarela que realiza decisiones de control de acceso (ACL) sobre la ruta literal de la solicitud, donde el servidor bRPC acepta tr\u00e1fico HTTP o HTTP/2 de ese proxy. En dichas implementaciones, un atacante puede enviar una ruta que contenga segmentos de ruta vac\u00edos para alcanzar un recurso que el proxy frontal pretend\u00eda bloquear.\\n\\nC\u00f3mo solucionar:\\n(Elija una de las siguientes opciones)\\n1. Actualice bRPC a la versi\u00f3n 1.18.0, que corrige este problema.\\n2. Aplique este parche: https://github.com/apache/brpc/pull/3512\\n\\nNota:\\nDespu\u00e9s de aplicar la correcci\u00f3n, las rutas de solicitud HTTP y HTTP/2 que contengan segmentos de ruta vac\u00edos (barras consecutivas) se rechazan por defecto, y los valores de :path de HTTP/2 que est\u00e9n vac\u00edos o que no comiencen con \u2019/\u2019 ni sean \u2019*\u2019 tambi\u00e9n se rechazan. Las implementaciones que dependan del comportamiento indulgente anterior pueden restaurarlo activando la gflag -http_allow_empty_path_segments, lo cual no se recomienda para servidores expuestos a tr\u00e1fico no confiable."
          }
        ],
        "id": "CVE-2026-84747",
        "lastModified": "2026-10-30T15:16:56.130",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "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"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 3.6,
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-84747",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T14:38:39.421022Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-10-21T13:20:03.847",
        "references": [
          {
            "source": "security@apache.org",
            "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
          }
        ],
        "sourceIdentifier": "security@apache.org",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-436"
              }
            ],
            "source": "security@apache.org",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "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:37:27.767Z",
              "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"
    }
  }
}

FKIE_CVE-2026-84747

Vulnerability from fkie_nvd - Published: 2026-10-21 13:20 - Updated: 2026-10-30 15:16

Severity

7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Summary

References

	URL	Tags
	security@apache.org	https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "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"
            }
          ]
        }
      ],
      "source": "security@apache.org"
    }
  ],
  "cveTags": [],
  "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."
    },
    {
      "lang": "es",
      "value": "Conflicto de interpretaci\u00f3n en la implementaci\u00f3n del protocolo HTTP de Apache bRPC (versiones anteriores a la 1.18.0) en todas las plataformas permite a atacantes remotos eludir las reglas de control de acceso impuestas por un proxy frontal.\\n\\nCausa ra\u00edz:\\nLa funci\u00f3n de despacho de m\u00e9todos FindMethodPropertyByURI() en el protocolo HTTP de bRPC divide la ruta de la solicitud con un separador de cadenas que omite los campos vac\u00edos, de modo que las rutas que contienen segmentos de ruta vac\u00edos (barras consecutivas), como //flags, /flags// y /flags//port, se despachan al mismo m\u00e9todo que su forma colapsada /flags. Seg\u00fan la RFC?3986, estas son rutas distintas. Un proxy frontal que aplica una ACL (p.?ej., bloqueando el acceso a servicios incorporados como /flags) coincide solo con la forma colapsada y, por lo tanto, reenv\u00eda el literal con relleno al servidor bRPC, donde se despacha como si fuera la forma colapsada. Esta diferencia permite que //flags?setvalue= acceda a un servicio incorporado al que /flags no tiene permitido acceder. Adem\u00e1s, la implementaci\u00f3n de HTTP/2 nunca valid\u00f3 el pseudo?header :path, de modo que las solicitudes sin un :path, o con un :path que no comienza con \u2019/\u2019 ni es la forma de asterisco \u2019*\u2019, contrarias a la RFC?9113 secci\u00f3n?8.3.1, no fueron rechazadas.\\n\\nEscenarios afectados:\\nImplementaciones de Apache bRPC detr\u00e1s de un proxy frontal o pasarela que realiza decisiones de control de acceso (ACL) sobre la ruta literal de la solicitud, donde el servidor bRPC acepta tr\u00e1fico HTTP o HTTP/2 de ese proxy. En dichas implementaciones, un atacante puede enviar una ruta que contenga segmentos de ruta vac\u00edos para alcanzar un recurso que el proxy frontal pretend\u00eda bloquear.\\n\\nC\u00f3mo solucionar:\\n(Elija una de las siguientes opciones)\\n1. Actualice bRPC a la versi\u00f3n 1.18.0, que corrige este problema.\\n2. Aplique este parche: https://github.com/apache/brpc/pull/3512\\n\\nNota:\\nDespu\u00e9s de aplicar la correcci\u00f3n, las rutas de solicitud HTTP y HTTP/2 que contengan segmentos de ruta vac\u00edos (barras consecutivas) se rechazan por defecto, y los valores de :path de HTTP/2 que est\u00e9n vac\u00edos o que no comiencen con \u2019/\u2019 ni sean \u2019*\u2019 tambi\u00e9n se rechazan. Las implementaciones que dependan del comportamiento indulgente anterior pueden restaurarlo activando la gflag -http_allow_empty_path_segments, lo cual no se recomienda para servidores expuestos a tr\u00e1fico no confiable."
    }
  ],
  "id": "CVE-2026-84747",
  "lastModified": "2026-10-30T15:16:56.130",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "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"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 3.6,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-84747",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-10-30T14:38:39.421022Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-10-21T13:20:03.847",
  "references": [
    {
      "source": "security@apache.org",
      "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
    }
  ],
  "sourceIdentifier": "security@apache.org",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-436"
        }
      ],
      "source": "security@apache.org",
      "type": "Secondary"
    }
  ]
}

GHSA-94R6-XP5C-QWQ5

Vulnerability from github – Published: 2026-10-21 15:42 – Updated: 2026-10-30 15:34

Details

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.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-84747"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-21T13:20:03Z",
    "severity": "HIGH"
  },
  "details": "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.",
  "id": "GHSA-94r6-xp5c-qwq5",
  "modified": "2026-10-30T15:34:10Z",
  "published": "2026-10-21T15:42:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84747"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-84747 (GCVE-0-2026-84747)

FKIE_CVE-2026-84747

GHSA-94R6-XP5C-QWQ5

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour