CVE-2026-119618: Kritische Apache HTTP/2-Schwachstelle ermöglicht Remote-Code-Ausführung

Apache hat ein dringendes Sicherheitsupdate veröffentlicht, das CVE-2026-119618 adressiert, eine kritische Schwachstelle für Remote-Code-Ausführung im mod_http2-Modul des Apache HTTP Server. Der Fehler betrifft Apache HTTP Server Versionen 2.4.55 bis 2.4.70 und kann einem nicht authentifizierten, entfernten Angreifer erlauben, den Heap-Speicher zu korrumpieren und möglicherweise beliebige Befehle auf verwundbaren Servern auszuführen.

Die Schwachstelle entsteht durch unsachgemäße Synchronisation, wenn Apache gleichzeitige HTTP/2-Anfragen verarbeitet. Mehrere Threads können auf gemeinsam genutzte Ressourcen ohne ausreichende Koordination zugreifen, was eine Race Condition erzeugt, die einem Thread erlaubt, den Speicher zu modifizieren, der von einem anderen genutzt wird. Ein erfolgreicher Angriff kann den internen Heap des Servers beschädigen und letztendlich zu einer Remote-Code-Ausführung führen.

Nur Apache-Installationen mit aktivierter HTTP/2-Funktionalität sind dem bekannten Angriffspfad ausgesetzt. Server, die ausschließlich für HTTP/1.1 konfiguriert sind, erreichen die verwundbare mod_http2-Funktionalität nicht. HTTP/2 kann mit h2 für TLS-Verbindungen oder h2c für reines HTTP/2 über die Protokoll-Direktive von Apache aktiviert werden.

Vertrieb kontaktieren

Apache hat die Schwachstelle in HTTP Server 2.4.71 behoben, veröffentlicht am 11. November 2026. Eigenständige Versionen von mod_h2 von GitHub-Versionen 2.0.8 bis 2.0.42 sind ebenfalls betroffen. Die offizielle Empfehlung von Apache identifiziert derzeit keine separat veröffentlichte, behobene eigenständige mod_h2-Version.

Red Hat hat der Schwachstelle einen CVSS 3.1-Score von 9.8 aufgrund der allgemeinen Bewertung zugewiesen, wobei die Ausnutzung netzwerkzugänglich und von geringer Komplexität ist und weder Authentifizierung noch Benutzerinteraktion erfordert. Red Hat erklärt weiter, dass die Forschung eine zuverlässige Ausnutzung gegen einen standardkonfigurierten Server mit aktiviertem mod_http2 gezeigt hat.

Jedoch dokumentieren weder Apache noch die überprüften Sicherheitsberichte zum 12. November 2026 Ausnutzungen in realen Angriffen. Auch Wiz berichtete zum Zeitpunkt der Veröffentlichung über keine bekannten In-the-Wild-Ausnutzungen. Organisationen sollten dennoch die Behebung priorisieren, da die Schwachstelle aus der Ferne erreichbar ist und die technische Ursache nun öffentlich bekannt ist.

Organisationen können ihre Verteidigung gegen aufkommende Ausnutzungen mit der AI-Native Detection Intelligence Platform von SOC Prime stärken, die es Sicherheitsteams ermöglicht, Bedrohungsinformationen zu operationalisieren und die Erkennungstechnik und Bedrohungsjagd über SIEM, EDR, XDR und Data Lake-Umgebungen zu beschleunigen.

Erkennen Sie CVE-2026-119618, indem Sie verwundbare, internetzugängliche Apache-Server mit aktiviertem HTTP/2 identifizieren und verdächtige HTTP/2-Aktivitäten mit Apache-Abstürzen, abnormalen Kindprozessen, unerwarteten Befehlsausführungen, neu erstellten Dateien und ungewöhnlichen ausgehenden Netzwerkverbindungen in Verbindung bringen.

Erkennungsinhalte sind möglicherweise nicht für jede CVE verfügbar. Prüfen Sie die SOC Prime Platform für die aktuelle Abdeckung. Wenn relevante Erkennungen noch nicht verfügbar sind, prüfen Sie erneut, da ständig neue Bedrohungsdaten und Erkennungsinhalte hinzugefügt werden.

CVE-2026-119618 Analyse

CVE-2026-119618 betrifft Apache HTTP Server Versionen 2.4.55 bis 2.4.70, wenn die verwundbare mod_http2-Funktionalität vorhanden und HTTP/2 aktiviert ist. Das eigenständige mod_h2-Projekt ist von Version 2.0.8 bis 2.0.42 betroffen. Apache stuft das Problem als kritisch ein und ordnet es CWE-362 zu, gleichzeitige Ausführung mit gemeinsam genutztem Speicher ohne ordnungsgemäße Synchronisation.

