CVE-2026-23918 — der mod_http2-Double-Free in Apache 2.4.66 im Betreiberüberblick

TL;DR — 90 Sekunden

Ein triviales Crash-Pattern, ein dokumentierter RCE-Pfad auf Debian-Default und acht Tage seit Disclosure mit öffentlichem PoC.

Betroffen?

Apache HTTP Server 2.4.66 mit aktiviertem mod_http2 und multi-threaded MPM (event, worker). Praktisch alle TYPO3- und Sylius-Hostings im DACH-Mittelstand, die HTTP/2 für Performance aktiviert haben. Frühere 2.4er-Linien sind nach Apache-Beschreibung nicht betroffen.

Risiko?

DoS trivial — eine TCP-Verbindung, zwei HTTP/2-Frames. RCE remote auf Debian-/Ubuntu-Default mit APR-mmap-Allokator. CVSS 8.8.

Sofortmaßnahme?

Auf Apache 2.4.67 upgraden. Wenn das Wartungsfenster nicht in den nächsten 24 Stunden zu öffnen ist: Protocols http/1.1 setzen, mod_http2 temporär deaktivieren.

Empfehlung?

Mittelstand: Distribution-Patch im laufenden Wartungsfenster, Stopgap-HTTP/1.1-Fallback bis dahin. Enterprise: kuratierte Image-Promotion auf gepatchte Base-Images, WAF-Regel auf die Frame-Sequenz HEADERS → RST_STREAM mit non-zero error code.

Kritikalität?

Siehe Hero-Badge — high.

Was ist das Problem?

Die Lücke ist im Stream-Cleanup-Pfad von mod_http2 angesiedelt, technisch in h2_mplx.c. Die Trigger-Sequenz ist nüchtern: ein Client sendet einen HTTP/2-HEADERS-Frame, sofort gefolgt von einem RST_STREAM-Frame mit einem nicht-null Error-Code, auf demselben Stream, bevor der Multiplexer den Stream überhaupt registriert hat. Zwei nghttp2-Callbacks feuern in Folge: on_frame_recv_cb für das RST und on_stream_close_cb für den Close. Beide rufen anschließend h2_mplx_c1_client_rst → m_stream_cleanup, was denselben h2_stream-Pointer zweimal auf das spurge-Cleanup-Array schiebt. Wenn c1_purge_streams später über spurge iteriert und h2_stream_destroy aufruft, trifft der zweite Aufruf bereits freigegebenen Speicher. Das ist die klassische Double-Free-Bedingung.

Der DoS-Pfad ist damit trivial. Ein einziger angreifender Client kann mit einer einzigen TCP-Verbindung und zwei Frames einen Worker zum Absturz bringen. Apache restartet den Worker im Standardmodus, aber wenn der Angreifer das in Schleife fährt, geht die effektive Verfügbarkeit der HTTPS-Frontline gegen Null.

Der RCE-Pfad ist die strukturell schwere Komponente. Die Apache Portable Runtime kennt zwei Allokatoren für ihren Pool-Mechanismus: einen privaten Heap-Allokator und den mmap-basierten Allokator. Auf Debian, Ubuntu und allen davon abgeleiteten Distributionen ist der mmap-Allokator der Default. Ein Angreifer kann die freigegebene virtuelle Adresse über mmap-Reuse mit einer eigens präparierten, gefälschten h2_stream-Struktur belegen, deren Pool-Cleanup-Funktion auf system() zeigt, und die Apache-Scoreboard-Memory als stabilen Container nutzen, um die Ausnutzung deterministisch zu machen.

Wer ist betroffen?

Eine kompakte Übersicht über betroffene und nicht betroffene Konfigurationen:

Wer in den letzten acht Tagen Apache 2.4.66 mit mod_http2 auf einer Debian-/Ubuntu-Basis im Internet exponiert hat, hat damit acht Tage einen Pre-Auth-RCE-Pfad gefahren. Ich behandle den Bestand operativ als „bis zum Beweis des Gegenteils kompromittierbar“ — kein Vollalarm-Zustand „kompromittiert“, aber kein Vertrauensstand wie vor dem 5. Mai.

Auswirkungen

