DEV Community

Cover image for Apache HTTP Server 2.4.67 cierra 11 vulnerabilidades de mayo: el RCE en HTTP/2 (CVE-2026-23918) que obliga a parchear hoy
lu1tr0n
lu1tr0n

Posted on • Originally published at elsolitario.org

Apache HTTP Server 2.4.67 cierra 11 vulnerabilidades de mayo: el RCE en HTTP/2 (CVE-2026-23918) que obliga a parchear hoy

#webdev #security #programming #cybersecurity

El 4 de mayo de 2026 la Apache Software Foundation publicó la versión 2.4.67 de Apache HTTP Server, el servidor web open source que sigue sirviendo cerca de un tercio de los sitios activos en internet. La versión llega como release de seguridad, features y bugfixes, e incluye parches para 11 vulnerabilidades documentadas en el advisory oficial publicado el 5 de mayo. La pieza más relevante de este conjunto, marcada por el equipo Apache como severidad Important y con CVSS de 8.8, es CVE-2026-23918: un double-free en la implementación de HTTP/2 que abre la puerta a ejecución remota de código en servidores que tienen el módulo mod_http2 activo —es decir, la mayoría de los Apache modernos detrás de un sitio HTTPS—.

A las pocas horas del anuncio, SecurityWeek, securityonline.info, The CyberSec Guru, Cybersecurity News y Undercode Testing cubrieron la noticia con análisis técnicos. No hay PoC público al momento de escribir y no se ha confirmado explotación activa, pero el bug se reportó privadamente el 10 de diciembre de 2025 y el commit del fix —r1930444— quedó registrado al día siguiente. Eso significa que un atacante con acceso al log de commits de Apache pudo identificar la primitiva vulnerable hace casi cinco meses; el ciclo de armar y publicar un exploit a partir del diff del fix suele tardar entre días y semanas. La ventana de parcheo, en otras palabras, es ya.

Este artículo documenta los 11 CVEs en el orden de criticidad real, explica con detalle el mecanismo del double-free en HTTP/2, lista mitigaciones temporales para quien no pueda actualizar de inmediato, y ofrece comandos copy-paste para detectar versiones vulnerables. Si administras Apache en producción —en un VPS, en un cluster Kubernetes, en una instancia AWS EC2 con LAMP, en una Synology o en cualquier panel tipo cPanel/Plesk— este es material operativo.

La pieza central: CVE-2026-23918, RCE en HTTP/2

Qué es exactamente

mod_http2 es el módulo de Apache que implementa el protocolo HTTP/2. Casi todos los Apache 2.4 modernos lo cargan por defecto cuando el sitio sirve por HTTPS, porque navegadores como Chrome y Firefox negocian HTTP/2 automáticamente sobre TLS desde 2015. La vulnerabilidad se dispara cuando un cliente envía una secuencia maliciosa de tramas HTTP/2 conocida como «early stream reset», una solicitud que cancela un stream en un momento muy temprano de su ciclo de vida.

En esa secuencia, la lógica de gestión de memoria del servidor termina liberando dos veces la misma región de heap: un bug clásico llamado double-free. La primera vez, la región pasa a la free-list del alocador; la segunda vez, el alocador interpreta esa región como reusable y rompe sus propias estructuras internas. A partir de ahí, un atacante con conocimiento del layout de la heap puede manipular asignaciones futuras, sobrescribir punteros de función o estructuras críticas, y en última instancia redirigir el flujo de ejecución del proceso del servidor.

Severidad oficial

  • Severidad Apache: Important (la segunda más alta en su escala interna, debajo de Critical).
  • CVSS base: 8.8 (High).
  • Impacto: ejecución remota de código en el contexto del usuario que corre httpd (típicamente apache, www-data o nobody).
  • Versión vulnerable: Apache HTTP Server 2.4.66.
  • Versión parcheada: 2.4.67.

Conviene notar la sutileza: el bug solo afecta la versión más reciente previa al parche, 2.4.66. Las versiones anteriores no tienen este defecto particular —fue introducido por un cambio reciente en mod_http2—. Eso es paradójico: los administradores que se mantuvieron actualizados quedaron expuestos, mientras que quienes corren versiones más viejas no son vulnerables a este CVE específico (aunque sí a los otros diez del advisory, que sí se arrastran desde antes).

Investigadores que reportaron el bug

