Kritische Apache-Lücke ermöglicht Remote Code Execution über HTTP/2

Gerade erst hat PHP2Shell die Webserver-Welt in Aufruhr versetzt, doch schon steht der nächste Albtraum für Admins ins Haus: In Apache HTTP Server wurde mit CVE-2026-119618 eine kritische Schwachstelle entdeckt, die Angreifern ohne Anmeldung die Ausführung von Schadcode auf dem Server ermöglicht. Die Apache Software Foundation hat das Problem zwar bereits mit der Version 2.4.71 behoben, doch auf unzähligen Systemen weltweit dürfte die Lücke noch offen stehen.

Erinnerung an PHP2Shell: Das Muster wiederholt sich

Wer Mitte Oktober die Nachrichten verfolgt hat, kennt das Spiel: Unter dem Namen PHP2Shell verbargen sich zwei kritische Remote-Code-Execution-Lücken (CVE-2026-109618 und CVE-2026-109619) direkt im Kern der Skriptsprache PHP, die beide mit einem CVSS-v4.0-Score von 9,2 eingestuft wurden. Die Lücken lauerten in der Speicherverwaltung von PHP und griffen, wenn das konfigurierte Speicherlimit (memory_limit) mitten in einem Request anschlug – das Ergebnis war eine korrupte Speicherverwaltung, über die Angreifer eigenen Code im Nutzerkontext des Webservers ausführen konnten. Besonders heikel: Sowohl Apaches mod_php als auch PHP via FPM und LiteSpeeds LSAPI waren anfällig, weshalb das BSI damals zum sofortigen Einspielen der Notfall-Updates riet.

CVE-2026-119618 ist nun quasi die Fortsetzung desselben Problems an anderer Stelle: wieder eine weit verbreitete Open-Source-Komponente, wieder ein Fehler in der Speicherverwaltung, wieder unauthentifiziertes RCE aus der Ferne. Der Unterschied: Diesmal trifft es nicht die Anwendungslogik, sondern den Webserver selbst.

Was ist CVE-2026-119618?

Die Schwachstelle sitzt im HTTP/2-Modul mod_http2 von Apache, genauer in der Funktion assign_headers(). Technisch handelt es sich um eine Race Condition (CWE-362): Bearbeitet der Server mehrere HTTP/2-Requests parallel über mehrere Threads, kann ein Thread in Speicher schreiben, der einem anderen Thread gehört – weil eine gemeinsam genutzte, lock-freie Speicherverwaltung nicht sauber synchronisiert wird. Die Folge ist eine Heap-Korruption, die sich nachweislich zu Remote Code Execution ausbauen lässt.

Bewertet wurde die Lücke von Red Hat mit der Höchstwertung CVSS 9,8 ("kritisch") – Angriffsvektor Netzwerk, keine Authentifizierung nötig, keine Nutzerinteraktion erforderlich. Besonders brisant: Laut Red Hat haben öffentliche Forschungen bereits einen zuverlässig funktionierenden Exploit gegen einen Server in Standardkonfiguration mit aktiviertem mod_http2 demonstriert. Entdeckt wurde der Fehler unabhängig voneinander von Anthropics OSS-Scanner sowie von Anthony Weems und Simon Scannell von der Google Cloud Vulnerability Research.

Welche Systeme sind betroffen?

Betroffen sind alle Apache-HTTP-Server-Installationen, die HTTP/2 aktiviert haben – also h2 oder h2c über die Protocols-Direktive. Server, die ausschließlich HTTP/1.1 ausliefern, sind nicht verwundbar.

Details zu RHEL: Red Hat stuft die Schwachstelle für RHEL 9 und RHEL 10 nur als "wichtig" ein, weil diese Pakete jeden HTTP/2-Stream aus einem separaten Allocator bedienen und der Angriff damit deutlich komplexer wird; RHEL 8 und älter enthalten den betroffenen Code gar nicht. Für die betroffenen RHEL-Strecken (9 und 10 inklusive EUS/E4S) sind bereits gepatchte mod_http2-Pakete über mehrere RHSA-Advisories verfügbar. Übrigens: Im selben RHEL-Update wurde mit CVE-2026-57941 gleich eine weitere mod_http2-Schwachstelle (Use-after-free) mitgefixt – ein Update lohnt sich also doppelt.

Die Reichweite ist enorm. Laut Analysedaten von Wiz sind 64 Prozent der untersuchten Cloud-Umgebungen anfällige Ressourcen im Einsatz, und 51 Prozent davon betreiben betroffene Instanzen öffentlich erreichbar im Internet.

Wie hoch ist das konkrete Risiko?

Der wahrscheinlichste Angriffsweg läuft über reguläre HTTP/2-Verbindungen: Ein entfernter Angreifer sendet gezielt konstruierte, parallele Requests an den Server, um die Race Condition auszulösen. Gelingt die Ausnutzung, läuft Schadcode mit den Rechten des Webserver-Prozesses – im schlimmsten Fall bedeutet das die komplette Übernahme des Systems, Zugriff auf sensible Daten und die Störung des gesamten Betriebs. Eine Authentifizierung oder Nutzerinteraktion ist nicht erforderlich. Zum Zeitpunkt der Veröffentlichung gab es zwar noch keine Berichte über aktive Ausnutzung im Feld, doch die demonstrierte Exploit-Zuverlässigkeit macht das eher zu einer Frage der Zeit.

Was Admins jetzt tun sollten

• Sofort updaten: Apache HTTP Server auf Version 2.4.71 bringen, die am 11. November 2026 erschienen ist und den Fix enthält.
• Verteilte Systeme prüfen: Wer mod_h2 als Standalone-Modul von GitHub einsetzt, muss eine Version nach 2.0.42 installieren.
• Distributionen einschlagen: Für RHEL 9 und 10 (inklusive EUS- und E4S-Strecken) stehen die korrigierten mod_http2-Pakete bereit; auch Gentoo, AlmaLinux und Microsofts Azure Linux arbeiten bereits an Updates.
• Notfall-Workaround: Lässt sich ein Update nicht sofort einspielen, sollte das HTTP/2-Modul deaktiviert werden – etwa durch Entfernen oder Auskommentieren der Zeile LoadModule http2_module bzw. durch die Beschränkung der Protocols-Direktive auf HTTP/1.1. Das kostet Performance, schließt aber die Angriffsfläche.

Fazit

Nach PHP2Shell ist CVE-2026-119618 bereits die zweite Lücke innerhalb weniger Wochen, die auf dieselbe bittere Wahrheit hinweist: Die Grundbausteine des Webs – PHP, Apache, HTTP/2 – sind Software wie jede andere, und Fehler in der Speicherverwaltung lassen sich zu vollwertigen Angriffen ausbauen. Der einzige verlässliche Schutz bleibt konsequentes, schnelles Patch-Management. Wer HTTP/2 im Einsatz hat, sollte das Update auf 2.4.71 heute noch einspielen und nicht warten, bis der erste Exploit in der freien Wildbahn auftaucht.