{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreief7p32wl5ul4ohawxdiisrcy5fvsizamnyqpuf7lv6bq36xjjoxa",
    "uri": "at://did:plc:4axwsf5hlk2omckvoolonim6/app.bsky.feed.post/3mnh5tdwkjfz2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifa7zlttnxf5av3r77ua7z4qqrdcgl4gxxrng43l2ux7k4yulk5km"
    },
    "mimeType": "image/jpeg",
    "size": 284458
  },
  "description": "HTTP/2 Bomb amenaza servidores con DoS remoto; NGINX, Apache y Envoy ya tienen mitigaciones.",
  "path": "/http-2-bomb-el-exploit-dos-que-pone-en-alerta-a-nginx-apache-iis-y-envoy/",
  "publishedAt": "2026-06-04T08:00:37.000Z",
  "site": "https://fomoera.com",
  "tags": [
    "Taylor Vick",
    "Unsplash",
    "1"
  ],
  "textContent": "**TL;DR:**\n\n> Calif reveló **HTTP/2 Bomb** , un exploit remoto de denegación de servicio contra servidores web con HTTP/2.\n\n> La firma reportó que una sola conexión puede retener **32 GB de memoria** en Apache httpd y Envoy en unos **20 segundos**.\n\n> **NGINX, Apache y Envoy** ya tienen parches o mitigaciones; en **Microsoft IIS** y **Cloudflare Pingora** el panorama público sigue menos claro.\n\nLa bomba HTTP/2 ha sonado la alarma en el mundo de la ciberseguridad, ya que aprovecha la configuración predeterminada de servidores populares como NGINX, Apache HTTPD, Microsoft IIS, Envoy y Cloudflare Pingora. Según la compañía de seguridad Calif, el malware fue descubierto utilizando OpenAI Codex y combina dos tecnologías bien conocidas – la bomba de compresión y la persistencia de conexión que imita Slowloris – para aumentar y monopolizar drásticamente el consumo de memoria de los servidores, lo que supone un riesgo inmediato para las empresas en México y América Latina. Los sitios web, API y servicios que utilizan HTTP/2 y ejecutan software vulnerable son fácilmente inaccesibles para atacantes sin botnets\n\n**HTTP/2 Bomb** es un exploit remoto de denegación de servicio que abusa de **HPACK** , el sistema de compresión de encabezados de HTTP/2, y de la ventana de control de flujo del protocolo para forzar asignaciones de memoria que el servidor no libera de inmediato.\n\n> \"El comportamiento vulnerable existe en la configuración predeterminada de HTTP/2 de cada servidor\", dijo Calif.\n\nLa parte más incómoda del hallazgo no es que exista una nueva variante de DoS. Es que toma piezas que ya estaban documentadas desde hace años y las encadena de una forma que varios servidores no bloquearon por defecto.\n\nCalif describe el ataque como una combinación de dos movimientos:\n\n  * **La bomba:** el atacante usa referencias HPACK muy pequeñas para provocar miles de asignaciones de encabezados en el servidor.\n  * **La retención:** el cliente anuncia una ventana de flujo de **cero bytes** , lo que impide que el servidor termine la respuesta y libere memoria.\n  * **El efecto práctico:** el servidor acumula presión de RAM hasta degradarse, entrar en swap o terminar procesos por falta de memoria.\n\n\n\nSegún Calif, una computadora doméstica con conexión de **100 Mbps** podría volver inaccesible un servidor vulnerable en segundos. En las pruebas citadas por la firma, un solo cliente consumió y retuvo **32 GB de memoria** contra **Apache httpd** y **Envoy** en alrededor de **20 segundos**.\n\nPhoto by Taylor Vick / Unsplash\n\n## El riesgo no está solo en HTTP/2, sino en cómo los servidores cuentan la memoria\n\nEl punto técnico clave está en que muchos límites tradicionales miran el tamaño total de los encabezados decodificados. HTTP/2 Bomb esquiva ese enfoque porque el encabezado puede ser casi vacío; el peso real aparece en la contabilidad interna que el servidor asigna por cada entrada.\n\nEn otras palabras: el problema no es únicamente cuántos bytes viajan por la red, sino cuánta memoria obliga a reservar cada byte cuando llega al servidor.\n\nCalif reportó estos resultados de demostración:\n\n  * **Envoy 1.37.2:** amplificación aproximada de **5,700:1** , con **32 GB** en unos **10 segundos**.\n  * **Apache httpd 2.4.67:** amplificación aproximada de **4,000:1** , con **32 GB** en unos **18 segundos**.\n  * **NGINX 1.29.7:** amplificación aproximada de **70:1** , con **32 GB** en unos **45 segundos**.\n  * **Microsoft IIS en Windows Server 2025:** amplificación aproximada de **68:1** , con **64 GB** en unos **45 segundos**.\n\n\n\nLa compañía también anunció que Shodan ahora es compatible con HTTP/2 e identificó más de 880.000 sitios web que utilizan estos servidores. Sin embargo, esta cifra no debe interpretarse de manera general como \"880.000 sitios web vulnerables\", ya que muchos de estos sitios web están protegidos por CDN, tienen contramedidas o tienen diferentes configuraciones. Sin embargo, esta cifra muestra claramente el alcance de los equipos de infraestructura que deben revisarse\n\n## NGINX, Apache y Envoy ya movieron ficha; IIS y Pingora siguen bajo presión\n\nLa respuesta no ha sido pareja. **NGINX** incorporó la directiva `max_headers` en **1.29.8** , con un valor predeterminado de **1,000** encabezados. La idea es simple: no basta limitar el tamaño total; también hay que limitar cuántos encabezados acepta el servidor.\n\n**Apache httpd** corrigió el problema en **mod_http2 v2.0.41** , con un ajuste para contabilizar encabezados `cookie` contra `LimitRequestFields`. Calif señaló que, si no es posible actualizar, una mitigación temporal es desactivar HTTP/2 con `Protocols http/1.1`.\n\n**Envoy** publicó el aviso **GHSA-22m2-hvr2-xqc8** el **3 de junio de 2026**. El proyecto marcó como afectadas las versiones **menores a 1.39** y enlistó como versiones corregidas **1.35.11** , **1.36.7** , **1.37.3** y **1.38.1**.\n\nPara administradores, el checklist defensivo queda así:\n\n  * Actualizar **NGINX** a **1.29.8+** o desactivar HTTP/2 si no hay parche inmediato.\n  * Actualizar **Apache httpd / mod_http2** a una versión corregida; como medida temporal, usar `Protocols http/1.1`.\n  * Actualizar **Envoy** a la versión parcheada correspondiente a cada rama.\n  * En **Microsoft IIS** y **Cloudflare Pingora** , revisar avisos oficiales y considerar desactivar HTTP/2 o poner una capa frontal que limite de forma estricta el número de encabezados por request.\n  * Aplicar límites de memoria por worker con contenedores, `cgroups` o mecanismos equivalentes para evitar que un proceso arrastre toda la máquina a swap.\n\n\n\nLa recomendación más importante es conceptual: cualquier punto que termine HTTP/2 debería limitar tanto el tamaño decodificado de encabezados como la cantidad de campos, incluyendo fragmentos `cookie`, y también acotar la vida de streams detenidos.\n\n## El dato incómodo: Codex no “inventó” el ataque, conectó piezas conocidas\n\nCalif atribuye el descubrimiento a **OpenAI Codex** , pero el hallazgo no significa que el modelo haya creado una clase de ataque desde cero. El valor estuvo en encadenar patrones conocidos: el abuso de HPACK y una retención de recursos similar a Slowloris.\n\nEse detalle importa para equipos de seguridad. Si un agente de IA puede leer diferencias públicas de código, conectar mitigaciones y convertirlas en un exploit funcional, la ventana entre “parche publicado” y “ataque replicable” se vuelve más corta.\n\nEl caso también obliga a revisar cómo se comunican los parches. Un commit defensivo puede revelar suficiente información para que otros reconstruyan el vector. No es una razón para ocultar correcciones, pero sí para acelerar pruebas, actualizaciones y mitigaciones en producción.\n\nPara empresas con portales públicos, APIs, e-commerce o servicios críticos, HTTP/2 Bomb no es una nota técnica de nicho. Es un recordatorio de que una configuración predeterminada puede ser segura hasta que alguien encuentra el ángulo donde el protocolo, la memoria y el tiempo juegan a favor del atacante.\n\n_Fuentes:_ 1",
  "title": "HTTP/2 Bomb: el exploit DoS que pone en alerta a NGINX, Apache, IIS y Envoy",
  "updatedAt": "2026-06-04T10:00:37.808Z"
}