Apache schließt kritische HTTP/2-Lücke: Codeausführung ohne Login

Die Apache Software Foundation hat am 11. November 2026 eine kritische Sicherheitslücke im HTTP/2-Modul ihres Webservers geschlossen, über die Angreifende ohne Anmeldung Code ausführen können. Betroffen sind laut Apache-Sicherheitsseite die Versionen 2.4.55 bis 2.4.70. Ausnutzbar ist die Lücke laut BleepingComputer nur bei aktiviertem HTTP/2, das standardmäßig ausgeschaltet ist. Behoben ist der Fehler in Version 2.4.71.

Race Condition in mod_http2: zwei Threads, ein Heap

CVE-2026-119618 ist eine Race Condition in mod_http2, dem HTTP/2-Modul von Apache: Zwei Threads greifen gleichzeitig und ohne Absprache auf dieselbe Ressource zu. Die Funktion heißt laut Apache assign_headers(). Das Projekt ordnet den Fehler der Kategorie „Concurrent Execution using Shared Resource with Improper Synchronization“ zu. Gemeint ist fehlende Abstimmung bei gleichzeitigem Zugriff.

Das Modul bringt dem Webserver HTTP/2 bei. Die Protokollversion bündelt viele Anfragen parallel über eine einzige Verbindung. Parallelität ist ihr Zweck. Hier wird sie zur Schwachstelle.

Die fehlende Synchronisation beschädigt den Heap, also den dynamisch vergebenen Arbeitsspeicher. Aus dieser Speicherkorruption lässt sich laut Wiz Remote Code Execution machen. Gemeint sind fremde Befehle aus der Ferne. Sie laufen mit den Rechten des Webservers. Der liest alles, was die Website ausliefert.

Zwei Teams fanden die Lücke unabhängig. Anthropics OSS Scanner meldete sie laut Apache am 26. Oktober 2026. Dort läuft der Fund als ANT-2026-MAPKT6MZ. Anthony Weems und Simon Scannell von Google Cloud Vulnerability Research folgten am 3. November. Zwei Funde kurz nacheinander sprechen nicht für ein gut gehütetes Geheimnis.

Apache stuft die Sicherheitslücke als kritisch ein. Einen offiziellen CVSS-Score, den Standardwert für den Schweregrad, gibt es laut BleepingComputer vom 12. November 2026 noch nicht. Wiz bewertet den Fehler ebenfalls als kritisch. Mitbetroffen ist mod_h2, die eigenständig auf GitHub gepflegte Fassung des Moduls. Betroffen sind dort 2.0.8 bis 2.0.42. Alle Einträge stehen auf der Sicherheitsseite des Apache-Projekts.

Wie viele Apache-Server tatsächlich angreifbar sind

Wiz zählt in 64 Prozent der Cloud-Umgebungen Ressourcen, die für CVE-2026-119618 anfällig sind. In 51 Prozent stehen solche Instanzen laut der Wiz-Analyse vom 11. November öffentlich im Netz. Beide Werte ignorieren die Konfiguration. Wiz sagt das selbst.

Die Konfiguration entscheidet über die Angreifbarkeit. Ohne aktiviertes HTTP/2 greift die Lücke nicht. Das Sicherheitsunternehmen watchTowr bestätigt diese Bedingung. Sein Rat lautet „patch now or drop h2 until you can“. Übersetzt heißt das: sofort patchen oder h2 abschalten, bis das Update läuft.

Der Standardwert „aus“ wirkt wie eine Entwarnung. Er schützt aber nur unveränderte Server. Wie viele Installationen HTTP/2 eingeschaltet haben, verrät er nicht. Wer es eingeschaltet hat, sollte das wissen. Wer es nicht weiß, sollte nachsehen.

Die Reichweite von Apache bleibt groß. Laut W3Techs vom 13. November 2026 läuft Apache auf 20,9 Prozent der Websites mit bekanntem Webserver. Vorn liegen nur Cloudflare Server mit 33,8 Prozent und Nginx mit 30,0 Prozent. Eine Website kann laut W3Techs mehrere Webserver nutzen, die Anteile überlappen sich deshalb. BleepingComputer spricht von rund jeder fünften Website.

In der Cloud wiegt ein übernommener Webserver schwerer. Laut Wiz kann eine kompromittierte Apache-Instanz mit Containern oder virtuellen Maschinen als Einstieg für Lateral Movement dienen, das seitliche Weiterwandern zu benachbarten Systemen. Potenziell erreichbar wären angrenzende Microservices und die Metadaten-Schnittstellen der Cloud. Brisant wird die Lücke also dort, wo der Server Nachbarn hat.

Fünfte HTTP/2-Lücke bei Apache seit Mai

CVE-2026-119618 ist laut Apache-Sicherheitsseite die fünfte Lücke im HTTP/2-Code, die das Projekt seit Mai 2026 geschlossen hat. Vier Releases waren dafür nötig. Das Modul bleibt eine Baustelle.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2_5 flare high 1k 16:9PromptPaper cut collage of a server room seen from a symmetrical frontal view down a narrow aisle, layered cut paper server racks in navy, teal and cream. Five of the server units in the foreground are marked with jagged torn red paper cracks, each one slightly different, suggesting five repeated vulnerabilities in the same module. Above the racks a schematic horizontal timeline made of paper strips with five red dots, without any numbers or text. A small paper feather emblem on one rack. Handmade texture, visible paper edges, soft drop shadows between layers, muted palette with red accents, no people. No watermark, no signature.

Die folgende Tabelle zeigt die HTTP/2-Fixes in der Reihenfolge ihrer Veröffentlichung.

