Apache HTTP/2 CVE-2026-23918: Wenn zwei Frames den Webserver-Pool kippen — was 2.4.67 wirklich ändert

Am 4. Mai 2026 hat die Apache Software Foundation CVE-2026-23918 veröffentlicht — einen Double-Free im Stream-Cleanup-Pfad von mod_http2 (Datei h2_mplx.c). Auslöser: ein HEADERS-Frame, unmittelbar gefolgt von einem RST_STREAM mit Non-Zero-Error-Code auf demselben Stream. Eine TCP-Verbindung, zwei Frames — der MPM-Worker crasht, jeder in der Verbindung anhängende Request wird gedroppt, Apache respawnt, der Angreifer wiederholt. DoS läuft sustained mit minimalem Traffic.

Auf x86_64 ist ein lauffähiger RCE-Proof-of-Concept demonstriert: Eine präparierte h2_stream-Struktur wird per mmap-Reuse an die freigegebene virtuelle Adresse platziert, ihre Pool-Cleanup-Funktion auf system() umgebogen. Debian-paketiertes Apache und die offiziellen Apache-httpd-Docker-Images mit dem APR-mmap-Allocator sind das relevante RCE-Ziel. Patch: Apache 2.4.67. Kein KEV-Eintrag zum Stand 10. Mai, aber Public-PoC ist verfügbar.

Was die Schwachstelle ist

CVE-2026-23918 ist ein Double-Free im HTTP/2-Stream-Cleanup-Pfad. Der Fehler sitzt in h2_mplx.c, der zentralen Multiplexer-Datei von mod_http2. Wird ein HTTP/2-Stream durch RST_STREAM mit Non-Zero-Error-Code beendet, während die HEADERS noch in Bearbeitung sind („early reset“), gerät die Stream-Struktur in einen Zustand, in dem zwei verschiedene Cleanup-Pfade dieselben Pool-Allokationen freigeben.

Der DoS-Pfad ist trivial: ein TCP-Connect, ein HEADERS-Frame, ein RST_STREAM-Frame, der MPM-Worker terminiert. Apache hat einen Worker-Pool, der respawnen kann, aber alle anderen Requests, die auf demselben Worker gehalten waren, werden dabei gedroppt. Der Angreifer wiederholt — das Pattern erzeugt einen anhaltenden Service-Ausfall mit minimalem Traffic.

Der RCE-Pfad ist nicht trivial, aber demonstriert. Nach dem ersten Free der h2_stream-Struktur kann ein Angreifer per mmap-Reuse eine präparierte Struktur an die freigewordene virtuelle Adresse platzieren, deren Pool-Cleanup-Callback auf system() umbiegen und im zweiten Free die Code-Ausführung auslösen. Die Vorbedingung ist eine bestimmte Heap-Layout-Vorhersagbarkeit — die der APR-Default-mmap-Allocator (in Debian-Paketen und den offiziellen httpd-Docker-Images) liefert.

Zum Stand 10. Mai 2026 ist keine aktive Ausnutzung in freier Wildbahn dokumentiert. Es gibt keinen CISA-KEV-Eintrag. Es gibt einen lauffähigen Public-PoC. Die Lage ist die einer Lauf-Schwachstelle, die gepatcht werden muß, bevor jemand sie für Massen-Scans automatisiert — nicht die einer Eskalations-Notfalls.

Wo Apache in DACH-Mittelstand-Stacks sitzt

Apache ist im DACH-Mittelstand in drei Rollen präsent:

1. Klassischer LAMP-Stack für TYPO3, oft mit mod_php oder php-fpm via mod_proxy_fcgi. Hier ist Apache der Webserver, der die Frontend-Requests entgegennimmt — und damit das direkte Angriffsziel.
2. Reverse-Proxy vor Sylius/Symfony-Anwendungen auf php-fpm oder Roadrunner. Apache spielt die TLS-Termination, das HTTP/2-Multiplexing, die mod_rewrite-Regeln, oft auch Authentifizierungs-Schichten via mod_auth_*.
3. Internal-Service-Frontend in containerisierten Stacks, wenn Teams aus historischen Gründen bei Apache geblieben sind statt auf nginx oder Caddy zu wechseln. Hier ist Apache hinter einem externen Load-Balancer, aber die Schwachstelle bleibt trotzdem im Lateral-Pfad ausnutzbar.

Für alle drei Rollen gilt: mod_http2 ist seit Jahren der Default. Wer HTTP/2 nicht aktiv deaktiviert hat, hat ihn aktiv.

Was wir konkret empfehlen

Erstens — und sofort: spielen Sie Apache 2.4.67 ein. Debian-stable, Ubuntu LTS, RHEL-Familie haben den Patch im Update-Stream; das offizielle httpd-Docker-Image ist mit Tag 2.4.67 verfügbar. Reload über apachectl graceful reicht aus — ein Full-Stop ist nicht nötig, weil der Patch im HTTP/2-Modul sitzt, nicht im Worker-Lifecycle.