Die Schwachstelle existiert in der assign_headers() Funktion, die von Apaches HTTP/2-Verarbeitung verwendet wird.

HTTP/2 unterscheidet sich erheblich von HTTP/1.1, weil mehrere Streams gleichzeitig über eine einzige Verbindung betrieben werden können. Das mod_http2-Modul von Apache verwendet daher mehrere Threads, um Anfragen zu verarbeiten und HTTP/2-Streams gleichzeitig zu verwalten.

Das Problem tritt auf, wenn diese Threads mit gemeinsam genutztem Speicher ohne ausreichende Synchronisation interagieren. Laut technischer Bewertung von Red Hat kann ein HTTP/2-Stream-Worker in den Speicher schreiben, der dem Verbindungsthread gehört, durch einen gemeinsam genutzten, sperrfreien Allokator.

Unter von Angreifern kontrolliertem Timing kann gleichzeitiger Zugriff den Heap beschädigen.

Heap-Korruptions-Schwachstellen können verschiedene Auswirkungen haben, abhängig vom Speicherlayout und der Kontrolle durch den Angreifer. Fehlgeschlagene Ausnutzung kann Apache-Worker-Prozesse zum Absturz bringen, während eine ausreichend kontrollierte Korruption den Programzustand modifizieren oder die Ausführung umleiten kann.

Red Hat gibt an, dass eine erfolgreiche Ausnutzung einem nicht authentifizierten Angreifer ermöglichen kann, beliebige Befehle mit den Rechten des Apache HTTP Server-Prozesses auszuführen. Dies kann Angreifern Zugang zu Anwendungsdaten, Konfigurationsdateien, Anmeldeinformationen, die dem Webserver zur Verfügung stehen, und andere Ressourcen im Sicherheitskontext geben.

Die Schwachstelle ist insbesondere auf internetzugänglichen Systemen besorgniserregend, weil kein gültiges Konto, Passwort, API-Schlüssel oder andere Authentifizierung erforderlich ist. Ein Angreifer benötigt nur Netzwerkzugriff auf einen betroffenen HTTP/2-Endpunkt.

Die Exposition hängt dennoch von der Konfiguration ab.

Der Apache HTTP Server muss tatsächlich HTTP/2 anbieten. Administratoren können dies durch die Protokoll-Direktive mit folgendem Befehl aktivieren:

Protocols h2 http/1.1

für HTTP/2 über TLS, oder:

Protocols h2c http/1.1

wo Klartext-HTTP/2 unterstützt wird.

Die Direktive kann global oder auf individuellen virtuellen Hosts konfiguriert werden, was bedeutet, dass Administratoren sowohl serverweite als auch per-Site-Konfigurationen inspizieren sollten, wenn sie die Exposition bewerten.

Ein Server, der eine betroffene Apache-Version ausführt, aber nur HTTP/1.1 bereitstellt, ist durch diesen Fehler nicht verwundbar. Red Hat bestätigt ausdrücklich, dass Systeme ohne aktiviertes HTTP/2 nicht den betroffenen Codepfad erreichen.

Apaches upstream betroffener Bereich sollte auch nicht blind auf Linux-Distributionen angewendet werden.

Red Hat Enterprise Linux 8 und frühere Versionen enthalten den verwundbaren Code nicht und sind nicht betroffen. RHEL 9 und RHEL 10 enthalten betroffene mod_http2-Pakete, jedoch stuft Red Hat das Problem auf diesen Plattformen als wichtig ein, nicht als kritisch.

Der Unterschied ergibt sich aus den Implementierungsdetails. In RHEL 9 und 10 erhält jeder HTTP/2-Stream einen separaten Speicher-Allokator anstatt denselben Allokator mit der Verbindung zu teilen. Red Hat gibt an, dass diese Architektur die Komplexität der Ausnutzung erheblich erhöht, obwohl betroffene Systeme dennoch Sicherheitsupdates benötigen.

Red Hat veröffentlichte korrigierte Pakete für mehrere RHEL 9- und RHEL 10-Streams am 11. November. Administratoren, die von Anbietern bereitgestellte Linux-Pakete verwenden, sollten das Sicherheitsupdate ihrer Distribution anwenden, anstatt die Verwundbarkeit allein von der ursprünglich aussehenden Apache-Version zu bestimmen, die vom Server angezeigt wird.

Apache HTTP Server 2.4.71 bietet die upstream Korrektur. Der Fix modifiziert das verwundbare Synchronisations- und Speicherverwaltungsverhalten, sodass gleichzeitige HTTP/2-Operationen nicht in unsicherer Weise mit den betroffenen gemeinsam genutzten Ressourcen interagieren können.

Die Schwachstelle wurde unabhängig durch zwei Forschungsarbeiten entdeckt.