CVSS-Wert 8.8 (High), Apache klassifiziert das Advisory als Critical wegen der Kombination aus trivialem DoS-Pfad und dokumentiertem RCE-Pfad auf Debian-Default. Im DACH-Mittelstand ist die betroffene Konstellation die Standardform: Apache 2.4 ist der Default-Webserver in Plesk, cPanel, ISPConfig und als Standard-Container-Image für PHP-Workloads. HTTP/2 ist seit etwa 2018 auf den meisten DACH-Mandanten-Hostings aktiviert.

Eine kompromittierte Webserver-Frontline auf einem TYPO3- oder Sylius-Mandanten-Host bedeutet operativ den Zugriff auf den lokalen Klartext-Source-Code, die laufenden PHP-FPM-Pools mit allen aktiven Backend-User-Sessions, die Datenbank-Verbindung über das in der Konfiguration hinterlegte Credential-Paar, den Cloud-Provider-Token aus dem systemd-Unit oder dem Container-Init, den Backup-Pfad und damit alle historischen Inhalte des Mandanten. Auf Sylius-Hostings kommt der direkte Zugriff auf das Stripe-/Mollie-/Adyen-API-Credential hinzu, wenn es als Umgebungsvariable konfiguriert ist.

Mitigation und Sofortmaßnahmen

Drei Pfade, je nach Wartungsfenster und Distribution-Disziplin.

Pfad 1 — Distribution-Patch (empfohlen)

# Debian / Ubuntu
sudo apt-get update
sudo apt-get install --only-upgrade apache2

# RHEL / Rocky / AlmaLinux
sudo dnf upgrade httpd

# Version prüfen
apache2 -v   # bzw. httpd -v
# Erwartet: Apache/2.4.67 oder höher

Pfad 2 — Container-Image neu ziehen

# Standard-Docker-Image
docker pull httpd:2.4
docker pull httpd:2.4-alpine

# In Compose-Setups
docker compose pull
docker compose up -d --force-recreate webserver

# In Helm-Charts
helm upgrade <release> <chart> \
  --set image.tag=2.4.67 \
  --reuse-values

Pfad 3 — Stopgap, wenn das Wartungsfenster nicht in 24 Stunden öffnet

# /etc/apache2/conf-available/disable-http2.conf
# Apache zwingt HTTP/1.1 zurück, mod_http2 wird nicht angesprochen
Protocols http/1.1

# Linux: Konfiguration aktivieren und Apache reloaden
sudo a2enconf disable-http2
sudo systemctl reload apache2

# RHEL-Linie
echo "Protocols http/1.1" | sudo tee /etc/httpd/conf.d/disable-http2.conf
sudo systemctl reload httpd

Verifizieren, dass HTTP/2 tatsächlich aus ist:

curl --http2 -I mandant.example.com 2>&1 | head -5
# Erwartet: HTTP/1.1 200 OK (nicht HTTP/2 200)

ModSecurity erkennt die Trigger-Sequenz an der TCP-Schicht nicht direkt — eine WAF-Regel ist primär für Wiederholungs-Trigger-Versuche sinnvoll, nicht als alleinige Mitigation. Der Patch bleibt die einzige vollständige Lösung.

Detection und Prüfung

Drei komplementäre Detection-Pfade, die ich parallel fahre.

Pfad 1: Access-Log-Pattern für unrealistische HEADERS-/RST-Sequenzen

Auf den letzten 7–10 Tagen prüfen. Apache logt RST_STREAM-Frames im normalen mod_http2-Logging-Pfad nicht detailliert; der Indikator ist indirekt — kurze Connection-Lifetime mit sofortigem Stream-Reset und HTTP-Status 400/499.

# Apache-Error-Log auf mod_http2-Crash-Hinweise prüfen
sudo grep -E "h2_(stream|mplx)|child pid .* exit signal|Segmentation fault" \
  /var/log/apache2/error.log* | tail -50

Pfad 2: Falco-Regel für Apache-Worker-Crashes mit ungewöhnlichem Process-Tree

