Apache HTTP Server mit HTTP/2: kritische Lücke in mod_http2 ermöglicht Remote Code Execution

Was ist passiert

Am 11. November 2026 hat das Apache-HTTP-Server-Projekt CVE-2026-119618 veröffentlicht und Version 2.4.71 freigegeben. Das Projekt stuft die Lücke als kritisch ein. Sie liegt im HTTP/2-Modul mod_http2, in der Funktion assign_headers(). Gemeinsam genutzte Ressourcen werden bei gleichzeitig laufenden Anfragen nicht korrekt synchronisiert. Laut Advisory des Projekts führt dies zu einer Heap-Beschädigung, die zu Remote Code Execution führen kann.

Red Hat bewertet die Lücke im CVSS-System mit 9,8 von 10 Punkten. Demnach benötigt ein Angreifer, der den Server erreichen kann, keine Authentifizierung und könnte die volle Kontrolle über den Serverprozess übernehmen. Red Hat erklärt außerdem, dass öffentliche Forschung einen zuverlässigen Exploit gegen eine Standardkonfiguration mit aktiviertem mod_http2 belegt habe, nennt diese Forschung aber nicht. Das Sicherheitsunternehmen Wiz teilte später mit, dass kein Exploit verfügbar sei und keine Angriffe gemeldet wurden. Die Schwachstelle ist nicht im Katalog der von CISA bekannten ausgenutzten Schwachstellen enthalten, und keine der geprüften Quellen meldet Angriffe.

Version 2.4.71 behebt außerdem zwei weitere Lücken:

• CVE-2026-106023 (als wichtig eingestuft): ein Absturz in mod_md.
• CVE-2026-109163 (als gering eingestuft): ein Stack-Überschreiben um ein Byte in mod_vhost_alias.

Wer ist betroffen

• Apache HTTP Server 2.4.55 bis 2.4.70, aber nur wenn HTTP/2 aktiviert ist. HTTP/2 läuft nur dort, wo die Direktive Protocols h2 (HTTP/2 über TLS) oder h2c (HTTP/2 über unverschlüsseltes TCP) enthält. Diese Direktive kann für den gesamten Server oder für einen einzelnen virtuellen Host gesetzt werden.
• Server, auf denen 2.4.67 für die frühere HTTP/2-Lücke CVE-2026-23918 installiert wurde, sind weiterhin betroffen. Das gilt für alle Versionen von 2.4.67 bis 2.4.70.
• Eigenständige Builds des Moduls (mod_h2 von GitHub), Versionen 2.0.8 bis 2.0.42. Es gibt noch keine korrigierte mod_h2-Version, und das Repository des Projekts wurde archiviert.

Diese Systeme sind nicht betroffen:

• Apache-Versionen vor 2.4.55.
• Server, auf denen weder h2 noch h2c in einer Protocols-Direktive aktiviert ist.
• Red Hat Enterprise Linux 6, 7 und 8, die den verwundbaren Code nicht enthalten.

Status der Distributionspakete, Stand 12. November 2026:

• RHEL 9: behoben in mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981).
• RHEL 10: behoben in mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978).
• RHEL EUS und SAP-Releases: Korrekturen sind in separaten Advisories verfügbar. Red Hat stuft die Lücke auf RHEL 9 und 10 als Important statt Critical ein, weil dort die Builds einen Angriff deutlich erschweren.
• Red Hat JBoss Core Services und Red Hat Hardened Images: als betroffen gelistet, noch ohne Korrektur.
• Debian: unstable (sid) ist mit apache2 2.4.71-1 behoben. Der Debian-Tracker listet bookworm, trixie und forky als verwundbar, ohne bislang ein korrigiertes Paket.
• Amazon Linux 2, Amazon Linux 2023 und Amazon Linux 2027 Preview: eine Korrektur steht aus.
• Ubuntu: es wurde noch kein Status veröffentlicht.

Hosting-Panels und andere Produkte, die eigene Apache-Builds ausliefern, sind betroffen, wenn ihr Build in diesen Versionsbereich fällt und HTTP/2 aktiviert ist. Den Status erfahren Sie im Advisory des jeweiligen Herstellers.

Was Sie jetzt tun sollten

1. Ermitteln Sie Ihre Apache-Version mit apachectl -v oder httpd -v. Prüfen Sie danach, ob HTTP/2 aktiviert ist (siehe nächster Abschnitt).
2. Aktualisieren Sie.
   • Selbst gebaut oder Upstream-Apache: Aktualisieren Sie auf 2.4.71.
   • RHEL 9 und 10: Installieren Sie die Updates, zum Beispiel mit dnf update mod_http2.
   • Andere Distributionen: Installieren Sie das korrigierte Paket apache2 oder httpd, sobald Ihre Distribution eines veröffentlicht. Beachten Sie die unten verlinkten Advisories der Hersteller.
3. Starten Sie Apache vollständig neu, zum Beispiel mit systemctl restart httpd oder systemctl restart apache2. Ein vollständiger Neustart stellt sicher, dass das aktualisierte Modul geladen wird. Prüfen Sie danach, ob Ihre Websites antworten.
4. Wenn Sie noch nicht aktualisieren können: Das Advisory von Apache nennt keinen Workaround. Wiz empfiehlt, h2 und h2c aus jeder Protocols-Direktive zu entfernen und Protocols http/1.1 stehen zu lassen. Prüfen Sie die serverweite Einstellung und jeden virtuellen Host. Testen Sie anschließend die Konfiguration mit apachectl configtest und starten Sie Apache neu. Clients weichen dann auf HTTP/1.1 aus. Dies ist bislang auch der einzige Schutz für Server, die eigenständige mod_h2-Builds verwenden.
5. Prüfen Sie Ihre anderen Server, einschließlich Reverse Proxies und Server, die Sie für Kunden betreiben, wenn dort Apache 2.4.55 oder neuer mit aktiviertem HTTP/2 läuft.

So prüfen Sie, ob Sie betroffen sind

• Version: Führen Sie apachectl -v (oder httpd -v) aus. Die Versionen 2.4.55 bis 2.4.70 sind betroffen. Bei Distributionspaketen vergleichen Sie mit den oben genannten korrigierten Paketversionen, da Distributionen eigene Versionsnummern verwenden.
• Modul geladen: apachectl -M 2>/dev/null | grep http2 zeigt, ob mod_http2 geladen ist.
• HTTP/2 aktiviert: Führen Sie grep -RniE '^\s*Protocols' /etc/httpd /etc/apache2 2>/dev/null aus und suchen Sie nach h2 oder h2c. Nehmen Sie weitere Verzeichnisse mit Konfigurationsdateien hinzu.
• Von außen: curl -sI --http2 https://example.com -o /dev/null -w '%{http_version}\n' gibt 2 aus, wenn die Website über HTTP/2 antwortet.

Wenn keiner Ihrer Server h2 oder h2c in einer Protocols-Direktive hat, ist diese Lücke für sie nicht relevant. Installieren Sie dennoch Version 2.4.71 oder das Update Ihrer Distribution im Rahmen der regulären Wartung, da damit auch die beiden anderen Lücken behoben werden.

Quellen

• https://nvd.nist.gov/vuln/detail/CVE-2026-119618
• https://httpd.apache.org/security/vulnerabilities_24.html