Cloudflare ha lanzado la versión 0.8.0 de su framework de código abierto Pingora para corregir tres vulnerabilidades críticas: CVE-2026-2833, CVE-2026-2835 y CVE-2026-2836. Estos fallos permiten el contrabando de solicitudes HTTP y el envenenamiento de caché, lo que representa una grave amenaza para las implementaciones independientes de Pingora expuestas directamente a Internet.

Cloudflare ha lanzado la versión 0.8.0 de su framework de código abierto Pingora para parchear tres vulnerabilidades críticas: CVE-2026-2833, CVE-2026-2835 y CVE-2026-2836.

Estas fallas permiten el contrabando de solicitudes HTTP y el envenenamiento de caché, lo que representa una grave amenaza para las implementaciones independientes de Pingora expuestas directamente a internet.

Cloudflare confirmó que su propia Red de Distribución de Contenido (CDN) y el tráfico de sus clientes no se vieron afectados por estos problemas, ya que su infraestructura interna no despliega Pingora como un proxy de entrada expuesto directamente.

Vulnerabilidades en el framework Pingora

Las vulnerabilidades, descubiertas y reportadas por el investigador de seguridad Rajat Raghav a través del Programa de Recompensas por Errores de Cloudflare, tienen calificaciones de gravedad crítica (hasta 9.3 sobre 10).

Si no se parchean, permiten a los atacantes eludir las Listas de Control de Acceso (ACL) a nivel de proxy y los Cortafuegos de Aplicaciones Web (WAF), secuestrar sesiones entre usuarios y envenenar conexiones aguas arriba.

Actualizaciones prematuras de conexión (CVE-2026-2833)

La primera vulnerabilidad surge del manejo de Pingora de las solicitudes de actualización de conexión HTTP/1.1.

Cuando Pingora recibía un encabezado "Upgrade", cambiaba inmediatamente a un modo de paso directo antes de que el servidor backend confirmara oficialmente la actualización con una respuesta "101 Switching Protocols".

Los atacantes podían explotar este cambio prematuro añadiendo una segunda solicitud oculta a su carga inicial.

Pingora reenviaba erróneamente esta solicitud contrabandeada directamente al backend, eludiendo por completo los controles de seguridad a nivel de proxy y potencialmente secuestrando sesiones de usuarios posteriores.

Fallos en HTTP/1.0 y Transfer-Encoding (CVE-2026-2835)

La segunda falla involucra el análisis no conforme de Pingora de las solicitudes HTTP/1.0 más antiguas.

Pingora permitía incorrectamente que los cuerpos de las solicitudes HTTP/1.0 estuvieran delimitados por cierre y manejaba mal los encabezados "Transfer-Encoding: chunked".

Debido a que Pingora y el servidor backend interpretaban de manera diferente la longitud del cuerpo de la solicitud, los atacantes podían desincronizar deliberadamente el encuadre de la conexión.

Este clásico ataque de desincronización HTTP permite que cargas maliciosas pasen desapercibidas por el proxy.

Envenenamiento de la clave de caché predeterminada (CVE-2026-2836)

La última vulnerabilidad está relacionada con un fallo de diseño en la construcción predeterminada de la clave de caché de Pingora.

La implementación predeterminada generaba claves de caché basadas únicamente en la ruta del Identificador Uniforme de Recursos (URI), ignorando diferenciadores críticos como el encabezado de host o el esquema HTTP.

Al no distinguir entre diferentes hosts que comparten la misma ruta URI, los atacantes podían forzar fácilmente colisiones de caché, haciendo que los usuarios legítimos recibieran respuestas maliciosas o de origen cruzado.

Cloudflare recomienda encarecidamente a todas las organizaciones que utilicen proxies Pingora independientes aplicar las siguientes mitigaciones:

Actualiza inmediatamente: Actualiza todas las implementaciones de Pingora a la versión 0.8.0 o superior para corregir la lógica de análisis y hacer cumplir el cumplimiento estricto de RFC.

Implementa claves de caché personalizadas: Dado que la versión 0.8.0 elimina la clave de caché predeterminada insegura, debes implementar una función de devolución de llamada personalizada que incluya el encabezado de host, el esquema HTTP aguas arriba y la ruta URI para garantizar un aislamiento adecuado de la caché.

Soluciones temporales: Si no puedes actualizar de inmediato, configura la lógica de filtrado de solicitudes para devolver un error en cualquier solicitud que contenga un encabezado "Upgrade". Además, rechaza cualquier solicitud que no sea HTTP/1.1 o que tenga encabezados Content-Length inválidos.