Apache-Sicherheitslücke prüfen: Ist mein Server gepatcht, obwohl die Versionsnummer gleich bleibt?
Die kritische Apache-Lücke CVE-2026-119618 steckt im HTTP/2-Modul mod_http2 und ist laut Apache-Projekt in Version 2.4.71 behoben. Ob Ihr Server geschützt ist, verrät die Versionsnummer allein nicht, denn Distributionen liefern Korrekturen teils unter dem alten Versionsstand aus. Entscheidend sind drei Fragen: Ist HTTP/2 bei Ihnen aktiv, enthält Ihr installiertes Paket die Korrektur, und wurde der Apache-Dienst danach neu gestartet? Wer ein Hosting-Paket hat, stellt diese Fragen an den Hoster.
Stand 12.11.2026. Grundlage: Apache-Sicherheitsseite für 2.4, heise-Meldung vom 12.11.2026, Debian Security Tracker und DSA-6620-1, Debian Security FAQ, Handbuchseiten zu apache2ctl, systemctl, needrestart und curl. Patch-Stände ändern sich laufend, prüfen Sie die Tracker erneut.
- Kurz geklärt: Was ist bekannt und wer ist betroffen?
- Warum die Versionsnummer nichts sagt: Distribution gegen Upstream
- Patch-Stand prüfen: Befehlsfolge für Debian und Ubuntu
- Nach dem Update: Dienst neu starten und kontrollieren
- Hosting-Paket: Was Sie prüfen können und was Sie den Hoster fragen
- Entscheidungshilfe: Ihr Befund und was daraus folgt
- Bis zum Patch: Checkliste für die Übergangszeit
- Wann es komplizierter wird, und wie Sie vorbeugen
Kurz geklärt: Was ist bekannt und wer ist betroffen?
Das Apache-Projekt führt CVE-2026-119618 als kritisch. Die Schwachstelle liegt in mod_http2, genauer in der Funktion assign_headers(). Ursache ist eine Race Condition, die den Speicher beschädigen und Codeausführung aus der Ferne ermöglichen kann. Betroffen sind die Versionen 2.4.55 bis 2.4.70, behoben ist die Lücke in 2.4.71 (veröffentlicht am 11.11.2026). Wer das Modul mod_h2 separat von GitHub eingebunden hat, muss zusätzlich den Bereich 2.0.8 bis 2.0.42 beachten.
Laut heise trifft es Server, auf denen HTTP/2 aktiviert ist; das Modul ist nicht standardmäßig eingeschaltet. Nach Einschätzung von Sicherheitsexperten wie Kevin Beaumont ist die Lücke schwer auszunutzen, unter anderem wegen der Speicherzufallsverteilung (ASLR). Als Entwarnung taugt das nicht: Ob und wann ein Exploit auftaucht, kann niemand vorhersagen.
Dasselbe Update schließt zwei weitere Fehler: CVE-2026-106023 (wichtig, mod_md, Absturz eines Child-Prozesses) und CVE-2026-109163 (niedrig, mod_vhost_alias). Diese drei CVE-Nummern brauchen Sie später für die Suche im Changelog.
Warum die Versionsnummer nichts sagt: Distribution gegen Upstream
Der Befehl apache2 -v zeigt die Version des Programms, nicht den Sicherheitsstand des Pakets. Laut Debian Security FAQ bleibt im Stable-Zweig die Upstream-Version bewusst gleich; Sicherheitskorrekturen werden in die ausgelieferte Version zurückportiert (Backport), damit sich das Verhalten nicht ändert. Ein Server mit „2.4.68“ kann also gepatcht sein. Umgekehrt gilt: Wer nur die Zahl mit „2.4.71“ vergleicht, übersieht Pakete, deren Korrektur unter einer anderen Nummer erscheint. Bei Debian trixie liefert DSA-6620-1 die Korrektur dagegen als Paket 2.4.71-1~deb13u1 aus; beide Wege kommen also vor.
| Was Sie sehen | Was es bedeutet | Aussagekraft für den Patch-Stand |
|---|---|---|
Ausgabe von apache2 -v | Upstream-Version der installierten Programmdatei (nicht zwingend des laufenden Prozesses) | Gering, weil Backports die Zahl nicht ändern |
Paketversion, z. B. 2.4.68-1~deb13u1 gegen 2.4.71-1~deb13u1 | Stand der Distribution samt Revisions-Suffix | Hoch, wenn Sie sie mit der Version aus dem Sicherheitshinweis vergleichen |
| CVE-Nummer im Paket-Changelog | Die Distribution bestätigt die Korrektur im Paket | Sehr hoch für das installierte Paket |
| Status im Tracker der Distribution | Einschätzung des Security-Teams je Release | Hoch, ändert sich aber und kann zeitweise uneinheitlich sein |
| Zeitpunkt des letzten Dienst-Neustarts | Seit wann der laufende Prozess die neue Programmdatei nutzt | Notwendig zusätzlich zum Paketstand |
Selbst gebaute oder aus anderen Quellen installierte Apache-Versionen (Docker-Images, Panel-Pakete, eigener Build) folgen diesen Regeln nicht. Dort zählt die Upstream-Version aus der Apache-Sicherheitsseite.
Patch-Stand prüfen: Befehlsfolge für Debian und Ubuntu
Die Befehle setzen einen Server mit Debian oder Ubuntu und Root-Rechten voraus (VPS, Root-Server). Auf anderen Distributionen heißt das Programm oft httpd, das Vorgehen bleibt gleich.
Schritt 1: Läuft Apache, und ist HTTP/2 an?
systemctl is-active apache2
apache2 -v
apache2ctl -M | grep -i http2systemctl is-active meldet, ob der Dienst läuft (Rückgabewert 0 bei aktiv). Die Option -M listet laut Apache-Handbuch alle geladenen Module. Taucht http2_module nicht auf, ist mod_http2 nicht geladen. Laut heise sind dann Server ohne aktiviertes HTTP/2 nicht betroffen. Läuft stattdessen nginx oder ein anderer Server, betrifft diese Lücke Sie nicht, andere Programme brauchen eine eigene Prüfung.
Von außen sehen Sie, ob HTTP/2 angeboten wird:
curl -I --http2 https://ihre-domain.deBeginnt die Antwort mit HTTP/2, wird das Protokoll ausgehandelt. Das sagt nichts über den Patch, wohl aber über Ihre Angriffsfläche.
Schritt 2: Paketstand statt Upstream-Version
sudo apt update
apt list --upgradable 2>/dev/null | grep -i apache
sudo apt-get install apache2
apt-get changelog apache2 | grep -n "CVE-2026-119618"Steht apache2 in der Liste der aktualisierbaren Pakete, ist das Update noch nicht eingespielt. apt-get install apache2 zieht es nach (auch die Debian-FAQ nennt apt-get update und apt-get upgrade beziehungsweise Installation des Pakets). Führen Sie die Changelog-Suche nach dem Update aus, dann stimmen installierter und angezeigter Stand überein. Findet grep die CVE-Nummer, hat die Distribution die Korrektur ins Paket aufgenommen. Bleibt die Ausgabe leer, kann das zwei Gründe haben: Das Paket ist noch nicht gepatcht, oder die Distribution nennt die Nummer anders. Dann gleichen Sie die Paketversion mit dem Sicherheitshinweis ab.
Die Quellen dafür:
- Debian: Security Tracker zur CVE-Nummer und DSA-6620-1. Der Hinweis nennt für trixie die Version 2.4.71-1~deb13u1. Der Tracker zeigte beim Abruf am 12.11.2026 für bookworm und forky noch „vulnerable“, für trixie und sid „fixed“. Der DSA-Text nennt keine Fixversion für bookworm; prüfen Sie das dort erneut.
- Ubuntu: Die CVE-Suche auf ubuntu.com/security zeigte beim Abruf am 12.11.2026 noch keinen Eintrag zu CVE-2026-119618. Schauen Sie dort später wieder nach und achten Sie auf einen Hinweis (USN) zu apache2.
Schritt 3: Läuft noch der alte Prozess?
sudo needrestart -r lMit -r l listet needrestart laut Handbuchseite die Dienste auf, die nach einem Paket-Update neu gestartet werden sollten, und startet nichts selbst. Steht apache2.service in der Liste, nutzt der laufende Prozess noch den alten Stand. Starten Sie dann neu, wie im nächsten Abschnitt beschrieben.
Nach dem Update: Dienst neu starten und kontrollieren
Ein installiertes Paket schützt erst, wenn der laufende Prozess die neue Programmdatei nutzt. Prüfen Sie die Konfiguration und starten Sie den Dienst anschließend neu:
sudo apache2ctl configtest
sudo systemctl restart apache2
systemctl status apache2configtest prüft nur die Syntax und verändert den Dienst nicht. systemctl restart stoppt und startet die Unit. Ob ein sanfter Neustart per apache2ctl graceful die neue Programmdatei übernimmt, sagt die Apache-Dokumentation nicht ausdrücklich. Für den Patch-Fall ist der vollständige Neustart die sichere Wahl; planen Sie dafür ein kurzes Zeitfenster ein, laufende Verbindungen werden unterbrochen.
Danach führen Sie sudo needrestart -r l erneut aus. Taucht Apache nicht mehr auf, ist der Dienst auf dem neuen Stand. Meldet der Browser nach dem Neustart „Verbindung abgelehnt“, hilft die Anleitung zu ERR_CONNECTION_REFUSED; meist hat dann eine fehlerhafte Konfiguration den Start verhindert.
Hosting-Paket: Was Sie prüfen können und was Sie den Hoster fragen
Bei Webhosting ohne Server-Zugang spielt der Anbieter den Patch ein, Sie haben keinen Einfluss auf Apache. Prüfen können Sie von außen, ob Ihre Webseite HTTP/2 anbietet (curl -I --http2, siehe oben). Den Paketstand sehen Sie nicht. Eine Versionsangabe im Antwort-Header, sofern der Hoster sie überhaupt ausgibt, würde ohnehin nur die Upstream-Version zeigen.
Suchen Sie zuerst Hinweise des Anbieters: Statusseite, Newsletter, Kundenbereich oder Wissensdatenbank. Fehlt dort die Aussage, fragen Sie den Support konkret:
- Ist CVE-2026-119618 (Apache,
mod_http2) auf dem Server meiner Webseite behoben? - Seit wann läuft der gepatchte Stand, und wurde der Apache-Dienst danach neu gestartet?
- Ist HTTP/2 auf meinem Tarif aktiviert, und kann es bis zum Patch abgeschaltet werden?
- Welches Paket und welche Paketversion ist installiert (nicht nur die Upstream-Version)?
Eine seriöse Antwort nennt Datum und Maßnahme. Eine pauschale Aussage wie „Wir sind immer aktuell“ beantwortet die Frage nicht. Bei einem verwalteten Server gilt dasselbe, bei einem unverwalteten VPS sind Sie selbst verantwortlich, dort gilt der Abschnitt zur Befehlsfolge.
Entscheidungshilfe: Ihr Befund und was daraus folgt
| Befund | Bedeutung | Nächster Schritt |
|---|---|---|
| Apache läuft nicht, sondern ein anderer Webserver | Diese Lücke betrifft Sie nicht | Sicherheitshinweise Ihres Servers verfolgen |
http2_module nicht geladen | Nach heise sind Server ohne aktiviertes HTTP/2 nicht betroffen | Trotzdem Update einspielen, es schließt weitere Fehler |
| HTTP/2 aktiv, apache2 steht unter „upgradable“ | Patch nicht eingespielt | Update installieren, Dienst neu starten |
Paket aktuell, CVE im Changelog gefunden, needrestart meldet Apache | Paket gepatcht, Prozess läuft noch alt | Dienst neu starten |
| Paket aktuell, CVE nicht im Changelog | Unklar | Paketversion mit Debian-DSA oder Ubuntu-Hinweis vergleichen |
| Für Ihr Release liefert der Tracker noch keinen Fix | Distribution hat noch nicht geliefert | HTTP/2 mit Protocols http/1.1 abschalten und Tracker beobachten |
| Hosting-Paket, keine Auskunft des Anbieters | Patch-Stand unbekannt | Support konkret anfragen, siehe Fragenliste |
Bis zum Patch: Checkliste für die Übergangszeit
Ist für Ihr Release noch kein Paket verfügbar, nennt heise als Ausweg, HTTP/2 abzuschalten. Dafür steht in der Konfiguration Protocols http/1.1; damit werden h2 und h2c nicht mehr angeboten. Die Direktive ist laut Apache-Handbuch auf Server- und VirtualHost-Ebene möglich, prüfen Sie daher alle Stellen, an denen Protocols gesetzt ist.
- Backup oder Snapshot des Servers anlegen.
- Prüfen, wo
Protocolsgesetzt ist, und dort aufhttp/1.1beschränken. sudo apache2ctl configtestausführen, bei „Syntax OK“ den Dienst mitsudo systemctl restart apache2neu starten.- Mit
curl -I --http2 https://ihre-domain.dekontrollieren, dass die Antwort nicht mehr mitHTTP/2beginnt. - Täglich Tracker der Distribution und
apt list --upgradablekontrollieren, bis das Paket erscheint. - Paket installieren, Dienst neu starten,
needrestarterneut ausführen. - Danach entscheiden, ob HTTP/2 wieder eingeschaltet werden soll (
Protocols h2 http/1.1im VirtualHost mit TLS).
Wer mod_h2 separat von GitHub installiert hat, bekommt den Fix nicht über apt. Betroffen sind laut Apache die Releases 2.0.8 bis 2.0.42.
Wann es komplizierter wird, und wie Sie vorbeugen
Aufwendiger wird es bei mehreren Servern, Containern mit eigenem Apache-Image, Panels wie Plesk oder cPanel mit eigenen Paketquellen und bei Servern, die lange nicht aktualisiert wurden. Dort lohnt zuerst eine Bestandsaufnahme: Welche Server laufen, welcher Dienst nutzt welches Paket, wer verantwortet das Update? Ein Container-Image ändern Sie nicht per apt auf dem Host, es muss neu gebaut werden.
Vorbeugen lässt sich mit einem festen Ablauf: Sicherheitsmeldungen der eingesetzten Distribution abonnieren, Updates in einem festen Rhythmus einspielen und nach Updates needrestart ausführen. Für den Patch-Stand zählt der Paketstand zusammen mit dem Neustart, nicht die Versionsnummer.
Wer keine Zeit hat, Paketstände, Neustarts und Tracker regelmäßig zu prüfen, kann das als laufende Aufgabe abgeben. Wie wir Webseiten und die zugehörigen Server-Updates pflegen, steht unter <a href="/website-wartung">Webseiten-Wartung und Pflege für Unternehmen</a>.
Mehr dazu: Webseiten-Wartung und Pflege für Unternehmen
Quellen
- Apache HTTP Server 2.4: Sicherheitslücken (Apache Software Foundation), httpd.apache.org
- heise online: Kritische Sicherheitslücke in Apache2 ermöglicht Codeeinschleusung, www.heise.de
- Debian Security Tracker: apache2, security-tracker.debian.org
- Debian Security Advisory DSA-6620-1 (apache2), lists.debian.org
- Debian Security FAQ, www.debian.org
- Ubuntu Security: CVE-Suche, ubuntu.com
- Apache-Dokumentation: mod_http2, httpd.apache.org
- Apache-Dokumentation: httpd (Optionen -v, -M, -t), httpd.apache.org
- Apache-Dokumentation: apachectl, httpd.apache.org
- Debian-Handbuchseite needrestart, manpages.debian.org
- Debian-Handbuchseite systemctl, manpages.debian.org
- curl-Handbuch, curl.se
Alle Quellen gelesen am 12.11.2026.
Erstellt von der Redaktion Die Netzhandwerker mit KI-Unterstützung. Die Sachangaben wurden vor der Veröffentlichung automatisch gegen die genannten Quellen geprüft.
Die Netzhandwerker