Apache 2.4.58 und trotzdem sicher: Warum dich die Versionsnummer bei der mod_http2-Lücke in die Irre führt

Podcast zum Blogbeitrag:

Du kennst das: Morgens kommt die Meldung „Kritische Lücke in Apache, Versionen 2.4.55 bis 2.4.70 betroffen“. Du tippst apache2 -v, und da steht 2.4.58. Mitten drin. Der Kaffee schmeckt plötzlich nicht mehr.Genau so ging es mir diese Woche mit der Apache mod_http2 Sicherheitslücke CVE-2026-119618. Zehn Minuten später war klar: Mein Server war nicht betroffen, und zwar gleich aus drei Gründen. Keiner davon hat mit der Versionsnummer zu tun.Hier ist der Ablauf, mit dem du das bei dir in zwei Minuten klärst. Er funktioniert auf Ubuntu und Debian, mit oder ohne Plesk.

Ziel

• Klären, ob dein Apache von CVE-2026-119618 betroffen ist.
• Verstehen, warum apache2 -v dafür die falsche Frage beantwortet.
• Wissen, was zu tun ist, wenn du nicht sofort patchen kannst.

Voraussetzungen

• Ein Server mit Apache unter Ubuntu oder Debian und ein Root-Zugang per SSH.
• Zwei Minuten. Wirklich.

Was hinter der Apache mod_http2 Sicherheitslücke steckt

Die Fakten aus der Apache-Meldung vom 11. November und von heise:

• CVE-2026-119618, von Apache als „critical“ eingestuft. Ubuntu führt sie mit Priorität „High“ und der knappen Begründung „This is a remote RCE“. Einen CVSS-Wert gibt es bisher nicht.
• Der Fehler steckt im HTTP/2-Modul mod_http2, in der Funktion assign_headers(). Zwei Abläufe greifen ohne saubere Abstimmung auf denselben Speicher zu. Das kann den Heap beschädigen und im schlimmsten Fall fremden Code ausführen.
• Betroffen ist Apache httpd 2.4.55 bis 2.4.70, behoben in 2.4.71.
• Laut heise sind nur Server betroffen, auf denen HTTP/2 im Apache aktiv ist. Ein funktionierender Exploit gilt als möglich, aber schwierig. Angriffe sind bisher nicht bekannt.

Gemeldet wurde die Lücke übrigens zweimal unabhängig voneinander: Ende Oktober von einem automatischen Code-Scanner von Anthropic, Anfang November von Forschern bei Google. Dass Maschinen inzwischen solche Fehler finden, ist die eigentliche Nachricht hinter der Nachricht. Aber das ist ein Thema für einen anderen Beitrag.

Schritt 1: Ist mod_http2 überhaupt geladen?

Als Erstes checke ich immer, ob das betroffene Modul läuft:

apache2ctl -M | grep -i http2

Kommt nichts zurück, ist das Modul nicht geladen, und die Lücke ist auf diesem Server nicht erreichbar. Steht dort http2_module (shared), geht es weiter mit Schritt 2.Bei mir kam nichts. Der Server war also schon an dieser Stelle raus.Hinweis: Lass dich nicht von einem grep -r Protocols /etc/apache2 täuschen. Die Datei mods-available/http2.conf enthält die Zeile Protocols h2 h2c http/1.1 auch dann, wenn das Modul gar nicht aktiviert ist. Es zählt nur, was unter mods-enabled liegt.

Schritt 2: Wer kann den Apache erreichen?

ss -ltnp | grep -E 'apache2|nginx' | awk '{split($6,a,"\""); print $4, a[2]}' | sort -u

Der awk-Teil kürzt nur die Ausgabe auf Adresse und Programmname. Ohne ihn siehst du dasselbe, nur mit einer langen Liste von Prozessnummern dahinter.Auf einem Plesk-Server mit nginx davor sieht das so aus:Apache lauscht nur auf 127.0.0.1, nach außen spricht allein nginx. HTTP/2 mit dem Browser macht dann nginx, und der reicht die Anfragen intern weiter. Die Lücke steckt in Apaches Modul, nicht in nginx.Das ist allerdings eine Schlussfolgerung von mir und keine Aussage von Apache: Wenn niemand von außen direkt mit dem Apache spricht, kommt auch niemand an sein HTTP/2-Modul. Als alleinigen Schutz würde ich mich nicht darauf verlassen. Lauscht dein Apache selbst auf Port 443, entfällt dieser Punkt sowieso.

Schritt 3: Steckt der Patch im Paket?

Jetzt die Frage, bei der apache2 -v nicht hilft:

zcat /usr/share/doc/apache2/changelog.Debian.gz | grep -B3 -e '- CVE-2026-119618'
dpkg -l apache2 | tail -1

Steht die CVE-Nummer im Changelog, ist die Korrektur eingebaut. Egal, was die Versionsnummer vorn behauptet.

Warum die Versionsnummer in beide Richtungen täuscht

Ubuntu und Debian heben bei Sicherheitsupdates in stabilen Versionen meist nicht die Apache-Version an. Sie bauen nur die Korrektur in die vorhandene Version ein. Aus 2.4.58 wird also nicht 2.4.71, sondern 2.4.58-1ubuntu8.19. Entscheidend ist der Teil hinter dem Bindestrich.Das führt zu zwei Fehlschlüssen:

