Digitale Sicherheit

nginx schliesst fünf Lücken im Oktober: Webserver prüfen und aktualisieren

E
ElaraTeq
Titelbild: fünf Lücken in nginx geschlossen, Webserver auf Version 1.30.6 oder das korrigierte Ubuntu- und Debian-Paket aktualisieren

Am 14. Oktober hat nginx 1.30.6 fünf Lücken geschlossen (CVE-2026-15176 und weitere), verteilt von Ubuntu am 26. Oktober und von Debian 13. Keine bekannte Ausnutzung, aber das Update ist einzuplanen. Warum die Versionsnummer täuscht, was am Server zu prüfen ist und wann der EDÖB zu informieren ist.

Am 14. Oktober 2026 hat das nginx-Projekt die Versionen 1.30.6 (stable) und 1.31.7 (mainline) veröffentlicht, die fünf Sicherheitslücken schliessen. Am 26. Oktober hat Ubuntu die korrigierten Pakete mit der Meldung USN-8955-1 verteilt; Debian hat für Debian 13 mit DSA-6575-1 nachgezogen.

nginx ist der Webserver oder Proxy, der die Anfragen sehr vieler Websites, Geschäftsanwendungen und Web-Apps auf Linux-Servern beantwortet. Für ein Tessiner KMU mit VPS oder dediziertem Server ist die praktische Frage einfach: Ist die installierte Version die korrigierte? Die Antwort erfordert etwas Sorgfalt, denn die Versionsnummer, die Linux-Distributionen anzeigen, führt leicht in die Irre.

Was korrigiert wurde

Laut den Sicherheitsmeldungen von nginx betreffen die fünf Lücken bestimmte Funktionen oder Konfigurationskombinationen, nicht jede Installation:

CVEBereichBetroffene Versionen (nginx.org)CVSS 3.1 (F5)
CVE-2026-15176Direktive alias zusammen mit rewrite0.1.29–1.31.68.1
CVE-2026-93479Auswertung von Ausdrücken mit Variablen (zum Beispiel map mit regulären Ausdrücken)1.30.0–1.30.5, 1.31.2–1.31.68.1
CVE-2026-95101HTTP/3 mit Pufferung der Anfrage an den Backend-Server1.25.0–1.31.65.3
CVE-2026-97629TLS-Session-Tickets mit gemeinsam genutztem Session-Cache1.23.2–1.31.66.5
CVE-2026-97205asynchrone Datei-Ein-/Ausgabe (AIO) mit SSI-Seiten0.8.11–1.31.68.1

Die Einstufungen gehen auseinander, und es hilft zu verstehen, warum:

  • nginx stuft alle fünf Lücken als mittel ein, weil besondere Konfigurationen nötig sind.
  • F5, das Unternehmen hinter nginx, das die CVEs vergeben hat, bewertet drei davon laut NVD-Datenbank mit CVSS 3.1 8.1 (hoch): Im schlimmsten Fall kann ein Angreifer ohne Zugangsdaten nginx-Prozesse zum Absturz bringen und, wenn der Speicherschutz des Systems (ASLR) deaktiviert oder umgangen ist, bis zur Codeausführung gelangen.
  • Die Lücke bei den TLS-Tickets (CVE-2026-97629) kann die Prüfung von Client-Zertifikaten aushebeln, ein Mechanismus, der vor allem für geschützte Zugänge und Schnittstellen zwischen Systemen genutzt wird.

Laut den Daten der NVD meldete die Einschätzung der CISA vom 15. Oktober keine bekannte Ausnutzung, und per 9. November steht keine der fünf Lücken im Katalog ausgenutzter Schwachstellen. Es gibt also keinen Grund zur Aufregung, aber auch keinen zum Abwarten: Das Update sollte zeitnah eingeplant werden.

Eine Zahl ordnet das Thema ein: 2026 hat nginx bereits 26 Sicherheitsmeldungen veröffentlicht. Den Webserver zu aktualisieren ist eine wiederkehrende Aufgabe, kein ausserordentlicher Eingriff.

Das Detail, das man kennen muss: die Versionsnummer

Linux-Distributionen installieren nicht die neueste nginx-Version, sondern korrigieren die Version, die sie zu Beginn des Lebenszyklus des Systems gewählt haben. Unter Ubuntu 24.04 zeigt nginx -v zum Beispiel auch nach dem Update 1.24.0 an: Die Korrektur steckt in der vollständigen Paketversion. Um zu wissen, ob ein Server korrigiert ist, vergleicht man deshalb die Paketversion mit derjenigen in der Meldung der eigenen Distribution.

Als korrigiert aufgeführte Versionen des Pakets nginx (Auszug):

SystemKorrigiertes Paket
Ubuntu 26.04 LTS1.28.3-2ubuntu1.12
Ubuntu 24.04 LTS1.24.0-2ubuntu7.19
Ubuntu 22.04 LTS1.18.0-6ubuntu14.22
Debian 13 (trixie)1.26.3-3+deb13u10
Debian 12 (bookworm)per 9. November führt der Debian-Security-Tracker das Paket noch als verwundbar
nginx.org (stable / mainline)1.30.6 / 1.31.7

