Apache HTTP Server Sicherheitslücke: CVE-2026-119618 beheben

Apache HTTP Server Sicherheitslücke: Die Apache Software Foundation hat am 11. November 2026 eine kritische Schwachstelle in der HTTP/2-Verarbeitung geschlossen. Unter der Kennung CVE-2026-119618 kann sie bei entsprechend konfigurierten Webservern die Ausführung fremden Codes aus der Ferne ermöglichen – ohne dass sich Angreifer zuvor anmelden müssen. Betroffen sind Apache HTTP Server 2.4.55 bis 2.4.70 mit aktiviertem HTTP/2. Die korrigierte Version ist 2.4.71.

Apache HTTP Server Sicherheitslücke: Was ist passiert?

Die Schwachstelle liegt im Modul mod_http2, genauer in der Funktion assign_headers(). Nach Angaben des Apache-Projekts handelt es sich um einen Synchronisierungsfehler beim gleichzeitigen Zugriff auf gemeinsam genutzte Ressourcen. Durch eine sogenannte Race Condition kann Speicher beschädigt werden (Heap Corruption). Im ungünstigsten Fall erlaubt dies Remote Code Execution (RCE), also die Ausführung von Befehlen mit den Rechten des Webserverprozesses.

Der Hersteller nennt die Sicherheitslücke ausdrücklich kritisch. Sie wurde unabhängig durch Anthropic OSS Scanner sowie Forschende der Google Cloud Vulnerability Research entdeckt und gemeldet. Das Sicherheitsupdate 2.4.71 erschien am 11. November. Originalmeldung des Apache HTTP Server Project (englisch).

Welche Installationen sind tatsächlich betroffen?

Die verwundbaren Apache-HTTP-Server-Versionen reichen von 2.4.55 bis einschließlich 2.4.70. Auch separat bezogene Versionen von mod_h2 zwischen 2.0.8 und 2.0.42 werden in der Sicherheitsmeldung genannt. Entscheidend ist die Konfiguration: Nach dem Sicherheitshinweis von Red Hat (englisch) sind nur Server angreifbar, die HTTP/2 tatsächlich aktiviert haben. Ein Server, der ausschließlich HTTP/1.1 verarbeitet, ist über diesen spezifischen Fehler nicht verwundbar.

Die reine Versionsnummer genügt nicht immer zur Risikobeurteilung: Linux-Distributionen können Sicherheitskorrekturen in ältere Paketversionen zurückportieren. Betreiber sollten deshalb neben der installierten Version auch die Sicherheitsmitteilungen ihres Distributors und die aktivierten Protokolle prüfen. Umgekehrt ist ein vorgeschalteter Proxy kein pauschaler Entwarnungsgrund; maßgeblich bleibt, ob der verwundbare Server selbst entsprechende HTTP/2-Anfragen verarbeitet.

Wie groß ist die Gefahr – und gibt es bereits Angriffe?

Der technische Schaden kann erheblich sein: Wer Befehle im Kontext des Webserverprozesses ausführen kann, könnte etwa Webseiten verändern, Schadsoftware nachladen oder auf Daten zugreifen, die diesem Prozess zugänglich sind. Eine vollständige Übernahme des gesamten Betriebssystems ist dagegen nicht automatisch nachgewiesen; sie hängt unter anderem von den Prozessrechten und weiteren Sicherheitsbarrieren ab.

Die englischsprachige Berichterstattung von BleepingComputer vom 12. November meldete zunächst keine bestätigten aktiven Angriffe. NHS England (englische behördliche Warnung vom 12. November) berichtet jedoch bereits von einem veröffentlichten Proof of Concept und bewertet eine Ausnutzung als wahrscheinlich. Ein öffentlich verfügbarer Machbarkeitsnachweis ist nicht dasselbe wie eine bestätigte Angriffskampagne. Die Lage kann sich kurzfristig ändern.

Was Betreiber jetzt konkret tun sollten

