Deutsch
Magyar
English
Slovenščina
Die Entwickler des Apache HTTP Server haben am 11. November die Version 2.4.71 veröffentlicht, die eine kritische Sicherheitslücke im HTTP/2-Modul des Webservers (mod_http2) behebt. Über die Lücke mit der Kennung CVE-2026-119618 kann ein Angreifer ohne Anmeldung, mit speziell präpariertem HTTP/2-Datenverkehr auf dem Server Code ausführen.
Unsere Server sind bereits geschützt: Das korrigierte Apache-Paket (2.4.71-1~urgent) wurde heute in den frühen Morgenstunden auf allen unseren eigenen Servern und auf allen von uns verwalteten Kundenservern installiert. Wenn Ihr Hosting bei uns liegt oder wir Ihren Server betreiben, müssen Sie nichts tun.
Worum geht es?
HTTP/2 ist eine neuere Version des HTTP-Protokolls, die mehrere Anfragen parallel über eine einzige Verbindung abwickelt, sodass Seiten schneller laden. Den Unterschied zwischen HTTP/1.1, HTTP/2 und HTTP/3 erklären wir in unserem Artikel über HTTP.
Das HTTP/2-Modul von Apache stellt die Header jeder eingehenden Anfrage zusammen (Funktion assign_headers()). In den Versionen 2.4.55 bis 2.4.70 ist dieser Schritt nicht korrekt synchronisiert: Das Modul kann die Header einer Anfrage ändern, während ein anderer Thread sie gerade verwendet (eine Wettlaufsituation, Race Condition). Laut Red Hat schreibt ein Worker-Thread über einen gemeinsamen, sperrfreien Speicher-Allocator in Speicher, der dem Verbindungs-Thread gehört. Das Ergebnis ist eine Beschädigung des Heap-Speichers, die zur Remotecodeausführung führen kann.
Das Wichtigste in Kürze:
- Eine Anmeldung ist nicht nötig, ebenso wenig eine Mitwirkung des Benutzers: Es genügt, dass der Angreifer den Webserver erreicht.
- Betroffen sind nur Server mit aktiviertem HTTP/2. Ein Apache, der ausschließlich HTTP/1.1 ausliefert, ist nicht verwundbar.
- Der Code läuft mit den Rechten des Webserver-Prozesses.
- Laut Red Hat hat öffentliche Forschung bereits einen zuverlässig funktionierenden Angriff auf einen Server mit Standardkonfiguration und HTTP/2 vorgeführt. Über tatsächliche Angriffe in freier Wildbahn haben die Quellen bisher nicht berichtet.
Wie schwerwiegend ist die Lücke?
Apache selbst stuft sie als kritisch ein. Der von Tenable veröffentlichte CVSS-3.1-Wert beträgt 9,8 (kritisch), Vektor: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Red Hat vergibt denselben Basiswert, stuft seine eigenen Produkte aber nur als wichtig (Important) ein: Das mod_http2-Paket von RHEL 9 und 10 bedient jeden HTTP/2-Stream aus einem eigenen Speicher-Allocator, was die Ausnutzung laut Red Hat deutlich erschwert. Schwerer, aber nicht unmöglich, daher müssen auch diese Systeme aktualisiert werden.
Die Lücke wurde dem Apache-Sicherheitsteam aus zwei Quellen gemeldet: am 26. Oktober vom Scanner von Anthropic, der Open-Source-Software untersucht (OSS Scanner), und am 3. November von zwei Forschern von Google Cloud Vulnerability Research, Anthony Weems und Simon Scannell.
Betroffene Versionen und Korrekturen
| Software / System | Betroffen? | Korrektur |
|---|---|---|
| Apache HTTP Server 2.4.55–2.4.70 | Ja | 2.4.71 (11. November 2026) |
Eigenständiges mod_h2-Modul 2.0.8–2.0.42 |
Ja | der Fix in Apache 2.4.71 |
| RHEL 8 und älter, System-Apache von CloudLinux 7 und 8 | nein | – |
| RHEL 9 und 10 sowie die darauf aufbauenden AlmaLinux, Rocky Linux und CloudLinux 9 und 10 | Ja | das korrigierte mod_http2-Paket der Distribution (AlmaLinux: 11. November) |
| cPanel EasyApache 4 (auf jeder CloudLinux-Version) | Ja | ea-apache24 2.4.71 (seit 11. November im stabilen Kanal) |
| Apache unter Ubuntu 22.04 | ja, wenn HTTP/2 aktiviert ist (standardmäßig aus) | laut CloudLinux am 12. November noch keiner |
Auf den älteren Systemen (RHEL 8, CloudLinux 7 und 8) ist der systemeigene Apache nicht betroffen, weil er entweder kein HTTP/2-Modul hat oder sein Modul älter als der fehlerhafte Code ist. Auf cPanel-Servern läuft dagegen nicht der Apache des Systems, sondern der von EasyApache 4, und der war unabhängig von der Version des Betriebssystems betroffen.
Was haben wir getan?
Das korrigierte Apache-Paket (2.4.71-1~urgent) wurde am 12. November 2026 in den frühen Morgenstunden installiert:
- auf allen unseren eigenen Servern, also den Servern für cPanel-Hosting, WordPress-Hosting und Webhosting sowie den Servern unserer übrigen Dienste,
- auf allen Kundenservern, die wir verwalten, zum Beispiel den Managed VPS.
Was können Sie tun?
Wenn Ihr Hosting bei uns liegt oder wir Ihren Server verwalten
Sie müssen nichts tun. Die Lücke lag im Webserver, nicht in Ihrer Website, daher muss der Betreiber des Servers den Fix installieren, und das haben wir bereits erledigt. Ein Update von WordPress oder einem anderen CMS hat mit dieser Lücke nichts zu tun, ein aktuelles CMS und aktuelle Plugins sind aber unabhängig davon wichtig.
Wenn Sie dennoch verdächtige Anzeichen auf Ihrer Website bemerken (unbekannte .php-Dateien, unbekannte Administratoren, unerwartete Weiterleitungen oder fremde Inhalte), schreiben Sie uns, und löschen Sie nichts, bevor wir uns abgestimmt haben.
Wenn Sie einen eigenen VPS oder Server betreiben
Wenn Sie Apache auf Ihrem KVM-VPS oder dediziertem Server selbst verwalten (bei uns oder anderswo), ist das Update Ihre Aufgabe.
1. Prüfen Sie, ob das HTTP/2-Modul geladen ist:
# AlmaLinux, Rocky Linux, CloudLinux, RHEL
httpd -M 2>/dev/null | grep -w http2_module
# Debian, Ubuntu
apache2ctl -M 2>/dev/null | grep -w http2_module
Gibt es keine Ausgabe, ist das Modul nicht geladen, und der Server ist für diese Lücke nicht anfällig. Gibt es eine, aktualisieren Sie.
2. Aktualisieren Sie und starten Sie Apache neu:
# AlmaLinux, Rocky Linux, CloudLinux 9 und 10 (System-Apache)
dnf upgrade --refresh httpd mod_http2
systemctl restart httpd
rpm -q mod_http2
# cPanel / EasyApache 4
dnf upgrade --refresh 'ea-apache24*'
/scripts/restartsrv_httpd
rpm -q ea-apache24 ea-apache24-mod_http2
Auf einem cPanel-Server muss das Paket ea-apache24-mod_http2 die Version 2.4.71 oder neuer anzeigen. Die allgemeinen Schritte eines Systemupdates, einschließlich der Einrichtung automatischer Sicherheitsupdates, beschreiben wir in unserem Artikel über Updates mit dnf und apt.
3. Wenn es noch kein korrigiertes Paket gibt, deaktivieren Sie HTTP/2 vorübergehend. Die Website läuft dann über HTTP/1.1 weiter, höchstens etwas langsamer.
# AlmaLinux, Rocky Linux, CloudLinux 9 und 10:
# die Zeile "LoadModule http2_module" in dieser Datei auskommentieren:
# /etc/httpd/conf.modules.d/10-h2.conf
apachectl configtest && systemctl restart httpd
# Debian, Ubuntu
a2dismod http2
systemctl restart apache2
Auf einem cPanel-Server empfiehlt CloudLinux, das Paket ea-apache24-mod_http2 zu entfernen (unter Ubuntu mit apt-get purge, weil die nach einem einfachen remove zurückbleibende Konfiguration den Start von Apache verhindert). Da das korrigierte 2.4.71 aber bereits verfügbar ist, ist dort das Update einfacher. Sobald das korrigierte Paket erschienen ist, kann HTTP/2 wieder eingeschaltet werden.
Vorsicht bei E-Mails zu „dringenden Updates“
Nach einer solchen Nachricht können sich Phishing-E-Mails häufen, die sich auf ein Sicherheitsupdate berufen. Wir fragen Sie nie per E-Mail nach Ihrem Passwort, und für die Aktualisierung unserer Server brauchen wir Ihre Mithilfe nicht.
Zeitleiste
| Datum | Ereignis |
|---|---|
| 2026-10-26 | Der OSS Scanner von Anthropic meldet die Lücke dem Apache-Sicherheitsteam. |
| 2026-11-03 | Auch Anthony Weems und Simon Scannell (Google Cloud Vulnerability Research) melden die Lücke. |
| 2026-11-11 | Apache veröffentlicht die korrigierte Version 2.4.71 und die Beschreibung von CVE-2026-119618. |
| 2026-11-11 | AlmaLinux veröffentlicht die korrigierten mod_http2-Pakete; der korrigierte Apache (2.4.71) von CloudLinux EasyApache 4 kommt in den stabilen Kanal. |
| 2026-11-12, frühmorgens | Das korrigierte Apache-Paket (2.4.71-1~urgent) wird auf unseren eigenen und den von uns verwalteten Servern installiert. |
Häufig gestellte Fragen
Betrifft das meine Website? Die Lücke lag im Webserver, nicht in den Websites, daher konnte sie jede Website betreffen, die von einem verwundbaren Apache mit HTTP/2 ausgeliefert wurde. Auf unseren Servern ist der Fix bereits installiert.
Muss ich WordPress oder die Plugins aktualisieren? Für diese Lücke nicht. Der Fix erfolgte in Apache; ein CMS-Update ersetzt ihn nicht, ist dafür aber auch nicht nötig.
War meine Website während des Updates nicht erreichbar? Nein. Apache musste nach dem Fix neu gestartet werden, das verursachte aber keinen spürbaren Ausfall.
Muss ich meine Passwörter ändern? Ohne verdächtige Anzeichen ist das nicht nötig. Wenn Sie trotzdem auf Nummer sicher gehen möchten: Wie Sie Ihr cPanel-Passwort ändern, zeigen wir in einem eigenen Artikel.