El advisory oficial acredita a Bartlomiej Dmitruk (striga.ai) y Stanislaw Strzalkowski (isec.pl), quienes reportaron el bug de forma privada al equipo de seguridad de Apache. La cooperación responsable funcionó: el fix se commitó al día siguiente del reporte y se incluyó en el siguiente release planificado.

Por qué el RCE no es trivial pero sí real

A diferencia de un bug clásico de stack overflow donde un atacante controla directamente un puntero, en un double-free moderno el camino al RCE pasa por manipular la heap —el llamado heap grooming—. El atacante necesita encadenar asignaciones específicas para que la región liberada dos veces termine ocupada por una estructura cuyo puntero de función o tabla de virtuales pueda controlar. Esto es complicado, pero completamente factible y forma parte del repertorio estándar de las técnicas de explotación contemporáneas. Las mitigaciones del kernel —ASLR, NX, stack canaries— ayudan, pero no eliminan el riesgo.

Lo que sí es robusto es el DoS: incluso sin una explotación completa de RCE, un atacante puede tirar el servidor con la misma trama maliciosa, simplemente corrompiendo la heap hasta que httpd haga un crash. Para servicios públicos eso ya es un problema operativo grave por sí solo.

Los otros diez: el panorama completo

Más allá de la RCE estrella, el advisory cierra otras diez vulnerabilidades. Las agrupo por familia de impacto.

Información sensible y privilegio local (Moderate)

CVE-2026-24072 (Moderate, mod_rewrite y otros). Permite a un autor local de archivos .htaccess leer archivos con los privilegios del usuario httpd. Es relevante en hostings compartidos donde múltiples clientes alojan sus sitios bajo el mismo proceso de Apache. Versiones afectadas: hasta 2.4.66. Reportado por el investigador anónimo y7syeu.

CVE-2026-33006 (Moderate, mod_auth_digest). Un ataque de timing side-channel permite a un atacante remoto eludir la autenticación Digest. La autenticación Digest está en franco desuso —reemplazada por OAuth, JWT y autenticación basada en formularios sobre HTTPS—, pero algunos sitios legacy todavía la usan. Reportado por Nitescu Lucian.

Cuatro CVEs en mod_proxy_ajp: el módulo que acumula deuda

Cuatro de los once CVEs aplican al mismo módulo: mod_proxy_ajp, el conector que permite a Apache reenviar peticiones a backends Tomcat o Jetty mediante el Apache JServ Protocol.

  • CVE-2026-28780 (Low) — Heap-based buffer overflow en ajp_msg_check_header(). Si mod_proxy_ajp se conecta a un servidor AJP malicioso, ese servidor puede provocar una escritura de 4 bytes controlados por el atacante más allá del final de un buffer heap. Reportado independientemente por Andrew Lacambra, Elhanan Haenel, Tianshuo Han y Tristan Madani entre febrero y marzo de 2026 —cuatro investigadores convergiendo al mismo bug es una señal clara de que el módulo está en el radar—.
  • CVE-2026-33857 (Low) — Out-of-bounds read en funciones getter de AJP. Reportado por Elhanan Haenel.
  • CVE-2026-34032 (Low) — Improper null termination y out-of-bounds read en ajp_msg_get_string(). Reportado por Tianshuo Han y Jérôme Djouder.
  • CVE-2026-34059 (Low) — Buffer over-read y memory disclosure en ajp_parse_data(). Reportado por Elhanan Haenel.

El patrón es elocuente: AJP es un protocolo viejo —diseñado en los noventa para Apache JServ— y el código de su parser en C sigue revelando bugs después de décadas. Si tu Apache no está reenviando a un Tomcat, deshabilitar mod_proxy_ajp es la mitigación más simple y efectiva contra estos cuatro CVEs.

Denegación de servicio y crashes

CVE-2026-29168 (Low, mod_md). Vulnerabilidad de asignación de recursos sin límite en respuestas OCSP del módulo ACME que gestiona certificados Let’s Encrypt y similares. Una respuesta OCSP de tamaño excesivo agota recursos del servidor. Versiones afectadas: 2.4.30 hasta 2.4.66. Reportado por Pavel Kohout (Aisle Research).

CVE-2026-29169 (Low, mod_dav_lock). NULL pointer dereference: una solicitud maliciosa al módulo de WebDAV crashea el servidor. El advisory aclara que mod_dav_lock no es usado internamente por mod_dav o mod_dav_fs, así que removerlo si no se usa explícitamente es la mitigación trivial. Reportado por Pavel Kohout.

