Apache HTTP/2-Lücke CVE-2026-119618: Update auf 2.4.71

Was ist CVE-2026-119618?

CVE-2026-119618 ist eine kritische Sicherheitslücke in mod_http2, dem Modul, das im Apache HTTP Server den HTTP/2-Datenverkehr verarbeitet; sie kann zu Heap-Beschädigung und Remote-Code-Ausführung führen ^[1].

Apache beschreibt sie als „Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers()“, die „zu RCE führen kann“ ^[1]. CIRCL, das nationale Computer-Notfallteam Luxemburgs, erklärt, dass bei der parallelen Verarbeitung von HTTP/2-Streams ein Worker eine Header-Tabelle verändern kann, die für einen anderen Ausführungskontext angelegt wurde, und dieser unsichere Zugriff auf gemeinsam genutzten Speicher den Heap beschädigen kann ^[2].

Ein erfolgreicher Angreifer könnte Code mit den Rechten des Apache-Webserver-Prozesses ausführen, ohne sich anzumelden ^[2][4]. Laut BleepingComputer läuft Apache HTTP Server schätzungsweise auf etwa jeder fünften Website ^[4].

Die Korrektur im Upstream ändert einen einzigen Schreibzugriff in modules/http2/h2_request.c von der gemeinsam genutzten Request-Header-Tabelle auf die eigenen Eingabe-Header der aktuellen Anfrage ^[2].

Welche Apache-Versionen sind betroffen?

Betroffen sind Apache HTTP Server 2.4.55 bis 2.4.70 sowie die eigenständigen mod_h2-Versionen 2.0.8 bis 2.0.42 von GitHub; Version 2.4.71 behebt die Lücke ^[1].

Distributionspakete erschweren die Versionsprüfung. CIRCL rät Organisationen, die von Distributoren gepflegte Pakete nutzen, den Sicherheits-Backport zu überprüfen, statt sich nur auf die Upstream-Versionsnummer zu verlassen ^[2]. Red Hat stuft laut CIRCL seine Pakete für RHEL 9 und 10 als Important statt Critical ein, weil ihr Speicherallokator die Ausnutzung erschwert, und gibt RHEL 8 und frühere Versionen als nicht betroffen an ^[2].

Red Hat gibt einen allgemeinen CVSS-v3.1-Wert von 9,8 (Critical) an ^[2][3]. Apaches eigene Einstufung lautet Critical ^[1].

Ist mein Apache-Server verwundbar?

Nur wenn er einen betroffenen Build ausführt und tatsächlich HTTP/2-Verbindungen akzeptiert: Red Hat erklärt, dass Server, die nur HTTP/1.1 ausliefern, nicht verwundbar sind ^[3]. CIRCL betont, dass der Codepfad nicht schon dadurch erreichbar ist, dass mod_http2 installiert oder geladen ist ^[2].

• Die Direktive Protocols steuert HTTP/2: „h2“ aktiviert es über TLS und „h2c“ über unverschlüsselte Verbindungen ^[2].
• Der Standard im Apache-Kern ist http/1.1, und das Laden von mod_http2 ändert das nicht von selbst ^[2]. BleepingComputer merkt an, dass HTTP/2 standardmäßig aus ist ^[4].
• Ein virtueller Host kann eine eigene Protocols-Direktive setzen, sodass die alleinige Prüfung der globalen Konfiguration eine HTTP/2-fähige Website übersehen kann ^[2].
• Wenn ein Reverse-Proxy, Load Balancer oder CDN HTTP/2 beendet und nur HTTP/1.1 an Apache weiterleitet, macht die HTTP/2-Sitzung des Clients Apache für sich genommen nicht erreichbar; Sie sollten das Protokoll aber an jeder Station prüfen ^[2].

CIRCL schlägt vor, die Version und die geladenen Module (apachectl -v, apachectl -M), die konfigurierten virtuellen Hosts (apachectl -S) und jede explizite Protocols-Einstellung zu prüfen ^[2]. Ein Test, der zeigt, dass ein Endpunkt HTTP/2 akzeptiert, beweist nicht, dass sein Backend verwundbar ist, und ein negativer Test beweist nicht, dass jeder Port oder virtuelle Host HTTP/2 ablehnt ^[2].

Wie prüfe ich, ob mein Server HTTP/2 akzeptiert?