# /etc/falco/rules.d/apache-h2-crash.yaml
- rule: Apache worker unexpected exit with mod_http2
  desc: Apache worker died abnormally while serving mod_http2 — possible CVE-2026-23918 exploitation
  condition: >
    proc_exit and
    proc.name in (apache2, httpd) and
    proc.exitcode != 0 and
    proc.aname[1] in (apache2, httpd)
  output: >
    Apache worker exited abnormally: pid=%proc.pid exitcode=%proc.exitcode cmdline=%proc.cmdline
  priority: WARNING
  tags: [apache, mod_http2, cve-2026-23918]

Pfad 3: Tetragon-TracingPolicy als eBPF-Alternative

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: apache-mod-http2-anomaly
spec:
  kprobes:
    - call: "sys_munmap"
      syscall: true
      args:
        - index: 0
          type: "uint64"
        - index: 1
          type: "size_t"
      selectors:
        - matchBinaries:
            - operator: "In"
              values:
                - "/usr/sbin/apache2"
                - "/usr/sbin/httpd"
          matchActions:
            - action: "Audit"

PoC-Validierung im eigenen Mandanten-Bestand

Wer eine eigene Staging-Umgebung mit Apache 2.4.66 hat, kann mit einem der öffentlichen PoCs die Detection-Regel im passiven Modus validieren — der xeloxa-PoC unterstützt einen --detection-only-Modus, der den Crash-Trigger nicht ausführt, sondern nur die Fingerprint-Sequenz sendet. Nicht gegen Produktiv-Hosts laufen lassen.

Betreiberempfehlung

Die operative Frage ist nicht „patchen oder nicht?“, sondern „wann öffnet sich das nächste Wartungsfenster?“ und „wer trägt das Risiko der acht Tage zwischen Disclosure und Eigenpatch?“.

Operational Decision Block — Patch-Fenster jetzt vs. Stopgap-Fallback

• Sofort patchen, wenn der Host eine TYPO3- oder Sylius-Mandanten-Frontline trägt, öffentlich auf 443 erreichbar ist, und Apache 2.4.66 mit mod_http2 aus dem Debian-/Ubuntu-Repo läuft.
• Stopgap HTTP/1.1-Fallback einsetzen, wenn das Wartungsfenster nicht in 24 Stunden öffnet, der Host aber öffentlich erreichbar ist. Performance-Einbruäch durch HTTP/2-Verzicht ist messbar, aber tragbar.
• Wartungsfenster im Standardzyklus möglich, wenn der Host hinter einem HTTP/1.1-Downstream-Reverse-Proxy steht und der mod_http2-Pfad nicht erreichbar ist.
• Reine Awareness, wenn keine Apache-2.4.66-Instanz im Mandanten-Bestand erreichbar ist (nginx-Only-Stack).

Mittelstand

Distribution-Patch im laufenden Wartungsfenster. Wer unattended-upgrades auf Debian/Ubuntu konfiguriert hat, sollte den Lauf der nächsten 24 Stunden überprüfen — der 2.4.67-Bump kommt typischerweise mit der apt-security-Linie, braucht keinen Reboot, aber den Apache-Reload. Stopgap-HTTP/1.1-Fallback ist die zweite Verteidigungslinie.

Enterprise

Kuratierte Image-Promotion auf gepatchte Apache-2.4.67-Base-Images. WAF-Regel auf die HEADERS-/RST-Frame-Sequenz als zusätzliche Schicht, die auch nach dem Patch sinnvoll bleibt. Mandanten-Frontline-Hosts in den 24h-Frühpatch-Pool nehmen, nicht in den 14-Tage-Standardzyklus.

Kubernetes-Plattform

Container-Images mit Apache 2.4.66 neu bauen. Helm-Chart-Pin auf gepatchten Tag ziehen, Cluster-weiten Rollout im Standard-Wartungsfenster, mit Vorzug für Mandanten-Frontline-Hosts. Falco-Regel aus der Detection-Sektion Cluster-weit ausrollen.

• Sub-Szenario Kubernetes-Ingress mit Apache-Sidecar: Sidecar-Image-Tag im Pod-Template-Spec aktualisieren, Rolling-Update über kubectl rollout restart.
• Sub-Szenario Helm-basierte TYPO3-Charts:image.repository und image.tag im values.yaml prüfen, oft auf älteren Apache-Tags gepinnt.