Zweitens — falls der Patch-Sprung diese Woche nicht läuft (Change-Window, Test-Pipeline, Künden-Freigabe): deaktivieren Sie HTTP/2 vorübergehend. a2dismod http2 auf Debian/Ubuntu, oder Protocols h2 h2c http/1.1 auf Protocols http/1.1 reduzieren. Der Performance-Verlust ist messbar, aber für die meisten DACH-KMU-Workloads tragbar. Der Angriffsvektor verschwindet sofort.

Drittens — strukturell: prüfen Sie, ob Ihr CI/CD die Apache-Image-Tags rotiert. Wir sehen in Reviews regelmäßig Pipelines, die das offizielle httpd:2.4-Image referenzieren, das aber nicht regelmäßig neu gepullt wird. Eine :2.4.67-Pin nach erfolgreichem Test, oder eine Wolfi-/Chainguard-basierte Variante mit nächtlichem Rebuild, ist die robuste Antwort. Wer auf :latest setzt, ist innerhalb von 24 Stunden gepatcht — sofern die Pipeline auch pullt.

Viertens — Detection. Apache-Logs zeigen den DoS-Pfad nicht zwingend, weil der Worker crasht, bevor er die Request-Zeile schreibt. Was sich beobachten läßt: anomale Crash-Frequenz im Apache-Errorlog („Child ... terminated by signal“), eine ungewöhnliche Häufung von RST_STREAM-Frames im HTTP/2-Mitschnitt (sofern vorhanden), Verbindungen, die nach einem HEADERS-Frame sofort einen RST schicken. Ein einfacher Alert auf SIGSEGV-respawns im systemd-Journal fängt den DoS-Pfad zuverlässig.

Was wir bewusst nicht empfehlen

Wir empfehlen nicht, sich auf eine vorgelagerte WAF zu verlassen. CVE-2026-23918 ist Layer-7-spezifisch und triggert auf HTTP/2-Protokoll-Ebene; eine WAF, die HTTP/1.1 inspiziert und dann an Apache weiterreicht, hilft nur, wenn sie HTTP/2 selbst terminiert (Cloudflare, AWS CloudFront, ein nginx davor). Falls Sie eine solche Architektur fahren, ist Apache im Backend zwar etwas weniger akut, aber der Patch bleibt operative Pflicht.

Wir empfehlen ebenso wenig, von Apache pauschal auf nginx zu wechseln. Die Lage ist beherrschbar mit einem Punkt-Release-Sprung; eine Migration ist eine eigene Architektur-Entscheidung, kein Patch-Tuesday-Reflex. Wer aus anderen Gründen ohnehin migriert, kann das Timing nutzen — aber der CVE allein ist kein hinreichender Migrations-Grund.

Wer am stärksten betroffen ist

TYPO3-Mandanten mit klassischem LAMP-Stack auf Debian-stable oder RHEL-Familie. Hier läuft Apache mit mod_http2 als Default, oft hinter einem schlanken Load-Balancer ohne eigene HTTP/2-Termination. Patch-Sprung diese Woche.

Sylius-Multi-Mandanten-Häuser mit Apache als Reverse-Proxy vor mehreren Shop-Instanzen. Der DoS-Pfad trifft hier nicht nur einen Shop, sondern alle Mandanten auf demselben Apache-Worker-Pool. Die Patch-Priorität ist entsprechend hoch.

KMU mit selbstgebauten Container-Images auf Basis von httpd:2.4, die kein automatisches Re-Build haben. Diese Images sitzen oft über lange Zeiträume auf demselben Layer-Hash; ohne expliziten Rebuild-Trigger bleibt der Stack im verwundbaren Zustand.

Fazit

CVE-2026-23918 ist keine Sensation, aber sie ist eine der ersten Lauf-Schwachstellen seit dem frühen 2024er-mod_http2-Cluster, die jeder Apache-Betreiber im DACH-Mittelstand kennen sollte. Der Patch ist verfügbar, die Mitigation ist trivial, der Public-PoC ist veröffentlicht. Was fehlt, ist nur die Welle der Massen-Scans — und die kommt erfahrungsgemäß innerhalb von Wochen, nicht Monaten.

Die Frage lautet nicht, ob Sie die Lage überleben können, ohne 2.4.67 zu fahren. Sie lautet, ob Ihre Pipeline diesen Punkt-Release-Sprung in einer Woche durchziehen kann — oder ob Sie heute jemand manuell anschieben muß.

Persönlicher Hintergrund und technische Details zur Apache-Patch-Disziplin und zur Wolfi-/Chainguard-basierten Image-Rotation: ole-hartwig.eu.