Apache Sicherheitslücke: maxcluster schaltet HTTP/2 ab

Eine kritische Apache Sicherheitslücke im HTTP/2-Modul kann Angreifern ermöglichen, aus der Ferne Schadcode auf Webservern auszuführen – betroffen sind die Apache-Versionen 2.4.55 bis 2.4.70. Apache hat die Lücke CVE-2026-119618 am Mittwoch mit Version 2.4.71 geschlossen. Für die stabilen Debian-Versionen gibt es aber noch kein korrigiertes Paket. Der Shop-Hoster maxcluster schaltet deshalb seit Donnerstag, 14 Uhr, auf betroffenen Kunden-Clustern HTTP/2 ab, wie er in einer Kundenmail mitteilt, die wortfilter.de vorliegt. Für Onlinehändler heißt das: Der Shop bleibt erreichbar, kann aber langsamer laden – und wer seinen Server selbst betreibt, sollte handeln.

Zwei Threads, ein Speicher: So entsteht die Apache Sicherheitslücke

Die Lücke steckt in der Funktion assign_headers() des Moduls mod_http2. Das Modul bringt Apache das Protokoll HTTP/2 bei (die schnellere Nachfolgeversion von HTTP/1.1). Laut der Sicherheitsseite des Apache-Projekts greifen dabei mehrere Prozesse ohne saubere Abstimmung gleichzeitig auf denselben Speicher zu (Race Condition). Das kann zur Ausführung von fremdem Code führen (Remote Code Execution, RCE). Apache stuft die Lücke mit der höchsten Stufe „critical“ ein.

Betroffen sind Apache HTTP Server 2.4.55 bis 2.4.70 sowie das separat vertriebene mod_h2 in den Versionen 2.0.8 bis 2.0.42. Version 2.4.55 erschien im Januar 2023. Die korrigierte Version 2.4.71 ist seit dem 11. November verfügbar und schließt zwei weitere Lücken in den Modulen mod_md und mod_vhost_alias.

Gemeldet haben den Fehler zwei Stellen unabhängig voneinander: der automatische Open-Source-Scanner von Anthropic am 26. Oktober, Forscher von Google Cloud am 3. November. Berichte über aktive Angriffe gibt es laut dem Sicherheitsdienstleister Rescana bislang nicht. Auch der Katalog ausgenutzter Schwachstellen der US-Behörde CISA führt die Lücke nicht. Eine Bewertung in der US-Schwachstellendatenbank NVD steht noch aus.

14 Uhr: maxcluster zieht bei HTTP/2 den Stecker

Der auf Onlineshops spezialisierte Hoster maxcluster aus Paderborn hat seine Kunden am Donnerstagmittag per Mail informiert. Betroffen sind in seiner Infrastruktur Cluster mit Ubuntu 24.04 oder 26.04, auf denen Apache ohne vorgeschalteten Reverse-Proxy (ein Server, der Anfragen annimmt und weiterreicht) oder Varnish (ein Cache-Server) läuft. Auf diesen Clustern deaktiviert maxcluster seit 14 Uhr HTTP/2.

Shops bleiben über HTTP/1.1 erreichbar. Beim Neuladen des Webservers kann es laut maxcluster zu einer Unterbrechung von wenigen Sekunden kommen. Seiten mit vielen Bildern, Skripten und anderen Dateien können länger laden. HTTP/2 schaltet der Hoster wieder ein, sobald die Sicherheitsupdates für seine Systemumgebung vorliegen und eingespielt sind.

maxcluster-Kunden müssen nach Angaben des Hosters nichts tun. Zusätzlich empfiehlt maxcluster seine kostenlose Web Application Firewall (WAF, ein Filter, der Angriffe abfängt, bevor sie den Shop erreichen). Mit aktivierter WAF ist ein Cluster laut maxcluster ebenfalls vor der Lücke geschützt.

Der Grund für die Übergangslösung: Debian markiert laut Rescana seine stabilen Versionen noch als verwundbar, behoben ist die Lücke dort bisher nur im Entwicklungszweig „unstable“. Wer Apache über die Paketquellen seiner Distribution bezieht, wartet also noch auf das Update.

Eigener Server, anderer Hoster? Fünf Schritte für heute

Wer seinen Shop bei einem Managed-Hoster oder als Mietshop betreibt, muss den Server nicht selbst patchen. Wer einen eigenen Server oder eine eigene VM betreibt, ist selbst zuständig. Diese Schritte schließen das Risiko bis zum Update:

1. Hoster fragen: Postfach prüfen. Fehlt eine Info, beim Support nachfragen, ob dein Server betroffen ist und ob HTTP/2 abgeschaltet wurde.
2. Version prüfen: Mit apache2 -v (Debian/Ubuntu) oder httpd -v die Apache-Version anzeigen. Betroffen sind 2.4.55 bis 2.4.70. Distributionen spielen Korrekturen oft in ältere Versionsnummern ein – maßgeblich ist dann der Sicherheitshinweis deiner Distribution.
3. HTTP/2-Status prüfen: apachectl -M | grep http2 zeigt, ob das Modul geladen ist. Keine Ausgabe heißt: HTTP/2 ist nicht aktiv.
4. Patchen oder abschalten: Auf Apache 2.4.71 aktualisieren oder das Sicherheitsupdate der Distribution einspielen, sobald es erscheint. Bis dahin HTTP/2 abschalten: sudo a2dismod http2 && sudo systemctl restart apache2. Nach dem Update mit sudo a2enmod http2 und Neustart wieder aktivieren.
5. Schutz und Ladezeit im Blick: Eine WAF aktivieren, falls dein Hoster eine anbietet. Nach der Umstellung auf HTTP/1.1 die Ladezeiten von Startseite, Kategorie- und Produktseiten messen.

Ob ein vorgeschalteter Proxy oder ein CDN die Lücke generell abschirmt, beschreibt Apache nicht. maxcluster nimmt Cluster mit Reverse-Proxy oder Varnish von der Maßnahme aus – das gilt für dessen Infrastruktur, nicht automatisch für jedes andere Setup.

16 Tage vom ersten Hinweis bis zum Patch

Zwischen der ersten Meldung am 26. Oktober und der Veröffentlichung von Version 2.4.71 am 11. November lagen 16 Tage. Der Fehler steckte da schon fast vier Jahre im Code. Mit dem Release sind Funktionsname, betroffene Versionen und der korrigierende Code öffentlich dokumentiert.

Damit kennen auch Angreifer die Stelle, an der sie ansetzen müssen. Wer HTTP/2 auf einem ungepatchten Apache weiterlaufen lässt, lässt die Tür offen, deren Bauplan seit Mittwoch im Netz steht.