CVE-2026-119618: Apache schließt kritische HTTP/2-Lücke

Apache hat am 11. November 2026 den HTTP Server 2.4.71 veröffentlicht. Das Update schließt CVE-2026-119618, eine als kritisch eingestufte Schwachstelle im HTTP/2-Modul mod_http2, die Codeausführung aus der Ferne ermöglichen kann. Apache-Sicherheitsmeldung

Für Betreiber beginnt die Prüfung mit zwei Fragen: Ist der eingesetzte Paketstand betroffen, und nimmt dieser Apache-Dienst HTTP/2-Verbindungen an? Ein installiertes Modul allein beantwortet die zweite Frage noch nicht.

Welche Apache-Versionen betroffen sind

Apache beschreibt einen Synchronisationsfehler bei gemeinsam genutztem Speicher in assign_headers(). Die betroffenen Bereiche und der Fix sind im Advisory dokumentiert. Bei separat eingebundenem mod_h2 gehört deshalb dessen Herkunft und Version in die Prüfung.

HTTP/2 und die Distribution entscheiden mit

Nach Red Hats Bewertung benötigen Angreifer keine Anmeldung. Betroffen sind Server mit aktiviertem h2 oder h2c; reiner HTTP/1.1-Betrieb ist von dieser CVE nicht betroffen. Red Hat verweist bereits auf öffentlich demonstrierte Ausnutzbarkeit.

Die Einstufung unterscheidet sich je Produkt: RHEL 9 und 10 werden wegen einer anderen Speicherverwaltung als „Important“ bewertet; RHEL 8 und ältere Versionen sind laut Red Hat nicht betroffen. Außerdem können Distributoren Korrekturen in ältere Paketversionen zurückportieren. Eine niedrigere sichtbare Apache-Versionsnummer beweist deshalb allein keine offene Lücke. Maßgeblich ist die Sicherheitsfreigabe für das konkrete Paket. Red-Hat-Eintrag

Welche Informationen für die Bestandsprüfung helfen

Unsere Empfehlung für den Betrieb: Prüft die tatsächlich laufende Instanz, einschließlich Container und kundenspezifischer Installationen. Bei mehreren Webservern kann ein gemeinsames Basisimage helfen, den Umfang einzugrenzen. Es belegt aber noch nicht, dass alle laufenden Instanzen bereits ersetzt wurden.

Apache stellt dafür lesende Diagnoseoptionen bereit:

httpd -v
httpd -M
httpd -S

Sie zeigen Version, geladene Module und VirtualHost-Konfiguration. Je nach Distribution heißen Programm oder Verwaltungswerkzeug anders und benötigen die passende Dienstumgebung. Die Apache-Dokumentation erklärt die Optionen. Führt die Prüfung innerhalb der betreffenden Installation aus, damit nicht versehentlich ein anderes Binary auf dem Host ausgewertet wird.

Ergänzt den Befund um Paketquelle, vollständigen Paketstand, zuständige Person und den betroffenen Dienst. Damit lässt sich ein offenes Update einem konkreten System zuordnen. Ein gepflegtes Asset-Inventar hilft insbesondere dann, wenn mehrere Teams oder Dienstleister Webserver betreiben.

Update einspielen oder HTTP/2 vorübergehend begrenzen

Für selbst verwaltete Upstream-Installationen steht das korrigierte Release bereit. Bei Distributionspaketen oder eingebetteten Komponenten folgt ihr dem jeweiligen Herstellerupdate. Prüft danach, ob der laufende Dienst den neuen Stand verwendet und die Anwendung weiterhin funktioniert.

Wenn ein Update noch nicht möglich ist, kommt als Übergang der Betrieb ausschließlich mit HTTP/1.1 infrage. Die Apache-Direktive Protocols steuert die erlaubten Protokolle:

Protocols http/1.1

Die VirtualHosts müssen mitgeprüft werden. Eine dort gesetzte eigene Protocols-Direktive ersetzt die Einstellung des Basisservers. Eine globale Änderung genügt deshalb nicht, wenn ein VirtualHost weiterhin h2 oder h2c aktiviert. TLS bleibt eine separate Einstellung; HTTP/1.1 ist auch über HTTPS möglich. Apache-Konfigurationsreferenz

Stimmt die Änderung mit dem Betrieb ab, prüft die Konfiguration und übernehmt sie nach dem Verfahren eurer Distribution. Anschließend sollte ein Verbindungstest bestätigen, welches Protokoll der betreffende Endpunkt tatsächlich aushandelt. Haltet die Übergangslösung mit einem Verantwortlichen und einem Termin für das reguläre Update fest.

Was ein abgeschlossenes Update noch nicht beantwortet

Ein Updateauftrag und die Untersuchung eines möglichen Einbruchs sind getrennte Aufgaben. Bei auffälligen Prozessstarts, unerwarteten Dateien oder verdächtigen Verbindungen gehört der betroffene Server zusätzlich in euren Incident-Prozess. Solche Befunde müssen untersucht werden; sie belegen für sich genommen weder diese CVE noch einen erfolgreichen Angriff.

Sichert verfügbare Spuren, bevor sie durch Neuaufsetzen oder Logrotation verloren gehen. Haltet fest, welche Systeme und Zugänge geprüft wurden, welche Erkenntnisse gesichert sind und was noch offen ist. Dafür bietet der Incident Report eine strukturierte Arbeitsgrundlage.

Für die Update-Nachverfolgung sollte pro System erkennbar sein: vorheriger Paketstand, umgesetzte Änderung, Funktionstest und verbleibende Ausnahme. So wird aus „Update beauftragt“ ein überprüfbares Ergebnis.

Quellenstand: 13. November 2026. Die Grafik erklärt den technischen Zusammenhang schematisch; sie zeigt keinen beobachteten Angriff auf Kopexa.