Bestandsaufnahme: Ermitteln, welche Apache-Instanzen und vorgeschalteten Dienste HTTP/2 verwenden und welche Softwarestände tatsächlich installiert sind.
Updates priorisieren: Auf Apache HTTP Server 2.4.71 oder eine vom jeweiligen Distributor als korrigiert bestätigte Paketversion aktualisieren. Auch verwundbare Container-Images und automatisierte Deployments berücksichtigen.
Vorübergehend absichern: Falls ein Update nicht sofort möglich ist, HTTP/2 einschließlich h2 und h2c nach fachlicher Prüfung vorübergehend deaktivieren und HTTP/1.1 verwenden. Anschließend die wirksame Konfiguration und die Erreichbarkeit testen.
Spuren prüfen: Webserver- und Systemprotokolle auf ungewöhnliche Anfragen, Prozessabstürze und verdächtige Folgeaktivitäten untersuchen. Ein fehlender Alarm beweist nicht, dass kein Angriff stattgefunden hat.
Wiederholungen verhindern: Exponierte Systeme, Patchfristen, Notfallverfahren und Konfigurationsmanagement regelmäßig überprüfen.

Die Aktualisierung behebt zusätzlich zwei weitere Fehler: CVE-2026-106023 in mod_md sowie CVE-2026-109163 in mod_vhost_alias. Diese sind von der kritischen HTTP/2-Lücke zu unterscheiden.

Datenschutzrechtliche Bedeutung: Nicht jede Schwachstelle ist eine Datenschutzverletzung

Werden über einen verwundbaren Webserver personenbezogene Daten verarbeitet, kann ein erfolgreicher Angriff Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigen. Verantwortliche müssen nach Art. 5 Abs. 1 Buchst. f und Art. 32 DSGVO ein angemessenes Sicherheitsniveau gewährleisten. Ob ein verspätetes Update einen Verstoß begründet, hängt von Risiko, Schutzmaßnahmen und konkreten Umständen ab.

Die bloße Existenz einer Sicherheitslücke löst noch keine Meldung nach Art. 33 DSGVO aus. Erst wenn tatsächlich eine Verletzung des Schutzes personenbezogener Daten vorliegt, sind die Meldepflichten und ihre Ausnahmen zu prüfen; bei voraussichtlich hohem Risiko für Betroffene kommt Art. 34 DSGVO hinzu. Für die Einordnung helfen dokumentierte Prüfungen von Systemen, Protokollen und möglichen Datenzugriffen.

Warum das auch Privatpersonen und Vereine betrifft

Apache HTTP Server betreibt Webseiten unterschiedlichster Art – vom persönlichen Projekt über Vereinsseiten und Online-Shops bis zu großen Plattformen. Nicht jeder Website-Betreiber administriert den Server selbst: Bei verwaltetem Hosting ist der Hostinganbieter erster Ansprechpartner für die Aktualisierung. Wer einen eigenen Server, VPS oder Container betreibt, muss die Zuständigkeit dagegen selbst klären. Nutzerinnen und Nutzer können die installierte Serverversion von außen meist nicht zuverlässig erkennen.

NoDSB-Kommentar: Sicherheitsupdates sind Teil digitaler Verantwortung

Die Apache-Schwachstelle zeigt, wie aus einem technisch unscheinbaren Synchronisierungsfehler ein erhebliches Risiko für zahlreiche Websites werden kann. Der entscheidende Punkt ist nicht die möglichst dramatische Schlagzeile, sondern die präzise Frage: Ist HTTP/2 aktiviert, ist die Installation tatsächlich verwundbar und ist eine wirksame Korrektur eingespielt? Gute Sicherheitskommunikation trennt belegte technische Auswirkungen, theoretische Angriffsmöglichkeiten und bestätigte Vorfälle. Nur so können Menschen und Organisationen angemessen handeln.

Originalquellen und weiterführende Informationen

Weitere fachliche Hintergründe: NoDSB-Fachbibliothek und NoDSB: SonicWall MFA-Bypass – Sicherheitsrisiken bei exponierten Zugängen.

Apache HTTP Server Sicherheitslücke: Kritische RCE in HTTP/2 geschlossen