Deklarative Stacks (NixOS / Talos / Flatcar / Wolfi)

NixOS-Module für apacheHttpd aktualisieren, sobald der nixpkgs-Bump für 2.4.67 gemerged ist (Stand 13.05.: bereits gemerged, in den meisten Channels verfügbar). Wolfi-basierte Apache-Container schließen den Patch über das apk-Index-Update der laufenden Woche — Image-Rebuild auf Wolfi-Base mit apk upgrade triggern.

Was ich konkret getan habe

Ich habe am 13.05.2026 zwischen 07:15 und 08:30 CEST drei Disziplinen durchgezogen.

Zuerst die Inventur: alle Mandanten-Hosts unter eigenem Betrieb mit apache2 -v bzw. httpd -v abgefragt, plus die Container-Tags aller TYPO3- und Sylius-Mandanten-Images mit docker image ls | grep httpd. Drei Hosts standen auf 2.4.66 (alle Debian-12-Base, alle mit mod_http2 aktiviert), zwei Container-Images auf httpd:2.4.66. Die übrigen Hosts laufen auf nginx oder bereits auf 2.4.67.

Dann der Patch: apt-get install --only-upgrade apache2 auf den drei betroffenen Hosts, Container-Images mit docker pull httpd:2.4 && docker compose up -d --force-recreate webserver neu gezogen. Auf einem Plesk-managed Host musste der Distribution-Patch über das Plesk-Web-UI gezogen werden, weil das apt-Repo dort durch ein Plesk-Mirror überlagert ist — Notiz im Mandanten-Onboarding-Leitfaden ergänzt.

Schließlich die Detection-Stage: Falco-Regel Apache worker unexpected exit with mod_http2 in zwei Cluster-Plattformen aktiviert. Access-Log-Pattern-Check auf den letzten 10 Tagen ergab in keinem Mandanten-Log auffallende Häufungen kurzer Connection-Lifetimes mit Stream-Reset.

Die strukturelle Lehre dieser Lücke liegt im Zusammenspiel zwischen nghttp2-Callback-Reihenfolge und der APR-Allokator-Wahl. Der Fehler in 2.4.66 liegt nicht in nghttp2, sondern in der Annahme von mod_http2, dass die beiden Callbacks bei einem unregistrierten Stream nicht beide den Cleanup-Pfad triggern. Sie tun es. Die APR-Allokator-Wahl ist der zweite Hebel: auf Debian-basierten Distributionen wird historisch mmap als Default kompiliert. Genau dieser mmap-Default ist der Hebel, der aus dem Double-Free einen Pre-Auth-RCE-Pfad macht. Das ist der direkte Anschluss an die Linie, die ich mit CVE-2026-31431 „Copy Fail“ als „die Distribution ist die Architektur“-Befund aufgemacht habe.

Fazit

CVE-2026-23918 ist im Mai-Patch-Cycle nicht der spektakulärste Befund — keine aktive Ausnutzung in freier Wildbahn, kein CISA-KEV-Eintrag, kein BSI-Sondergutachten. Was den Befund operativ schwer macht, ist seine Trivialität auf der Trigger-Seite kombiniert mit der strukturellen RCE-Pfad-Bedingung auf Debian-Default. Eine TCP-Verbindung, zwei Frames, ein Mandanten-Host weniger. Und seit acht Tagen liegen die PoCs öffentlich.

Die Frage lautet nicht, ob 2.4.67 ausreicht — sie reicht für den konkreten Codepfad, den Apache am 5. Mai geschlossen hat. Sie lautet, ob Ihre Plattform die HTTP-Front-End-Schicht als eigene Patch- und Detection-Pflicht führt, oder ob Sie die Front-End-Frontline weiterhin als „kommt mit dem Distribution-Update mit“-Komponente behandeln. Die strukturelle Antwort ist die erste Variante, mit eigenem Inventar, eigener Frühpatch-Kohorte und eigener WAF-Regel-Disziplin.

Persönlicher Hintergrund und technische Details zur Härtung von Apache-Frontlines im DACH-Mittelstand: ole-hartwig.eu.