Debian 13: Fünf nginx-Sicherheitslücken – mein Worldnode-Praxischeck

21. Oktober 2026: Was Debian gemeldet hat

Am 21. Oktober 2026 veröffentlichte das Debian-Sicherheitsteam DSA-6575-1 für nginx. Die Meldung fasst fünf Schwachstellen zusammen, deren Auswirkungen von Speicherfehlern und Dienstunterbrechungen bis hin zu eingeschleusten Backend-Anfragen oder einer möglichen Umgehung der Client-Zertifikatsprüfung reichen. Entscheidend ist das Wort möglich: Die Angriffspfade hängen von Modulen, Direktiven und der konkreten Bereitstellung ab. Nicht jeder nginx-Server ist durch alle fünf Fehler angreifbar.

Für Debian 13 „Trixie“ nennt Debian das korrigierte Paket 1.26.3-3+deb13u10. Die Upstream-Projekte nginx und F5 dokumentieren die Fehler separat; Debian liefert dafür eigene Paketrevisionen. Deshalb ist eine reine nginx -v-Abfrage kein Ersatz für die Überprüfung des Debian-Paketstands.

Fünf CVEs, fünf unterschiedliche Voraussetzungen

Die folgende Übersicht folgt den technischen Beschreibungen aus DSA-6575-1 und dem nginx-Sicherheitsverzeichnis. Sie zeigt die jeweils relevanten Funktionen, ohne aus jeder Schwachstelle pauschal eine universelle Remote-Code-Ausführung zu machen.

Ein wichtiger Debian-Sonderfall: Der von CVE-2026-93479 betroffene Code wurde laut DSA durch einen früheren Sicherheits-Backport in Trixie eingeführt. Aus den Upstream-Versionsbereichen allein lässt sich der Debian-Betroffenheitsstatus deshalb nicht sicher ableiten.

Wer ist tatsächlich betroffen?

Bei alias + rewrite zählt die Kombination der beiden Anweisungen. Bei HTTP/3 müssen die entsprechenden Protokollfunktionen genutzt werden; das Backend-Injektionsszenario verlangt zusätzlich Proxy-Verhalten. Der AIO-Fehler hängt mit asynchroner Datei-I/O zusammen. Die Ticket-Problematik ist insbesondere für Setups mit ssl_session_cache shared:... ohne explizite ssl_session_ticket_key-Dateien beschrieben; sicherheitsrelevant kann sie vor allem dort werden, wo Client-Zertifikate Zugriffe schützen.

Für einen einzelnen Server darf man diese Voraussetzungen nur aus dessen Konfiguration und Nutzung beurteilen. Ich habe im Rahmen dieser Untersuchung keine vollständige nginx-Konfigurationsprüfung und keine aktiven Angriffstests auf Worldnode durchgeführt. Die gute Nachricht lautet hier ausdrücklich: Die von Debian korrigierte Paketversion ist installiert.

Warum nginx 1.26.3 nicht automatisch „ungepatcht“ bedeutet

nginx dokumentiert in seinem Upstream-Sicherheitsverzeichnis die Fehlerbehebungen unter anderem für 1.30.6+ und 1.31.7+. Debian Stable verfolgt eine andere Strategie: Sicherheitskorrekturen werden in die unterstützte Paketbasis zurückportiert, ohne zwangsläufig auf die neueste Upstream-Hauptversion zu wechseln. Das relevante Kriterium auf Trixie ist daher 1.26.3-3+deb13u10 oder eine nachfolgende korrigierte Debian-Paketversion.

apt-cache policy nginx
# Installiert / Installed: 1.26.3-3+deb13u10
# Paketquelle: trixie-security

Eine Versionszeichenfolge ist nur im Kontext von Distribution, Paketrevision und Sicherheits-Tracker aussagekräftig. Auch ein aktueller Paketstand belegt für sich genommen noch nicht, ob alle laufenden Worker das aktualisierte Programm geladen haben.

Mein Praxischeck auf Worldnode: Vier Originalaufnahmen

Am 26. Oktober habe ich auf Worldnode nachgesehen, ob die Korrektur bereits angekommen war. Ich habe nicht blind aktualisiert, sondern zuerst den vorhandenen Zustand abgefragt und anschließend die Protokolle rückwärts überprüft. Diese vier Aufnahmen stammen aus meiner tatsächlichen Terminalsitzung; die WebP-Versionen sind lediglich für die Darstellung komprimiert. Die Original-PNGs bleiben als Beleg erhalten.

Die zeitliche Nähe zwischen Paketinstallation und Dienststart ist sichtbar. Welcher konkrete Mechanismus den Start ausgelöst hat, wurde in diesen vier Abfragen jedoch nicht separat nachgewiesen. Die APT-History zeigt außerdem automatische Aktualisierungen von ca-certificates, bind9 und libbrotli1; sie sind hier nur Kontext.