CIRCL schlägt zwei Prüfungen vor: die Apache-Konfiguration auf dem Server selbst durchsehen und dann das ausgehandelte Protokoll aus dem Netzwerk testen, am besten mit direkter Verbindung zu Apache statt über einen Proxy ^[2].

1. Version und Module prüfen. Mit apachectl -v sehen Sie die Version und mit apachectl -M, gefiltert nach http2, ob das Modul geladen ist ^[2].
2. Virtuelle Hosts auflisten. apachectl -S zeigt jeden konfigurierten virtuellen Host, was wichtig ist, weil jeder eine eigene Protocols-Zeile tragen kann ^[2].
3. Jede Protocols-Direktive finden. CIRCL nennt einen grep-Befehl, der /etc/apache2 und /etc/httpd nach expliziten Protocols-Einstellungen durchsucht, einschließlich Überschreibungen in virtuellen Hosts; die Pfade unterscheiden sich je nach Distribution ^[2].
4. Über TLS testen. Eine curl-Anfrage mit der Option --http2, die die HTTP-Version ausgibt, zeigt, ob ein HTTPS-Endpunkt HTTP/2 aushandelt ^[2].
5. Unverschlüsselt testen. curl mit --http2-prior-knowledge prüft, ob ein einfacher HTTP-Endpunkt h2c akzeptiert ^[2].

Lesen Sie die Ergebnisse sorgfältig. Eine Antwort, die HTTP/2 meldet, zeigt, dass der getestete Endpunkt HTTP/2 akzeptiert hat, bestätigt aber nicht, dass sein Apache-Backend verwundbar ist; ein negatives Ergebnis beweist nicht, dass jede Adresse, jeder Port oder virtuelle Host es ablehnt ^[2]. CIRCL rät, die tatsächlich wirksame Apache-Konfiguration und den Status des gepatchten Pakets beim Hersteller gemeinsam zu bestätigen ^[2]. In Cloud-Umgebungen warnt Wiz, dass eine kompromittierte Apache-Instanz zum Einstiegspunkt für seitliche Bewegungen zu benachbarten Microservices oder Cloud-Metadaten-Endpunkten werden kann, ein weiterer Grund, jede Instanz zu prüfen statt nur die öffentliche Website ^[5].

Wie behebe ich CVE-2026-119618?

Aktualisieren Sie auf Apache HTTP Server 2.4.71 oder neuer oder installieren Sie das gepatchte Paket Ihrer Distribution, starten Sie dann Apache neu und prüfen Sie, dass die laufenden Prozesse den neuen Build verwenden ^[2][1].

1. Apache aktualisieren. Installieren Sie 2.4.71 oder einen Hersteller-Build, der ausdrücklich für CVE-2026-119618 gepatcht ist ^[2].
2. Eigenständiges mod_h2 aktualisieren, falls Sie es nutzen, wie vom Hersteller angegeben; Wiz rät, über 2.0.42 hinauszugehen, während CIRCL warnt, nicht ungeprüft anzunehmen, dass es eine neuere eigenständige Version gibt ^[5][2].
3. Neu starten und prüfen, dass die laufenden Prozesse den korrigierten Build verwenden ^[2].
4. Wenn Sie noch nicht patchen können, HTTP/2 deaktivieren: Setzen Sie Protocols auf http/1.1, entfernen Sie h2 und h2c aus jedem überschreibenden virtuellen Host, testen Sie mit apachectl -t und laden Sie neu ^[2]. Das blockiert den Weg dieser Lücke, behebt aber nicht den Code ^[2].
5. Zugriff beschränken auf vertrauenswürdige Netze als vorübergehende Maßnahme, wo weder Patchen noch Protokolländerungen möglich sind ^[2].

Forscher von watchTowr fassten es laut BleepingComputer so zusammen: „patch now or drop h2 until you can“ (jetzt patchen oder h2 abschalten, bis es möglich ist) ^[4]. SecurityWeek berichtet, dass auch Defiant warnte, WordPress-Sicherheitsupdates könnten das Problem nicht lösen, da es den zugrunde liegenden Webserver betrifft ^[3].

Wird CVE-2026-119618 ausgenutzt?

Zum Zeitpunkt des Wiz-Beitrags vom 11. November 2026 gab es keinen verfügbaren Exploit und keine Berichte über Ausnutzung in freier Wildbahn ^[5]. Die Lage ändert sich aber schnell.