Anthropics OSS Scanner meldete das Problem am 26. Oktober 2026 an das Sicherheitsteam von Apache unter der Kennung ANT-2026-MAPKT6MZ. Anthony Weems und Simon Scannell von Google Cloud Vulnerability Research meldeten die Schwachstelle unabhängig am 3. November. Apache veröffentlichte den Fix am 11. November.

Der CVE-Eintrag wurde am 11. November 2026 veröffentlicht.

Die CVE-2026-119618 PoC-Situation erfordert eine sorgfältige Interpretation. Red Hat gibt an, dass die öffentliche Forschung eine zuverlässige Ausnutzung gegen einen standardkonfigurierten Server mit aktiviertem mod_http2 demonstriert hat. Allerdings berichteten The Hacker News und Wiz, dass zum Zeitpunkt der Veröffentlichung kein öffentlich verfügbarer RCE-Exploit identifiziert worden war. Öffentliche GitHub-Projekte, die Scanner oder mit Ausnutzung in Verbindung stehende Tools beanspruchen, sollten daher nicht automatisch als validierter, waffenfähiger RCE-Code interpretiert werden.

Diese Unterscheidung ist im Betrieb wichtig. Verteidiger sollten annehmen, dass die Schwachstelle technisch ausnutzbar ist, während sie Behauptungen vermeiden, dass ein zuverlässiger, waffenfähiger Exploit bereits weit verbreitet ist, es sei denn, es gibt weitere Beweise.

Für die Erkennung von CVE-2026-119618 sollten Sicherheitsteams zunächst exponierte Systeme identifizieren, anstatt sich nur auf Exploit-Signaturen zu verlassen.

Administratoren können bestätigen, ob das HTTP/2-Modul geladen ist, indem sie:

apachectl -M | grep http2

verwenden. Sie sollten dann Apache-Konfigurationsdateien auf Protokoll-Direktiven mit h2 oder h2c überprüfen, einschließlich Direktiven, die innerhalb einzelner virtueller Hosts definiert sind.

Externe Serviceerkennung kann auch Server identifizieren, die HTTP/2 über TLS ALPN aushandeln. Versionserkennung allein kann jedoch irreführend sein, da Linux-Distributionen häufig Sicherheitsfixes zurückportieren, ohne den ursprünglich aussehenden Versionsstring zu ändern.

Laufzeit-Telemetrie sollte mit verdächtigem HTTP/2-Datenverkehr korreliert werden. Mögliche Verhaltensindikatoren sind wiederholte Apache-Worker-Abstürze, Segmentierungsfehler, anormale Neustarts, Speicherbeschädigungsnachrichten oder plötzliche Dienstinstabilität, die mit ungewöhnlichen HTTP/2-Anfrage-Bursts verbunden ist.

Da erfolgreiche Ausnutzung zur Befehlsausführung führen kann, sollten Endpunkt- und Host-Telemetrie ebenfalls auf ungewöhnliche Kindprozesse überprüft werden, die von Apache stammen.

Beispiele umfassen httpd oder apache2, die unerwartet Shells, Skriptausführungen, Download-Dienstprogramme oder Systemverwaltungsbefehle starten.

Sicherheitsteams sollten Prozessbeziehungen untersuchen wie:

httpd → /bin/sh

apache2 → bash

httpd → curl

apache2 → wget

oder andere Ausführungsketten, die nicht mit dem normalen Verhalten der gehosteten Anwendung übereinstimmen.

Dateierstellungen in temporären Verzeichnissen, Web-Roots, Startorten oder beschreibbaren Anwendungsordnern können ebenfalls auf Post-Exploitation-Aktivitäten hinweisen. Unerwartete ausgehende Verbindungen von Apache-Worker-Prozessen sollten ähnlich überprüft werden.

Es gibt derzeit keine vom Anbieter veröffentlichten kampagnenspezifischen CVE-2026-119618-IOCs wie bösartige IP-Adressen, Domains, Payload-Hashes oder Angreifer-Infrastrukturen, da Apache und die überprüften Quellen keine Ausnutzung in freier Wildbahn berichtet haben. Dies macht die Konfigurationsbewertung und verhaltensbasierte Überwachung wertvoller als statisches Indikator-Matching.

CVE-2026-119618 Minderung

Die primäre Behebung besteht darin, betroffene Apache HTTP Server-Installationen auf Version 2.4.71 zu aktualisieren oder das korrigierte Sicherheitspaket des Betriebssystemanbieters anzuwenden. Apache 2.4.71 wurde am 11. November 2026 veröffentlicht und enthält den upstream Fix.

Organisationen sollten Apache-Bereitstellungen mit aktiviertem HTTP/2 auf Internet zugänglichen Systeme priorisieren, da diese Systeme die verwundbare Funktionalität direkt unzuverlässigem Netzwerkverkehr aussetzen.

