insomnisec/detections-cve-2026-23918Erkennungsregeln für CVE-2026-23918 Apache http2 RCE - Credit: stringa.ai, isec.pl
Veröffentlicht: 2026-05-04
CVSSv3: 8.8 (Hoch)
Typ: Remote Code Execution / Denial of Service (Double-Free Memory Corruption)
Komponente: Apache HTTP Server mod_http2 (h2_mplx.c stream cleanup path)
Betroffen: Apache HTTP Server 2.4.66 mit aktiviertem HTTP/2 und Multi-Threaded MPM
Referenzen:
CVE-2026-23918 ist eine Double-Free-Speicherverfälschungsschwachstelle in der HTTP/2-Protokollimplementierung von Apache HTTP Server 2.4.66, die nur den Stream-Bereinigungspfad des mod_http2-Moduls in h2_mplx.c betrifft. Sie ermöglicht es einem nicht authentifizierten entfernten Angreifer, Apache-Worker-Prozesse mit einer einzigen TCP-Verbindung und zwei HTTP/2-Frames zum Absturz zu bringen (Denial of Service). Unter Bedingungen, die auf Debian-basierten Systemen und offiziellen Apache-Docker-Images vorhanden sind, kann die Double-Free zu einer vollständigen Remote Code Execution ausgebaut werden.
Die Ausnutzung für DoS wurde in freier Wildbahn bestätigt. Es wurden groß angelegte Internet-Scans beobachtet, die auf HTTP/2-Endpunkte abzielen. Der RCE-Exploit hat sich in kontrollierten Umgebungen als durchführbar erwiesen, obwohl es derzeit keine Hinweise auf eine weit verbreitete öffentliche Ausnutzung für RCE gibt.
MPM prefork ist nicht betroffen – die Schwachstelle erfordert eine Multi-Threaded-MPM-Konfiguration (worker, event oder ähnlich). CVE-2026-23918 betrifft nur die Apache HTTP Server Version 2.4.66.
Attacker opens HTTP/2 connection to Apache 2.4.66 (mod_http2 loaded, multi-threaded MPM) └─ Sends HTTP/2 HEADERS frame on stream N (opens the stream) └─ Immediately sends RST_STREAM on stream N (non-zero error code) └─ Sent BEFORE the multiplexer has registered the stream
Two nghttp2 callbacks fire in sequence: ├─ on_frame_recv_cb (RST received) → calls h2_mplx_c1_client_rst → m_stream_cleanup └─ on_stream_close_cb (stream closed) → calls h2_mplx_c1_client_rst → m_stream_cleanup
Result: same h2_stream pointer pushed onto spurge[] cleanup array TWICE
c1_purge_streams() iterates spurge[] and calls h2_stream_destroy() on each entry: ├─ First call: valid — frees the stream └─ Second call: DOUBLE-FREE — operates on already-freed memory → heap corruption
DoS path (trivial, in the wild): └─ Heap corruption → SIGABRT in worker process → worker dies → service disruption
RCE path (requires mmap allocator — default on Debian/Ubuntu and official Docker): └─ Attacker places fake h2_stream struct at freed virtual address via mmap reuse └─ Points pool cleanup function pointer to system() └─ Uses Apache scoreboard shared memory (fixed address, ASLR-resistant) as payload container └─ c1_purge_streams() executes system() with attacker-controlled argument → RCE
> **Wichtige Asymmetrie:** Der DoS-Pfad erfordert keine Heap-Manipulationskenntnisse und wird aktiv ausgenutzt. Der RCE-Pfad ist technisch anspruchsvoll, wurde jedoch unter Laborbedingungen demonstriert und wird angesichts der ASLR-resistenten festen Adresse des Scoreboards in naher Zukunft mit ziemlicher Sicherheit bewaffnet werden.
---
## Erkennungsarchitektur
> In diesem Abschnitt wird erläutert, warum sich die hier bereitgestellten Erkennungswerkzeuge erheblich von einem typischen Paket zur lokalen Privilegienerweiterung unterscheiden.
Copy Fail (CVE-2026-31431) war eine **hostseitige, nach dem Zugriff auftretende** Schwachstelle. Der Angreifer benötigte eine bestehende Präsenz auf dem System. Die Erkennung fand hauptsächlich auf der Syscall-Ebene statt (auditd, Wazuh) mit YARA-Scans nach dem PoC-Skript auf der Festplatte.
CVE-2026-23918 ist eine **netzwerkseitige, vor dem Zugriff auftretende** Schwachstelle. Der Exploit trifft als HTTP/2-Protokollframes über die Leitung ein, bevor Anwendungscode ausgeführt wird. Dies verschiebt den Erkennungsstapel erheblich:
| Layer | Copy Fail (LPE) | CVE-2026-23918 (RCE) |
|---|---|---|
| **Primäre Erkennung** | Auditd-Syscall-Regeln | Suricata-Netzwerkregeln |
| **WAF (ModSecurity)** | Eingeschränkt – kann Exploit nicht sehen | Relevant – Anomalie + Post-Exploit |
| **Auditd** | Kernerkennung | Ergebniserkennung (Abstürze, Post-Exploit) |
| **YARA** | Scannt nach PoC-Skript | Scannt nach Web-Shells (Post-Exploit-Artefakte) |
| **Netzwerk-IDS** | Nicht anwendbar | Erstklassige Erkennungsschicht |
| **TLS-Inspektion** | N/V | Für vollständige Suricata-Abdeckung erforderlich |
Die Faustregel: Bei RCE auf Netzwerkebene von außen nach innen arbeiten (Netzwerk → WAF → Host). Bei lokaler Privilegienerweiterung vom Host aus nach außen arbeiten.
---
## Erkennungsgrenzen
> **Lesen Sie dies, bevor Sie Regeln bereitstellen.**
**1. TLS beendet HTTP/2-Sichtbarkeit.**
Die meisten Produktions-Apache-Bereitstellungen verwenden HTTPS. Suricata kann den Inhalt verschlüsselter HTTP/2-Frames nicht überprüfen, ohne dass TLS-Entschlüsselung konfiguriert ist. Wenn Ihre Suricata-Bereitstellung keinen Zugriff auf TLS-Sitzungsschlüssel oder einen Entschlüsselungsspiegel hat, erfassen die folgenden Netzwerkregeln nur:
- Klartext-HTTP/2 (h2c) – in der Produktion ungewöhnlich, aber in internen Umgebungen vorhanden
- Die Netzwerksignatur des TCP-Verbindungsverhaltens (Verbindungsanzahl, RST-Muster auf der TCP-Ebene)
Für HTTPS-Bereitstellungen aktivieren Sie die TLS-Entschlüsselung von Suricata über die `tls-decrypt`-Einstellung und die Protokollierung von Sitzungsschlüsseln oder verlassen Sie sich stattdessen auf die WAF (ModSecurity/Coraza) und die hostbasierten Ebenen (auditd/Wazuh).
**2. ModSecurity kann den Exploit-Trigger nicht blockieren.**
Der Double-Free tritt im HTTP/2-Frame-Parser auf, bevor eine vollständige HTTP-Anfrage zusammengestellt und an ModSecurity übergeben wird. Die WAF sieht die Anfrage erst, nachdem die Frame-Parsing abgeschlossen ist – zu diesem Zeitpunkt kann der Schaden bereits eingetreten sein. ModSecurity wird in diesem Paket für Anomalieerkennung, Ratenbegrenzung und Post-Exploitation-Erkennung verwendet, nicht als Blocker für den Trigger.
**3. MPM prefork ist nicht betroffen.**
Wenn Ihre Apache-Bereitstellung `mpm_prefork_module` (single-threaded) verwendet, ist diese Schwachstelle nicht anwendbar. Der Fehler tritt nur in multithreaded MPMs auf (`mpm_event_module` oder `mpm_worker_module`). Überprüfen Sie mit `apachectl -V | grep MPM`, bevor Sie Regeln bereitstellen, die auf Prefork-Servern Fehlalarme erzeugen würden.