Was unattended-upgrades erledigt – und was nicht

unattended-upgrades kann Sicherheitsupdates aus konfigurierten APT-Quellen automatisiert installieren. Auf Worldnode hat es für diese Transaktion nachweislich funktioniert. Auf anderen Systemen kann die Funktion deaktiviert sein, ein Paket durch Pinning oder Holds blockiert werden oder eine APT-Quelle fehlen. Automatik ersetzt weder Update-Monitoring noch Dienst- und Konfigurationsprüfungen.

Besonders wichtig in der Produktion: Ein installiertes Update und ein erfolgreicher Service-Status bedeuten nicht, dass sämtliche Konfigurationsrisiken ausgeschlossen sind. Prüft Update-Historie, tatsächlichen Service-Zustand und nötige Neustarts separat.

Selbst prüfen: Sichere, lesende Kommandos

Die folgenden Befehle lesen nur Informationen und ändern keine Pakete oder Dienste. Sie sind einzeln ausführbar.

apt-cache policy nginx

Installierte Version, Kandidat und APT-Paketquelle vergleichen. Für Debian 13 ist der von DSA-6575-1 genannte Korrekturstand 1.26.3-3+deb13u10.

dpkg-query -W -f='${binary:Package} ${Version}\n' nginx nginx-common

Den tatsächlichen dpkg-Paketstand beider Komponenten anzeigen. nginx -v allein genügt wegen Debian-Backports nicht.

systemctl status nginx --no-pager --lines=0

Prüfen, ob der Dienst aktiv ist und seit wann. Nicht mit einer vollständigen Sicherheitsprüfung verwechseln.

sudo zgrep -hE ' (install|upgrade) nginx(:amd64|\-common:all) ' /var/log/dpkg.log* | sort | tail -n 15

Die Paket-Historie einschließlich rotierter Logs durchsuchen. Bei abweichender Architektur muss der Filter angepasst werden.

sudo zgrep -h -A 8 'Start-Date: 2026-10-22' /var/log/apt/history.log*

Ein datumsbezogenes Beispiel für APT-History; auf dem eigenen Server den passenden Tag verwenden. Zusätzliche Prüfungen von /var/log/unattended-upgrades/ helfen bei der Ursachenanalyse.

Ändernde Schritte: apt update aktualisiert Paketlisten, apt upgrade installiert Pakete; systemctl restart greift in laufende Dienste ein. Vor solchen Aktionen auf Produktionssystemen Wartungsfenster, Sicherungen, Rollback-Möglichkeiten und eine zweite Administrationssitzung berücksichtigen.

Häufige Fehlschlüsse

• „1.26.3 ist älter als 1.30.6, also verwundbar“: falsch ohne Prüfung der Debian-Paketrevision und des Security Trackers.
• „nginx läuft, also sind alle CVEs behoben“: der Service-Status sagt nichts über die installierten Sicherheitspatches.
• „Alle fünf CVEs betreffen jede Website“: die jeweiligen Direktiven und Module sind entscheidend.
• „Auto-Updates sind aktiviert, also ist nichts mehr zu prüfen“: Update-Fehler, Holds und nicht neu gestartete Prozesse bleiben möglich.
• „Ein Restart wurde sicher durch Mechanismus X ausgelöst“: ohne zusätzliche Protokolle ist das Spekulation.

Checkliste für Administratoren

1. Distribution, Release und Herkunft der nginx-Pakete eindeutig bestimmen.
2. Debian-Advisory und Security Tracker für die jeweilige Suite lesen.
3. apt-cache policy und dpkg-query auswerten.
4. Installationsverlauf und laufenden Dienst separat prüfen.
5. Falls der Korrekturstand fehlt: Upgrade geplant und abgesichert durchführen.
6. Auto-Updates überwachen; nicht nur aktivieren.
7. HTTP/3, AIO, Alias/Rewrite und Client-Zertifikatsnutzung nur nach tatsächlicher Konfiguration bewerten.

Fazit: Vertrauen durch überprüfbare Daten

Für mich ist das die eigentliche Pointe dieser Untersuchung: Ich habe am 26. Oktober nachgesehen und festgestellt, dass Worldnode das nginx-Sicherheitsupdate schon am 22. Oktober selbstständig installiert hatte. Nicht ein grünes Symbol, sondern vier zueinander passende Originalbelege machen diese Aussage belastbar.

Der sinnvolle Standard bleibt: Sicherheitsmeldung verstehen, Paketrevision prüfen, Dienststatus kontrollieren und die Historie bei Bedarf nachlesen. Automatische Updates sind ein nützlicher Teil dieses Prozesses, aber nicht der gesamte Prozess.