Administratoren sollten folgende Schritte unternehmen:

1. Inventarisierung von Apache HTTP Server-Deployments in Produktions-, Entwicklungs-, Cloud- und Container-Umgebungen.
2. Installation von Apache-Versionen 2.4.55 bis 2.4.70 identifizieren.
3. Überprüfen, ob mod_http2 geladen ist.
4. Globale und virtuelle Host-Protokoll-Direktiven auf h2 oder h2c untersuchen.
5. Upstream Apache-Deployments auf 2.4.71 oder höher aktualisieren.
6. Verteilen spezifikationsbezogene Pakete, wenn Apache durch Debian, Red Hat, Amazon Linux oder einen anderen Betriebssystemanbieter verwaltet wird.
7. Starten Sie Apache nach dem Patchen neu, um sicherzustellen, dass anfällige Worker-Prozesse nicht mehr laufen.
8. Überprüfen Sie die wirksame HTTP-Server-Konfiguration nach der Behebung.
9. Überprüfen Sie historische Telemetriedaten auf verdächtige Aktivitäten in internetzugänglichen Systemen, die vor dem Patchen exponiert waren.

Administratoren sollten nicht davon ausgehen, dass die Installation eines Betriebssystempakets mit einer Versionsnummer unter 2.4.71 bedeutet, dass das System weiterhin angreifbar ist. Anbieter wie Red Hat portieren Sicherheitsfixes in ihre eigenen Paketversionen zurück, sodass die relevante Distributionsberatung als maßgeblich behandelt werden sollte.

Die offizielle Empfehlung von Apache bietet keinen Workaround. Organisationen, die nicht sofort patchen können, können jedoch vorübergehend HTTP/2 aus exponierten Konfigurationen entfernen, um den Zugriff auf den bekannten verwundbaren Codepfad zu eliminieren. Wiz empfiehlt, den Server auf HTTP/1.1 zu beschränken, bis das Update bereitgestellt werden kann.

Zum Beispiel:

Protocols http/1.1

Organisationen, die diesen Workaround anwenden, sollten alle virtuellen Hosts überprüfen, da eine standortspezifische Konfiguration h2 oder h2c unabhängig aktivieren kann.

Das Entfernen von HTTP/2 kann die Anwendungsleistung und das Verhalten des Clients beeinträchtigen, daher sollte die Änderung getestet und als vorübergehende Risikominderung behandelt werden, anstatt als Ersatz für die Installation des Sicherheitsupdates.

Die CVE-2026-119618-Minderungsstrategie sollte auch die Reduzierung unnötiger Exposition umfassen. Administrative oder interne Apache-Dienste, die keine direkte Internetverbindung benötigen, sollten durch Netzwerksegmentierung, Load Balancer, Reverse Proxies, Firewall-Regeln oder private Adressierung eingeschränkt werden.

Organisationen, die eigenständige mod_h2-Versionen zwischen 2.0.8 und 2.0.42 verwenden, erfordern besondere Aufmerksamkeit. Apache identifiziert diese Versionen als betroffen, während The Hacker News berichtete, dass zum Zeitpunkt ihres Berichts vom 12. November keine korrigierte eigenständige Veröffentlichung veröffentlicht worden war. Das Deaktivieren von HTTP/2 oder das Migrieren zu einem Apache HTTP Server-Paket, das den upstream Fix enthält, kann deshalb notwendig sein, bis ein geeignetes eigenständiges Update verfügbar ist.

Wenn verdächtige Aktivitäten festgestellt werden, sollten Verteidiger den betroffenen Server isolieren, soweit betrieblich machbar, und Apache-Zugriffsprotokolle, Fehlerprotokolle, Systemprotokolle, Prozesstelemetrie, Netzwerkverbindungen sowie relevante Speicher- oder Absturzinformationen bewahren.

Erfolgreiche Ausnutzung sollte als potenzielle Serverkompromittierung behandelt werden, nicht nur als Dienstabsturz. Ermittler sollten nach neuen Dateien, Webshells, verändertem Anwendungscode, Persistenzmechanismen, gestohlenen Anmeldeinformationen, verdächtigem ausgehendem Datenverkehr und Beweisen für laterale Bewegungen suchen.

Anmeldeinformationen, die dem Apache-Prozess zugänglich sind, einschließlich Datenbankpasswörter, API-Schlüssel, Cloud-Anmeldeinformationen, TLS-Private-Keys oder Geheimnisse, die in der Anwendungskonfiguration gespeichert sind, sollten überprüft und gedreht werden, wenn Beweise darauf hindeuten, dass durch Angreifer kontrollierte Codeausführung stattgefunden hat.