CVE-2026-84747

{
  "id": "CVE-2026-84747",
  "sourceIdentifier": "[email protected]",
  "published": "2026-10-21T13:20:03.847",
  "lastModified": "2026-10-30T15:16:56.130",
  "vulnStatus": "Deferred",
  "cveTags": [],
  "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."
    },
    {
      "lang": "es",
      "value": "Conflicto de interpretación en la implementación 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íz:\\nLa función de despacho de métodos FindMethodPropertyByURI() en el protocolo HTTP de bRPC divide la ruta de la solicitud con un separador de cadenas que omite los campos vacíos, de modo que las rutas que contienen segmentos de ruta vacíos (barras consecutivas), como //flags, /flags// y /flags//port, se despachan al mismo método que su forma colapsada /flags. Según 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ía 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ás, la implementación de HTTP/2 nunca validó el pseudo?header :path, de modo que las solicitudes sin un :path, o con un :path que no comienza con ’/’ ni es la forma de asterisco ’*’, contrarias a la RFC?9113 sección?8.3.1, no fueron rechazadas.\\n\\nEscenarios afectados:\\nImplementaciones de Apache bRPC detrás 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áfico HTTP o HTTP/2 de ese proxy. En dichas implementaciones, un atacante puede enviar una ruta que contenga segmentos de ruta vacíos para alcanzar un recurso que el proxy frontal pretendía bloquear.\\n\\nCómo solucionar:\\n(Elija una de las siguientes opciones)\\n1. Actualice bRPC a la versión 1.18.0, que corrige este problema.\\n2. Aplique este parche: https://github.com/apache/brpc/pull/3512\\n\\nNota:\\nDespués de aplicar la corrección, las rutas de solicitud HTTP y HTTP/2 que contengan segmentos de ruta vacíos (barras consecutivas) se rechazan por defecto, y los valores de :path de HTTP/2 que estén vacíos o que no comiencen con ’/’ ni sean ’*’ también 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áfico no confiable."
    }
  ],
  "affected": [
    {
      "source": "[email protected]",
      "affectedData": [
        {
          "vendor": "Apache Software Foundation",
          "product": "Apache bRPC",
          "defaultStatus": "unaffected",
          "collectionURL": "https://github.com",
          "packageName": "apache/brpc",
          "packageURL": "pkg:github/apache/brpc",
          "versions": [
            {
              "version": "0",
              "lessThan": "1.18.0",
              "versionType": "semver",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ],
  "metrics": {
    "cvssMetricV31": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
          "baseScore": 7.5,
          "baseSeverity": "HIGH",
          "attackVector": "NETWORK",
          "attackComplexity": "LOW",
          "privilegesRequired": "NONE",
          "userInteraction": "NONE",
          "scope": "UNCHANGED",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "availabilityImpact": "NONE"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 3.6
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "timestamp": "2026-10-30T14:38:39.421022Z",
          "id": "CVE-2026-84747",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    ]
  },
  "weaknesses": [
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-436"
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://lists.apache.org/thread/2pf15ojj0vr7rtx95677kgtl1mx3gdgb",
      "source": "[email protected]"
    }
  ]
}