Die Einstufung schwankt, der Ort bleibt. Double Free und Use-after-free sind Speicherfehler, bei denen bereits freigegebener Speicher erneut freigegeben oder benutzt wird. Zweimal stand Code-Ausführung im Raum. Im Mai sprach Apache von „possible RCE“. Jetzt heißt es „can lead to RCE“. Aus möglich wurde kann. Ärger mit Protokoll- und Kompressionscode gibt es auch anderswo, wie die Brotli-Lücke Node2Shell zeigt, die weit über Node.js hinausreicht.

Diesmal ging es schneller. Bei CVE-2026-23918 stand der Fix laut Apache schon am 11. Dezember 2025 im Code. Das Release folgte erst am 4. Mai 2026. Bei der neuen Lücke erschienen Fix und Release am selben Tag.

Wer im Oktober zügig auf 2.4.69 aktualisiert hat, steht trotzdem ungeschützt da. Das Release schloss laut Apache 20 CVEs. CVE-2026-119618 war nicht darunter. Auch 2.4.70 ist betroffen. Geschützt ist erst, wer 2.4.71 einsetzt. Fleiß beim Patchen hilft nur gegen die Lücken von gestern.

Ältere Versionen vor 2.4.55 trifft CVE-2026-119618 nicht. Trost spendet das kaum. Viele der im Oktober behobenen Lücken betreffen laut Apache alle Versionen ab 2.4.0. Wer auf altem Stand verharrt, tauscht eine Lücke gegen viele.

Version 2.4.71 schließt zwei weitere Lücken

Apache HTTP Server 2.4.71 behebt laut Apache neben CVE-2026-119618 zwei weitere Fehler. Das Release umfasst damit drei CVEs. Je eine ist als kritisch, wichtig und niedrig eingestuft. Für das Projekt ist das eine schlanke Liste. Version 2.4.68 brachte im Juni 13 CVEs, 2.4.67 im Mai elf.

CVE-2026-106023 gilt als wichtig. Die Lücke steckt in mod_md, dem Modul für automatisch verwaltete TLS-Zertifikate. Eine NULL-Pointer-Dereferenzierung, also ein Zugriff über einen leeren Zeiger, lässt dort Kindprozesse abstürzen, die Arbeitsprozesse des Servers. Betroffen sind 2.4.30 bis 2.4.70. Gemeldet haben den Fehler unter anderem Forschende des 360 Vulnerability Research Institute und Bartlomiej Dmitruk von striga.ai. Dmitruk taucht schon im Mai auf. Damals war er Mitfinder der HTTP/2-Lücke CVE-2026-23918.

CVE-2026-109163 hat die Einstufung niedrig. Es geht um ein Ein-Byte-Überschreiben auf dem Stack in mod_vhost_alias. Das Modul bildet virtuelle Hosts über Namensmuster ab. Betroffen sind nur 2.4.69 und 2.4.70. Apache versieht den Eintrag mit dem Zusatz „after CVE-2026-63292“. Diese Vorgängerlücke war ein Stack-Überlauf im selben Modul. Auslöser waren laut Projekt Host-Header über 8192 Bytes. Behoben wurde sie in 2.4.69. Auch Reparaturen brauchen manchmal eine Reparatur.

Updates über Hosting-Panels laufen nicht immer glatt, wie das Plesk-Update mit Fehler 421 bei Apache gezeigt hat. Ein Grund zum Aufschieben ist das nicht.

Patchen oder h2 abschalten: so gehen Admin-Teams vor

Das Update auf Apache HTTP Server 2.4.71 ist die wirksamste Maßnahme gegen CVE-2026-119618. Die Download-Seite des Projekts führt 2.4.71 als aktuelle stabile Version. So gehen Sie vor:

1. Prüfen Sie mit apachectl -v, welche Version installiert ist.
2. Prüfen Sie mit apachectl -M, ob das Modul http2_module geladen ist.
3. Suchen Sie in der Konfiguration nach einer Protocols-Zeile mit h2 oder h2c.
4. Spielen Sie Version 2.4.71 ein und prüfen Sie den Download vorher per PGP- oder SHA-Signatur, wie es die Download-Seite verlangt.
5. Setzen Sie laut Wiz vorübergehend Protocols http/1.1, falls das Update warten muss.
6. Aktualisieren Sie eigenständige mod_h2-Builds von GitHub auf eine Version nach 2.0.42.

Tipp: Laden Sie die Konfiguration nach jeder Änderung an Protocols neu und testen Sie, ob Ihre Website per HTTP/1.1 erreichbar bleibt.

Laut Wiz beseitigt das Abschalten von HTTP/2 den Angriffsweg. Bis zum Update verzichtet der Server dann auf HTTP/2. Das ist der kleinere Schaden.

Bei mod_h2 stiften die Versionsnummern Verwirrung. Die Tabelle im Wiz-Blog nennt 2.0.42 als gepatchte Version. Der Fließtext desselben Beitrags verlangt eine Version nach 2.0.42. Apache führt 2.0.42 als betroffen. Maßgeblich ist die Angabe des Projekts.

Ob nach einem Update weitere Schritte nötig sind, hängt vom Einzelfall ab. Bei BeyondTrust Remote Support reichte der Patch allein nicht.

Angriffe auf CVE-2026-119618 sind laut Wiz bislang nicht bekannt. Einen öffentlichen Exploit gibt es ebenfalls nicht. Laut BleepingComputer kann sich das bald ändern. Admin-Teams mit aktiviertem h2 sollten 2.4.71 deshalb einspielen, bevor der erste Proof of Concept erscheint.