• „2.4.58 liegt im betroffenen Bereich, also bin ich betroffen.“ Stimmt nicht, wenn das Paket aktuell ist.
• „Ich habe 2.4.52, das liegt unter 2.4.55, also bin ich sicher.“ Stimmt auch nicht. Ubuntu hat laut eigener Notiz neuere Versionen des Moduls in ältere Ubuntu-Versionen zurückportiert. Deshalb gibt es auch für 22.04 mit Apache 2.4.52 ein Update.

Diese Paketversionen enthalten die Korrektur:

System	Korrigiert ab Paketversion
Ubuntu 26.10	2.4.68-1ubuntu6.2
Ubuntu 26.04 LTS	2.4.66-2ubuntu2.8
Ubuntu 24.04 LTS	2.4.58-1ubuntu8.19
Ubuntu 22.04 LTS	2.4.52-1ubuntu4.27
Ubuntu 20.04 LTS	2.4.41-4ubuntu3.23+esm11 (nur mit Ubuntu Pro)
Debian 13 (trixie)	2.4.71-1~deb13u1
Debian 12 (bookworm)	2.4.71-1~deb12u1

Debian hat hier ausnahmsweise tatsächlich auf 2.4.71 angehoben. Ein Grund mehr, nicht zu raten, sondern nachzusehen.

Schritt 4: Läuft der neue Apache auch wirklich?

Ein installiertes Paket hilft nicht, wenn noch der alte Prozess im Speicher hängt:

grep ' upgrade apache2:' /var/log/dpkg.log | tail -1
systemctl show apache2 -p ActiveEnterTimestamp --value

Der Startzeitpunkt des Dienstes muss nach dem Upgrade liegen. Bei mir lagen zehn Sekunden dazwischen (die Serverzeit ist UTC): Das Paket kam morgens um halb acht automatisch über unattended-upgrades, einen Tag nach der Ubuntu-Meldung, und hat den Dienst gleich mit neu gestartet. Als ich die Meldung gelesen habe, war das Thema auf dem Server schon erledigt.Ob die automatischen Updates bei dir an sind, zeigt:

systemctl is-enabled unattended-upgrades

Wenn du nicht sofort patchen kannst

Apache selbst nennt keinen Workaround. heise empfiehlt, HTTP/2 im Apache vorübergehend abzuschalten. Auf Debian und Ubuntu geht das so:

a2dismod http2
apache2ctl configtest && systemctl restart apache2

Danach wieder prüfen mit Schritt 1. Deine Seiten bleiben erreichbar, nur eben über HTTP/1.1. Mit nginx davor merkt der Besucher davon nichts.

So prüfst du es

• apache2ctl -M | grep -i http2 liefert nichts, oder
• die CVE-Nummer steht im Paket-Changelog und der Dienst wurde nach dem Upgrade neu gestartet.

Eins von beiden reicht. Beides zusammen ist besser.

Rückweg

Falls du HTTP/2 nur vorübergehend abgeschaltet hast: Nach dem Update a2enmod http2, Konfiguration testen, Apache neu starten.

Stolperstellen aus der Praxis

• apache2 -v beantwortet die falsche Frage. Es zeigt die Version, von der das Paket abstammt, nicht den Patchstand. Ein Hinweis steckt trotzdem drin: Die Zeile „Server built“ nennt das Baudatum. Liegt es nach der Meldung, ist das ein gutes Zeichen.
• Konfigurationsreste täuschen. Protocols h2 in mods-available heißt nichts. Entscheidend ist apache2ctl -M.
• nginx kann HTTP/2, Apache muss es nicht. Auf Plesk-Servern mit nginx davor ist HTTP/2 für Besucher an, obwohl Apaches Modul aus ist. Das sind zwei verschiedene Programme.
• Installiert ist nicht gleich aktiv. Ohne Neustart läuft der alte Code weiter. Paket-Upgrades starten Apache normalerweise neu, aber prüf den Zeitstempel.
• Automatische Updates decken nicht alles ab. unattended-upgrades spielt in der Standardeinstellung nur Sicherheitsupdates der Distribution ein. Pakete aus anderen Quellen, etwa die von Plesk selbst, laufen über deren eigene Aktualisierung.
• Ubuntu 20.04 bekommt die Korrektur nur mit Ubuntu Pro. Wer dort noch ohne Pro unterwegs ist, hat ein größeres Problem als diese eine Lücke.
• Im selben Update stecken noch drei weitere Korrekturen, unter anderem für mod_md (CVE-2026-106023). Wer Zertifikate über mod_md holt, sollte das Update auch dann nicht aufschieben, wenn HTTP/2 aus ist.

Fazit

Bei der Apache mod_http2 Sicherheitslücke entscheidet nicht die Versionsnummer, sondern drei andere Dinge: Ist das Modul geladen? Kommt jemand von außen dran? Steckt der Patch im Paket und läuft er auch? Mein Server hat an allen drei Stellen bestanden, und zwei davon waren Glück der Voreinstellung.Neulich habe ich beim Zyxel-Switch gelernt, dass eine neue Versionsnummer keine Sicherheit beweist. Diese Woche war es andersherum: Eine alte Versionsnummer beweist keine Lücke. Versionsnummern sind offenbar wie Türschilder. Was dahinter wirklich wohnt, sieht man erst, wenn man klingelt.Quellen: Apache HTTP Server 2.4: Sicherheitsmeldungen · Ubuntu: CVE-2026-119618 · Debian Security Tracker: CVE-2026-119618 · heise: Kritische Apache2-Lücke ermöglicht Codeeinschleusung