
Vulnerabilità di Heap-based Buffer Overflow in Apache HTTP Server con mod_xml2enc, xml2StartParse e contenuti non attendibili
mod_xml2enc Heap Overflow PoCQuesto repository contiene una proof of concept controllata per CVE-2026-42536, una scrittura out-of-bounds basata su heap nel modulo mod_xml2enc di Apache HTTP Server. Le versioni di Apache HTTP Server dalla 2.4.0 alla 2.4.67 sono interessate; la versione 2.4.68 contiene la correzione upstream.
Il risultato dimostrato è una corruzione di memoria seguita da un crash del worker Apache. Attivazioni ripetute possono causare denial of service. Questa PoC non dimostra remote code execution, privilege escalation o una reverse shell.
Questa PoC invia intenzionalmente contenuto che può mandare in crash un worker Apache. Eseguila solo in un ambiente usa e getta e isolato che possiedi o che sei esplicitamente autorizzato a testare. Non puntarla a sistemi di produzione o di terze parti.
Lo script consente per impostazione predefinita solo l'operazione su loopback. L'operazione remota richiede il flag esplicito --allow-remote, ma tale flag non sostituisce l'autorizzazione.
xml2StartParse può istruire mod_xml2enc a saltare byte prima dell'elemento di inizio configurato. In Apache HTTP Server 2.4.67, fix_skipto() avanza il puntatore del buffer di output e riduce la quantità di dati validi, ma non riduce la capacità di output dello stesso offset:
ctx->bytes -= (p - ctx->buf);
ctx->buf = p;
La successiva conversione del set di caratteri riceve quindi una capacità misurata dall'allocazione originale anche se ctx->buf ora punta all'interno di tale allocazione. La PoC rende osservabile questa discrepanza combinando:
xml2StartParse html.Content-Type che dichiara charset=windows-1252.0x80, che si espande da un byte CP1252 alla codifica UTF-8 a tre byte del simbolo dell'euro.La conversione in espansione consuma la capacità obsoleta e può scrivere oltre lo spazio effettivamente rimanente dopo il puntatore avanzato.
Apache 2.4.68 corregge l'errore di contabilità sottraendo l'offset saltato da ctx->bblen:
ctx->bytes -= (p - ctx->buf);
+ctx->bblen -= (p - ctx->buf);
ctx->buf = p;
La PoC utilizza due componenti HTTP:
poc.py client -> vulnerable Apache front end -> payload backend in poc.py
Apache deve caricare i seguenti moduli:
filter
proxy
proxy_http
xml2enc
Usa la seguente configurazione solo in un laboratorio isolato con Apache 2.4.67 o precedente:
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 configurazione predefinita prevede che poc.py venga eseguito nello stesso host o nello stesso namespace di rete del container di Apache. La porta 18081 è il backend del payload; le richieste devono essere inviate alla rotta Apache filtrata sulla porta 18080.
Avvia l'istanza vulnerabile di Apache, poi esegui la PoC dallo stesso host o container usa e getta:
python3 poc.py
I valori predefiniti sono equivalenti 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
Per un laboratorio autorizzato su due macchine, rendi il backend del payload raggiungibile da Apache e aggiorna ProxyPass/ProxyPassReverse per usare l'IP del laboratorio dell'attaccante. Poi associa il backend e punta esplicitamente all'indirizzo Apache del laboratorio:
python3 poc.py \
--host VICTIM_LAB_IP \
--port 18080 \
--backend-bind 0.0.0.0 \
--backend-port 18081 \
--allow-remote
Non esporre la porta del backend oltre la rete di test isolata.
Monitora Apache mentre esegui la PoC. A seconda della build e del process manager, una richiesta del client può fallire, essere resettata o restituire dati parziali mentre il processo padre sostituisce il worker andato in crash.
Le prove tipiche della build vulnerabile testata includevano:
AH01434 character-set conversion selected
AH01428 skipped to the first configured element
AH01441 conversion performed
AH00052 child process exited on signal 11 (SIGSEGV)
Su un'installazione gestita da systemd:
sudo journalctl -u apache2 -f
Per un container Docker in primo piano:
docker logs -f CONTAINER_NAME
Il ricambio del PID del worker può fornire un segnale aggiuntivo:
watch -n 0.5 'pgrep -a httpd || pgrep -a apache2'
Il solo fallimento del trasporto non è prova della vulnerabilità. Conferma il crash nel log degli errori di Apache, nel journal di sistema, nell'output del sanitizer o in un core dump.
Ripeti la stessa richiesta contro Apache HTTP Server 2.4.68 con gli stessi moduli e la stessa configurazione del virtual host. Il backend del payload dovrebbe comunque ricevere la richiesta, ma il worker Apache dovrebbe rimanere attivo perché la capacità di output viene ridotta insieme al puntatore avanzato.
Se il processo padre non sostituisce automaticamente il worker, riavvia solo il servizio del laboratorio usa e getta:
sudo systemctl restart apache2
oppure riavvia il container usa e getta:
docker restart CONTAINER_NAME