This content is currently only available in Spanish. English translation is on the roadmap — in the meantime, here's the original.
Apache 2.4.71: el parche de HTTP/2 que no debería esperar al lunes
Lo primero que hice al leer el aviso fue preguntarme cuántos Apache conozco con HTTP/2 activado sin que nadie lo decidiera de forma consciente. Seguramente más de los que me gustaría.
El 11 de noviembre salió Apache HTTP Server 2.4.71, que corrige la CVE-2026-119618: una condición de carrera en la función assign_headers() de mod_http2 que puede corromper memoria del heap y acabar en ejecución remota de código. Sin autenticación. Apache la califica de crítica y Red Hat le da un CVSS de 9.8.
Qué está afectado y qué no
Afecta a las versiones de la 2.4.55 a la 2.4.70, y también al módulo mod_h2 independiente de la 2.0.8 a la 2.0.42. La condición clave es que HTTP/2 esté realmente en uso: mod_http2 cargado y h2 o h2c en la directiva Protocols. Si tu servidor solo habla HTTP/1.1, este fallo no te toca.
Comprobarlo cuesta un minuto:
# ¿Está cargado el módulo? (en Debian/Ubuntu, apache2ctl)
apachectl -M 2>/dev/null | grep -i http2
# ¿Está HTTP/2 anunciado en la configuración?
grep -Ri "^\s*Protocols" /etc/apache2/ /etc/httpd/ 2>/dev/null
Si no puedes actualizar todavía, Red Hat propone quitar h2 y h2c de Protocols para servir solo HTTP/1.1 mientras tanto. Ojo con un detalle: si Apache está detrás de otro Apache como proxy inverso, el que da la cara también necesita el parche.
Sobre si hay exploit, las fuentes no coinciden. Red Hat habla de investigación pública que ha demostrado una explotación fiable con la configuración por defecto y mod_http2 activo; otras fuentes dicen que no hay código público enlazado ni explotación conocida, y a fecha del 12 de noviembre no estaba en el catálogo KEV de CISA. No lo doy por confirmado, pero tampoco me quedaría tranquilo por eso.
Quién lo encontró, y por qué me importa
El anuncio en oss-security atribuye el hallazgo al escáner de código abierto de Anthropic y a Anthony Weems y Simon Scannell, de Google Cloud Vulnerability Research. Que una herramienta con IA aparezca en los créditos de una RCE crítica en el servidor web más veterano de Internet ya no sorprende como hace un año. Y ahí está lo que me preocupa.
Si encontrar condiciones de carrera en código C maduro se vuelve más barato, se vuelve más barato para todo el mundo, no solo para quien reporta de forma responsable. El tiempo entre que se publica un parche y alguien lo compara con la versión anterior para sacar el exploit se acorta.
Mi postura: esto se parchea hoy, no en la próxima ventana
Llevo años en sistemas y entiendo perfectamente el argumento contrario. Los cambios en producción pasan por control de cambios, hay aplicaciones que se rompen con una actualización y nadie quiere ser el que tiró la web un viernes por la tarde. Es un argumento serio y casi siempre tiene razón.
Pero con un fallo pre-autenticación, en un servicio expuesto a Internet y con mitigación trivial, creo que la ventana mensual es una mala costumbre. Si no puedes desplegar la 2.4.71 o el backport de tu distribución hoy, al menos desactiva HTTP/2 hoy. Perder multiplexación unos días es mucho menos grave que perder el servidor.
Lo que más me inquieta no es este bug concreto, sino el ritmo. Si las herramientas de análisis con IA siguen sacando fallos de este calibre en proyectos que dábamos por estables, ¿estamos preparados en sistemas para parchear en horas lo que antes parcheábamos en semanas?