Apache 2.4.71 schließt kritische HTTP/2-Lücke CVE-2026-119618 in mod_http2

Die Apache Software Foundation hat am 11. November 2026 Apache HTTP Server 2.4.71 veröffentlicht und damit drei Sicherheitslücken geschlossen. Die wichtigste ist CVE-2026-119618 im Modul mod_http2, die Apache selbst als kritisch einstuft: Ein Fehler bei der Synchronisierung paralleler Threads kann den Heap beschädigen und zur Ausführung von Code führen. Betroffen sind die Versionen 2.4.55 bis 2.4.70.

Relevant ist das für jeden Apache-Server, auf dem HTTP/2 aktiv ist, also für viele Webserver mit HTTPS. Server, die nur HTTP/1.1 ausliefern, sind laut Red Hat nicht verwundbar. Admins sollten das Update ihrer Distribution zügig einspielen und HTTP/2 vorübergehend abschalten, wo das nicht sofort geht.

Was ist passiert?

Nach dem Sicherheitsbericht des Apache-Projekts liegt der Fehler in der Funktion assign_headers() von mod_http2. Red Hat erklärt den Hintergrund: HTTP/2 erlaubt viele gleichzeitige Anfragen über eine Verbindung, mod_http2 verarbeitet sie mit mehreren Threads. Durch einen Fehler in der Thread-Sicherheit schreibt ein Arbeits-Thread in Speicher, der dem Verbindungs-Thread gehört. Ein Angreifer, der den Webserver erreicht, kann das nach Red Hats Einschätzung ohne Anmeldung ausnutzen.

Gemeldet haben die Lücke laut Apache der OSS Scanner von Anthropic (am 26. Oktober) sowie Anthony Weems und Simon Scannell von Google Cloud Vulnerability Research (am 3. November), nach Angaben von SecurityWeek und Wiz unabhängig voneinander. Neben Apache selbst sind die eigenständig ausgelieferten mod_h2-Versionen 2.0.8 bis 2.0.42 von GitHub betroffen.

Version 2.4.71 schließt zwei weitere Lücken: CVE-2026-106023 in mod_md (Stufe „important“, Absturz von Kindprozessen, betroffen 2.4.30 bis 2.4.70) und CVE-2026-109163 in mod_vhost_alias (Stufe „low“, betroffen 2.4.69 und 2.4.70).

Wer ist betroffen?

Betroffen sind Apache-Installationen von 2.4.55 bis 2.4.70, bei denen HTTP/2 (h2 oder h2c) über die Direktive Protocols eingeschaltet ist. Red Hat Enterprise Linux 8 und älter sind laut Red Hat nicht betroffen. Für RHEL 9 und 10 stuft Red Hat die Lücke nur als „Important“ ein, weil die dort ausgelieferten mod_http2-Pakete jedem HTTP/2-Stream einen eigenen Speicherverwalter geben und das die Ausnutzung deutlich erschwert. Debian hat für Trixie mit DSA-6620-1 das Paket 2.4.71-1~deb13u1 bereitgestellt. Für andere Distributionen zählt der jeweilige Sicherheitshinweis, nicht allein die Versionsnummer, weil Distributionen Korrekturen oft zurückportieren.

Wie kritisch ist das?

Red Hat bewertet die Lücke mit CVSS 3.1 9,8 (Angriff über das Netz, keine Anmeldung, keine Nutzeraktion). Die Lage zur Ausnutzung ist uneinheitlich: Red Hat schreibt, öffentliche Forschung habe einen zuverlässigen Exploit gegen einen Server mit Standardkonfiguration und aktivem mod_http2 gezeigt, nennt die Arbeit aber nicht. Wiz meldete zur Veröffentlichung seines Beitrags am 11. November weder einen verfügbaren Exploit noch Angriffe. Ein öffentlicher Proof of Concept auf GitHub zeigt laut SecurityWeek Speicherbeschädigung und Abstürze, aber keine Codeausführung. Belege für Angriffe liegen bislang nicht vor. Bei einer Lücke ohne Anmeldung in einem so verbreiteten Webserver ist das aber kein Grund zu warten.

Was sollten Admins jetzt tun?

• Inventar: Version prüfen, etwa mit apache2 -v (Debian, Ubuntu) oder httpd -v (RHEL-Familie), und mit apachectl -M | grep http2 klären, ob mod_http2 geladen ist.
• Konfiguration: In den Konfigurationsdateien nach der Direktive Protocols suchen. Steht dort h2 oder h2c, ist HTTP/2 aktiv. Die Direktive kann global, je VirtualHost und in Moduldateien stehen.
• Patchen: Apache 2.4.71 oder das korrigierte Paket der Distribution einspielen und den Dienst neu starten.
• Übergangslösung: Wo das Update nicht sofort möglich ist, HTTP/2 abschalten, zum Beispiel mit Protocols http/1.1, wie es Wiz beschreibt. Dabei alle Stellen mit h2 oder h2c anpassen.
• Container und Images: Eigene Images auf Basis von httpd oder Distributions-Images neu bauen, sobald die Basis aktualisiert ist.
• Überwachen: Error-Logs auf ungewöhnlich häufige Abstürze von Kindprozessen prüfen.

Einordnung für Unternehmen

Apache steckt in vielen Umgebungen an Stellen, die niemand als „den Webserver“ führt: in Appliances, Hosting-Panels, Intranet-Anwendungen und Containern. Die Lücke betrifft nur Versionen ab 2.4.55 und nur mit HTTP/2, das grenzt den Kreis ein. Laut SecurityWeek weist der Wordfence-Hersteller Defiant WordPress-Betreiber darauf hin, dass sich die Lücke nicht über WordPress-Updates schließen lässt, weil sie im Webserver liegt. Zuständig ist also der Betreiber des Servers oder der Hoster.

Passende Anleitungen auf S-EDV

• WordPress nativ auf Ubuntu installieren: LAMP-Stack mit Apache, MariaDB und PHP-FPM (ohne Docker)
• KeyHelp: Zusätzliche Apache-Anweisungen je Domain für Header, Rewrite und Caching nutzen
• HTTP/2 Bomb (CVE-2026-49975): Kritische DoS-Lücke trifft nginx, Apache, IIS und Envoy

Quellen

• Apache: Sicherheitslücken in Apache HTTP Server 2.4
• Red Hat: Eintrag zu CVE-2026-119618
• Debian: Security Tracker zu CVE-2026-119618
• Wiz: Analyse zu CVE-2026-119618
• SecurityWeek: Bericht zum Apache-Update