CVE-2026-33007 (Low, mod_authn_socache). Otro NULL deref. Permite a un usuario remoto sin autenticar crashear un proceso hijo en configuraciones de caching forward proxy. Versiones afectadas: 2.4.0 hasta 2.4.66. Reportado por Pavel Kohout y Arkadi Vainbrand.

HTTP response splitting

CVE-2026-33523 (Low, múltiples módulos). Vulnerabilidad de HTTP response splitting cuando Apache reenvía a backends comprometidos o no confiables. Permite a un atacante con control parcial del backend inyectar headers HTTP arbitrarios en la respuesta al cliente. Versiones afectadas: 2.4.0 hasta 2.4.66. Reportado por Haruki Oyama (Waseda University), Merih Mengisteab y Dawit Jeong.

Cómo detectar si tu servidor es vulnerable

El primer paso es saber qué versión corres. Los comandos varían según distribución y método de instalación.

# Linux (compilación desde fuente o paquete)
apache2 -v
# o
httpd -v

# RHEL / CentOS / Rocky / Alma
rpm -qa | grep httpd

# Debian / Ubuntu
dpkg -l | grep apache2

# Verificar módulos cargados (HTTP/2 y AJP en uso)
apache2ctl -M | grep -iE "http2|proxy_ajp"
# o en RHEL
httpd -M | grep -iE "http2|proxy_ajp"

# Ver si HTTP/2 está realmente activo en algún virtualhost
grep -r -i "Protocols" /etc/apache2/ /etc/httpd/ 2>/dev/null
Enter fullscreen mode Exit fullscreen mode 
# Windows (Apache Lounge u otros builds Windows)
C:\Apache24\bin\httpd.exe -v
Enter fullscreen mode Exit fullscreen mode

Si la salida indica 2.4.66, eres vulnerable a CVE-2026-23918. Si indica una versión entre 2.4.0 y 2.4.66, eres vulnerable a varios de los otros diez —dependiendo de qué módulos cargues—. La versión correcta es 2.4.67.

Para chequear desde fuera, sin acceso al servidor, basta con una petición curl al header Server:

curl -I -k https://tu-dominio.tld/ 2>&1 | grep -i server
# Server: Apache/2.4.66 (Unix)
Enter fullscreen mode Exit fullscreen mode

Muchos administradores ocultan el banner con ServerTokens Prod, lo cual es buena práctica de seguridad pero impide la detección remota fácil. En esos casos, un escaneo con Nmap usando el script http-apache-server-status o herramientas como Nuclei pueden inferir la versión por comportamiento.

Cómo parchear: ruta principal

La actualización es una tarea estándar. Variantes según distribución:

# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade apache2

# RHEL / Rocky / Alma
sudo dnf update httpd

# Tras la actualización
sudo systemctl restart apache2  # o httpd

# Verificar la nueva versión
apache2 -v
# Server version: Apache/2.4.67 (Ubuntu)
Enter fullscreen mode Exit fullscreen mode

Para sitios construidos sobre paneles de control —cPanel, Plesk, DirectAdmin, Webmin— la actualización suele venir empaquetada por el panel y se aplica desde su propio gestor. cPanel típicamente emite un upcp (update cPanel) que arrastra Apache; Plesk usa su propio updater. Si la versión empaquetada por la distribución todavía no incluye 2.4.67, es legítimo compilar desde fuente desde downloads.apache.org/httpd como medida temporal, pero hay que tener disciplina para volver al paquete oficial cuando la distro libere la versión.

Mitigaciones temporales si no podés actualizar ahora

A veces el calendario de mantenimiento no permite reiniciar Apache de inmediato. Hay mitigaciones que reducen sustancialmente el riesgo sin requerir actualización.

Deshabilitar HTTP/2 (cierra CVE-2026-23918) 

# En httpd.conf o equivalente
# Comentar la carga del módulo:
# LoadModule http2_module modules/mod_http2.so

# O forzar solo HTTP/1.1 a nivel de virtualhost:
Protocols http/1.1
Enter fullscreen mode Exit fullscreen mode

Tras editar:

sudo apachectl configtest
sudo systemctl reload apache2
Enter fullscreen mode Exit fullscreen mode

El costo: HTTP/1.1 es más lento sobre TLS y los navegadores modernos están optimizados para HTTP/2. Para sitios de tráfico alto, esta mitigación puede afectar Core Web Vitals y experiencia de usuario. Es aceptable como puente de horas o un día, no como configuración permanente.

