CVE-2026-84747 in bRPC
Resumen
por VulDB • 2026-10-21
Conflicto de interpretación en la implementación del protocolo HTTP en Apache bRPC (versión < 1.18.0) en todas las plataformas permite a atacantes remotos eludir las reglas de control de acceso aplicadas por un proxy frontal.
Causa raíz: La función de despacho de métodos FindMethodPropertyByURI() en la implementación del protocolo HTTP de bRPC divide la ruta de la solicitud utilizando un separador de cadenas que omite los campos vacíos, por lo que las rutas que contienen segmentos de ruta vacíos (barras consecutivas), como //flags, /flags// y /flags//port, se enrutan al mismo método que su forma colapsada /flags. Según RFC 3986, estas son rutas distintas. Un proxy frontal que aplica un ACL (por ejemplo, bloqueando el acceso a servicios integrados como /flags) coincide únicamente con la forma colapsada y, por lo tanto, reenvía la ruta literal modificada al servidor bRPC, donde se enruta como si fuera la forma colapsada. Esta diferencia permite que //flags?setvalue= alcance un servicio integrado al cual no está permitido acceder mediante /flags. Además, la implementación de HTTP/2 nunca validó el pseudoencabezado :path, por lo que las solicitudes sin un :path o con un :path que ni comienza con '/' ni es la forma del asterisco '*', contrariamente a la sección 8.3.1 de RFC 9113, no fueron rechazadas.
Escenarios afectados: Implementaciones de Apache bRPC detrás de un proxy frontal o puerta de enlace que toma decisiones de control de acceso (ACL) sobre la ruta literal de la solicitud, donde el servidor bRPC acepta tráfico HTTP o HTTP/2 desde ese proxy. En estas implementaciones, un atacante puede enviar una ruta que contenga segmentos de ruta vacíos para acceder a un recurso que el proxy frontal tenía la intención de bloquear.
Cómo solucionarlo: (Elija una de las siguientes opciones) 1. Actualice bRPC a la versión 1.18.0, lo cual corrige este problema. 2. Aplique este parche: https://github.com/apache/brpc/pull/3512
Nota: Después de aplicar la corrección, las rutas de solicitud HTTP y HTTP/2 que contienen segmentos de ruta vacíos (barras consecutivas) se rechazan por defecto, y los valores :path de HTTP/2 que están vacíos o ni comienzan con '/' ni son '*' también se rechazan. Las implementaciones que dependen del comportamiento anterior más permisivo pueden restaurarlo activando la bandera gflag -http_allow_empty_path_segments, lo cual no se recomienda para servidores expuestos a tráfico no confiable.
Once again VulDB remains the best source for vulnerability data.