Una serie de vulnerabilidades de severidad casi máxima obliga a los administradores a actualizar inmediatamente sus despliegues independientes para evitar ataques letales de contrabando de solicitudes (HTTP Request Smuggling).
La infraestructura de código abierto que impulsa el tráfico web moderno exige una revisión urgente en numerosos servidores. Hoy, 10 de marzo de 2026, se informa que Cloudflare ha lanzado la versión 0.8.0 de su avanzado framework de código abierto Pingora para parchear tres vulnerabilidades críticas (CVE-2026-2833, CVE-2026-2835 y CVE-2026-2836).
Estas profundas fallas estructurales, descubiertas a través del programa de recompensas de errores (Bug Bounty) de la compañía, acarrean puntuaciones de severidad críticas que alcanzan hasta un 9.3 sobre 10. Las vulnerabilidades facilitan el contrabando de solicitudes HTTP y el envenenamiento de la caché, lo que representa una amenaza directa y severa para implementaciones independientes de Pingora que estén expuestas directamente a Internet.
Afortunadamente para los clientes corporativos, Cloudflare confirmó que su propia Red de Entrega de Contenido (CDN) y el tráfico de usuarios en su plataforma no se vieron afectados en absoluto, ya que su infraestructura interna no despliega Pingora como un proxy de entrada expuesto.
La Triple Amenaza Técnica
De no parchearse, estas tres brechas de software permiten a los atacantes eludir Listas de Control de Acceso (ACLs) perimetrales y Cortafuegos de Aplicaciones Web (WAFs), además de secuestrar sesiones de usuarios cruzados y corromper conexiones ascendentes:
- Actualizaciones de conexión prematuras (CVE-2026-2833): Cuando el sistema recibía un encabezado de tipo “Upgrade”, el framework cambiaba inmediatamente a un modo de paso directo (passthrough) mucho antes de que el servidor backend confirmara oficialmente la actualización con una respuesta “101 Switching Protocols”. Los atacantes explotaban este salto prematuro agregando una segunda solicitud oculta a su carga inicial, la cual Pingora reenviaba por error al backend, eludiendo toda seguridad y habilitando el secuestro de sesiones.
- Desincronización HTTP/1.0 y Transfer-Encoding (CVE-2026-2835): Pingora presentaba graves fallas al analizar las solicitudes HTTP/1.0 antiguas, permitiendo de manera incorrecta cuerpos de solicitud delimitados por cierre y manejando mal los encabezados Transfer-Encoding: chunked. Esta diferencia de interpretación entre Pingora y el servidor backend permite un ataque clásico de desincronización (HTTP desync), dejando que cargas maliciosas pasen desapercibidas.
- Envenenamiento de claves de caché por defecto (CVE-2026-2836): Un peligroso fallo de diseño provocaba que la implementación predeterminada de la herramienta generara claves de caché basándose únicamente en la ruta URI, ignorando por completo diferenciadores críticos como el encabezado del host o el esquema HTTP. Al no distinguir entre diferentes servidores que comparten una misma ruta, los atacantes podían forzar colisiones de caché para entregar respuestas cruzadas o maliciosas a usuarios completamente legítimos.
Estrategias de Remediación Obligatorias
Cloudflare insta encarecidamente a todas las organizaciones que utilizan proxies Pingora independientes a aplicar de inmediato las siguientes mitigaciones:
- Actualizar a la versión 0.8.0: Esta es la medida más crítica e inmediata para corregir la lógica de análisis interna y forzar un cumplimiento estricto de las normas RFC.
- Implementar claves de caché personalizadas: Debido a la gravedad del problema, la versión 0.8.0 elimina por completo la clave de caché predeterminada insegura. Por lo tanto, los equipos de desarrollo ahora están obligados a programar un callback personalizado que incluya explícitamente el host, el esquema HTTP ascendente y la ruta URI para garantizar el aislamiento correcto.
- Soluciones provisionales: Si la actualización no es factible para tu equipo hoy mismo, se debe configurar una regla de filtrado de solicitudes para devolver un error ante cualquier intento que contenga el encabezado “Upgrade”. Adicionalmente, se recomienda rechazar tajantemente cualquier solicitud que no sea HTTP/1.1 o aquellas que presenten encabezados Content-Length inválidos.