Deshabilitar mod_proxy_ajp si no se usa (cierra los 4 CVEs AJP) 

# Debian / Ubuntu
sudo a2dismod proxy_ajp
sudo systemctl reload apache2

# RHEL / Rocky / Alma — comentar la línea LoadModule en
# /etc/httpd/conf.modules.d/00-proxy.conf
Enter fullscreen mode Exit fullscreen mode

La gran mayoría de los Apache modernos no usan AJP. Si tu stack es LAMP puro, PHP-FPM, Node detrás de Apache via proxy_pass HTTP, esto se puede deshabilitar sin impacto.

Deshabilitar mod_dav_lock si no se usa 

sudo a2dismod dav_lock
Enter fullscreen mode Exit fullscreen mode

Solo dejar habilitado si tu sitio usa WebDAV con locking explícito.

Cómo se rompe y cómo se arregla, en términos del código

El commit del fix —r1930444, registrado el 11 de diciembre de 2025— se incluyó en la rama 2.4.x del repositorio Subversion oficial de Apache. El advisory no cita la función exacta del double-free, pero el patrón es reconocible para quien haya leído el código de mod_http2: la implementación de Apache mantiene estructuras de stream que se asignan al iniciar una nueva petición HTTP/2 y se liberan al cerrarla. Cuando el cliente envía un RST_STREAM muy temprano —antes de que la inicialización del stream haya completado todos los pasos— la lógica de cleanup intenta liberar la estructura por una ruta de error, mientras que el flujo principal también la libera por su ruta normal. Dos liberaciones, una sola estructura: double-free.

La corrección típica de este tipo de bug es marcar la estructura con un flag freed = true después de la primera liberación, y verificar el flag antes de cualquier liberación posterior. Apache tiene infraestructura para esto en su pool de memoria APR, y en general el arreglo consiste en que la ruta de cleanup detecte el caso y no toque la región dos veces.

Cuán fuerte es la noticia

Hay tres elementos a calibrar.

Lo serio. Es una RCE en el servidor web más usado del planeta —Apache sigue corriendo aproximadamente un tercio de los sitios activos según las series de Netcraft—, en una primitiva muy expuesta —HTTP/2 sobre TLS—, y con CVSS 8.8. No requiere autenticación. La superficie potencial es muy grande.

Lo que matiza. No hay PoC público todavía. Las primitivas de double-free a RCE en heap moderna no son triviales y requieren heap grooming específico para la versión de glibc o jemalloc del binario en cuestión. La explotabilidad real depende de mitigaciones del kernel y de las características del binario. Como mínimo, esto es un DoS confiable; el RCE confiable suele requerir trabajo adicional.

El factor tiempo. El commit del fix lleva publicado desde el 11 de diciembre de 2025. Cualquier atacante competente con acceso al log puede haber identificado la primitiva vulnerable hace meses. La ventana entre fix público y exploit público en este tipo de bugs es típicamente de días a semanas, no meses. El hecho de que la versión 2.4.67 se libere recién ahora —cinco meses después del commit— sugiere que el equipo de Apache esperaba completar la batería de releases con todos los fixes acumulados, pero el costo de esa espera es exposición prolongada para administradores que no compilaban desde el branch en desarrollo.

Lección de fondo

Hay un patrón en este advisory que vale la pena retener para quien planifica seguridad en infraestructura web. No es un solo bug; son once. La concentración de cuatro CVEs en mod_proxy_ajp confirma que los protocolos legacy mantenidos por compatibilidad acumulan deuda silenciosa. La pregunta operativa, más allá de aplicar este parche, es: ¿qué módulos cargás por defecto que no estás usando? El principio de superficie mínima —deshabilitar todo lo no necesario— sigue siendo la defensa más barata y efectiva contra clases enteras de vulnerabilidades futuras.

La otra lección es de cadencia. La política de Apache de no publicar advisories hasta tener un release estable que parche las cosas es defendible, pero crea una ventana de riesgo donde el commit del fix está en público y el binario nuevo todavía no. Para infraestructura crítica, suscribirse al httpd-announce@apache.org —la lista oficial de anuncios— y al feed RSS de los advisories es lo mínimo viable. Para entornos altamente expuestos, mirar directamente el repositorio Subversion del proyecto en busca de commits con tags Fixes ... CVE es práctica de equipos de seguridad maduros.

Y para el resto: 2.4.67 hoy.

Fuentes

Top comments (0)