Hosting-Panels und Container-Images (Docker) enthalten oft eine eigene Kopie von nginx: Dann zählt die Version des Panels oder des Images, nicht diejenige des Betriebssystems.

Was mit dem eigenen Server zu tun ist

  1. Wissen, wo nginx läuft. Nicht nur auf dem Server der Website: nginx wird oft als Proxy vor Geschäftsanwendungen, Web-Apps oder Containern eingesetzt. Erstellen Sie eine Liste der betroffenen Systeme.
  2. Paketversion prüfen. Unter Ubuntu und Debian mit apt policy nginx oder beim Anbieter nachfragen und mit der Tabelle oben oder der Meldung der Distribution vergleichen.
  3. Aktualisieren und den Dienst neu starten. Das Sicherheitsupdate der Distribution installieren, oder 1.30.6 oder neuer, wenn nginx aus den offiziellen Paketen von nginx.org stammt, und prüfen, ob der Dienst tatsächlich neu gestartet wurde. Bei Container-Images: Image aktualisieren und Container neu erstellen.
  4. Wenn das Update noch nicht verfügbar ist (zum Beispiel unter Debian 12 zum Zeitpunkt der Veröffentlichung): die Konfiguration vom Serverbetreiber prüfen lassen. Die Lücken hängen von bestimmten Funktionen ab (HTTP/3, SSI mit asynchroner Ein-/Ausgabe, Client-Zertifikate, bestimmte Kombinationen von alias und rewrite): Was nicht gebraucht wird, abzuschalten, verringert die Angriffsfläche bis zur Korrektur.
  5. Logs prüfen. Im Fehlerlog von nginx können unerwartete Neustarts der Worker-Prozesse auf erfolglose Versuche oder ein näher zu untersuchendes Problem hinweisen.

Wir veröffentlichen keine Details zur Ausnutzung dieser Lücken: Ziel ist, die Systeme zu aktualisieren und zu prüfen. Über Updates von Ubuntu- und Debian-Servern haben wir auch im Zusammenhang mit der Lücke in APT geschrieben.

Wenn der Server kompromittiert wurde: Meldungen

  • Datenschutz (revDSG). Enthält der Server Personendaten (Kunden, Formulare, Konten) und führt die Verletzung voraussichtlich zu einem hohen Risiko für die betroffenen Personen, verlangt Artikel 24 des Datenschutzgesetzes eine Meldung an den EDÖB so rasch als möglich. Der Leitfaden des EDÖB erklärt, wie der Fall zu beurteilen ist.
  • BACS. Für die meisten KMU ist die Meldung eines Cybervorfalls an das BACS freiwillig, aber sinnvoll. Seit dem 1. April 2025 gilt für Betreiberinnen kritischer Infrastrukturen dagegen eine Meldepflicht für Cyberangriffe innert 24 Stunden nach der Entdeckung.
  • Finanzieller Schaden. Bei einem Schaden Anzeige bei der Kantonspolizei erstatten.

Häufige Fragen

Unsere Website liegt auf einem Shared Hosting: Müssen wir etwas tun?

Der Server wird vom Anbieter betrieben, der die Updates einspielen muss. Es lohnt sich trotzdem, schriftlich nachzufragen, ob der Webserver nginx verwendet und ob die Oktober-Updates installiert wurden.

Unser Server läuft mit Apache: Sind wir betroffen?

Diese Lücken betreffen nur nginx. Viele Installationen nutzen nginx jedoch als Proxy vor Apache oder anderen Anwendungen: Das lohnt sich zu prüfen.

nginx -v zeigt eine alte Version: Ist der Server verwundbar?

Nicht unbedingt. Bei Linux-Distributionen zählt die vollständige Paketversion, die die von der Distribution übernommenen Korrekturen enthält. Stimmt sie mit der Meldung überein, ist der Server korrigiert.

Wir nutzen weder HTTP/3 noch SSI: Können wir das Update auslassen?

Nein. Die Lücken betreffen unterschiedliche Funktionen, und man unterschätzt leicht, was eine über Jahre gewachsene Konfiguration enthält. Das Update ist der einfachste Weg, alle fünf Lücken auf einmal zu schliessen.

Unser Ansatz

ElaraTeq Sagl unterstützt KMU und Praxen im Tessin beim Betrieb und Aktualisieren von Linux- und Webservern, beim Hosting in der Schweiz und bei der TLS-Konfiguration (Hosting, Beratung; zu TLS siehe auch die 100-Tage-Zertifikate). Für eine Prüfung Ihres Servers können Sie uns kontaktieren.

Quellen

Tags: #nginx #CVE-2026-15176 #server web #Linux #Ubuntu #Debian #aggiornamenti #nLPD #PMI #Ticino
Teilen:

Möchten Sie mit uns arbeiten?

Lassen Sie uns besprechen, wie wir Ihre Vision zum Leben erwecken können.

Kontaktieren Sie uns