• Red Hat erklärt, öffentliche Forschung habe einen zuverlässigen Exploit gegen einen Server mit aktiviertem mod_http2 gezeigt, nennt die Forschung in seiner Mitteilung aber nicht ^[3]. CIRCL merkt an, dass dies für sich genommen keine Ausnutzung in freier Wildbahn belegt ^[2].
• Ein öffentlicher Proof of Concept auf GitHub berichtet, Speicherbeschädigung und Apache-Abstürze reproduziert zu haben, zeigt aber keine Remote-Code-Ausführung ^[3].
• Wiz-Daten zeigen, dass 64 % der Cloud-Umgebungen Ressourcen mit betroffenen Versionen enthalten und 51 % öffentlich erreichbare Instanzen haben; Wiz merkt an, dass dies die Konfiguration nicht berücksichtigt, es sich also nicht zwingend um ausnutzbare Systeme handelt ^[5][3].

CIRCL nennt Anzeichen, die untersucht werden sollten: unerwartete Worker-Abstürze, ungewöhnliche Neustarts, verdächtige Kindprozesse, nicht autorisierte Dateiänderungen und unerwartete ausgehende Verbindungen ^[2]. Dies sind Anhaltspunkte, keine bestätigten Kompromittierungsindikatoren, und Patchen entfernt keine vor dem Update eingerichtete Persistenz ^[2].

Wer hat die Apache-HTTP/2-Lücke gefunden?

Apache nennt als Entdecker den OSS Scanner von Anthropic, der die Lücke am 26. Oktober 2026 meldete, sowie Anthony Weems und Simon Scannell von Google Cloud Vulnerability Research, die sie am 3. November unabhängig meldeten ^[1].

Der Fund von Anthropic wird unter der internen Kennung ANT-2026-MAPKT6MZ geführt ^[1]. SecurityWeek beschreibt die beiden Meldungen als unabhängige Entdeckungen ^[3]. Es ist ein weiteres Beispiel dafür, dass automatisierte und KI-gestützte Werkzeuge schwerwiegende Fehler in weit verbreiteter Open-Source-Software finden; AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You beleuchtet, was dieser Trend bedeutet.

Die Korrektur wurde eingespielt und 2.4.71 am 11. November veröffentlicht, am selben Tag, an dem Apache das Problem auf der Mailingliste oss-security bekannt machte ^[1][2].

Was behebt Apache 2.4.71 sonst noch?

Apache HTTP Server 2.4.71 behebt insgesamt drei CVEs: eines kritisch, eines wichtig und eines niedrig ^[1].

• CVE-2026-106023 (wichtig): eine NULL-Pointer-Dereferenzierung in mod_md bei der Anfrageverarbeitung, die einen Kindprozess zum Absturz bringen kann; betrifft 2.4.30 bis 2.4.70 ^[1].
• CVE-2026-109163 (niedrig): ein Ein-Byte-Überschreiben des Stack-Puffers in mod_vhost_alias, das Apache als „after CVE-2026-63292“ bezeichnet (jene frühere Lücke wurde in 2.4.69 behoben); betrifft 2.4.69 und 2.4.70 ^[1].

Die vorherige Version, 2.4.69 im Oktober 2026, behob 20 CVEs ^[1]. Administratoren, die sie übersprungen haben, erhalten diese Korrekturen mit dem Wechsel auf 2.4.71 ebenfalls. Zu einer weiteren aktuellen Server-Lücke siehe CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers.

Was sollten Administratoren als Nächstes beobachten?

Achten Sie auf einen öffentlichen Exploit für Remote-Code-Ausführung, Backports der Hersteller für Ihre Distribution und Berichte über Angriffe in freier Wildbahn ^[3][5].

CIRCL empfiehlt, HTTP/2-fähige Instanzen zu inventarisieren, zu prüfen, ob der jeweilige mod_http2-Build betroffen ist, und exponierte Systeme unverzüglich zu patchen, mit Vorrang für aus dem Internet erreichbare Websites, APIs, Shared Hosting und Apache-Server hinter Frontends, die HTTP/2 weiterleiten ^[2]. Organisationen, die verdächtige Aktivitäten feststellen, sollten ihre Verfahren zur Reaktion auf Sicherheitsvorfälle befolgen und ihr nationales CSIRT kontaktieren ^[2].