Nginx: Drei kritische Sicherheitslücken im Webserver fast jeder dritten Website

Markus Seyfferth

Autor Dr. Web

25. Okt. 2026

3 Min. Lesezeit

F5 hat am 14. Oktober drei Speicherfehler im Webserver Nginx geschlossen, über die Angreifer im schlimmsten Fall eigenen Code auf dem Server ausführen können. Der Hersteller bewertet die Sicherheitslücken mit 9,2 von 10 Punkten als kritisch, die Projektseite nginx.org nur als mittel. Laut W3Techs läuft Nginx auf 30,2 % aller Websites mit bekanntem Webserver.^[5]

Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügen

Ein location-Block mit alias, rewrite und einer set-Anweisung mit $request_filename reicht, damit ein Nginx-Server für eine der drei Lücken angreifbar wird.^[1] Auf der Liste aktiv ausgenutzter Sicherheitslücken der US-Behörde CISA steht keine der drei, Stand 23. Oktober.^[6]

Auf einen Blick

Das Wichtigste in Kürze

Abgesichert sind Nginx 1.30.6, 1.31.7 und neuer, betroffen sind je nach Lücke Versionen ab 0.1.29.
Eigenen Code ausführen können Angreifer nur ohne wirksamen Speicherschutz ASLR.
Debian 13 liefert aktualisierte Pakete, für Debian 12 fehlt die Korrektur noch.

Welche Einstellungen machen Nginx angreifbar?

Servergehäuse mit drei gelben Warnstickern und einem Anhänger „Bitte prüfen“ — Drei Sicherheitslücken im Nginx-Worker-Prozess ermöglichen Angriffe ohne Authentifizierung durch präparierte Anfragen bei bestimmten Konfigurationen

Alle drei Fehler stecken im Worker-Prozess, dem Teil von Nginx, der die Anfragen der Besucher bearbeitet. Trifft eine dieser Einstellungen zu, genügt eine präparierte Anfrage ohne Anmeldung:

CVE-2026-15176: alias zusammen mit rewrite und einer set- oder return-Anweisung, die $request_filename nutzt, betroffen ab Version 0.1.29.^[1]
CVE-2026-93479: eine map mit regulärem Ausdruck, sobald root oder ein Logformat Platzhalter wie $1 für die Klammergruppen des Ausdrucks liest, bevor map ihr Ergebnis festlegt, betroffen erst ab Version 1.30.0.^[2]
CVE-2026-97205: asynchrones Lesen von Dateien (aio) zusammen mit Server Side Includes (SSI), also Bausteinen, die der Server beim Ausliefern per „include virtual“ einfügt, betroffen ab Version 0.8.11.^[3]

Wie gefährlich ein erfolgreicher Angriff wird, entscheidet der Speicherschutz. Eigenen Code können Angreifer laut F5 nur ausführen, wenn ASLR abgeschaltet ist oder sie den Schutz umgehen. Andernfalls stürzt der Worker-Prozess ab und startet neu, eine Serie solcher Anfragen legt die Website lahm.^[1] ASLR legt Programmteile bei jedem Start an zufällige Adressen im Arbeitsspeicher.^[9]

Bei der Einstufung widerspricht sich F5 selbst. Nach dem Bewertungssystem CVSS 4.0 gelten alle drei mit 9,2 Punkten als kritisch, nach dem älteren CVSS 3.1 kommen sie auf 8,1. Das eigene Open-Source-Projekt führt sie auf nginx.org als „mittel“.^[4]

Warum häufen sich die Sicherheitslücken in Nginx?

Auf nginx.org stehen 26 Sicherheitslücken mit einer CVE-Nummer aus dem Jahr 2026, aus 2025 nur zwei.^[4] Wie solche Funde heute entstehen, zeigt NGINX Rift: Den 18 Jahre alten Fehler im rewrite-Modul fand die Plattform des Sicherheitsanbieters depthfirst im Mai nach eigenen Angaben selbstständig, den Beispielcode für einen Angriff veröffentlichte depthfirst gleich mit.^[7]

Die Muster wiederholen sich. Rift ging auf unbenannte Platzhalter wie $1 in einer rewrite-Regel zurück, für CVE-2026-93479 empfiehlt F5 dieselbe Abhilfe: benannte Gruppen statt $1.^[2] Neben Nginx verlangen im Oktober auch PHP2Shell und HTTP2Shell in Googles Brotli die Aufmerksamkeit der Serverbetreiber.

Ein Webserver mit 26 Sicherheitslücken in zehn Monaten gehört auf die wöchentliche Update-Liste, nicht auf die jährliche.
Michael Dobler, Herausgeber Dr. Web

Kritische Nginx-Sicherheitslücken: Die Konfiguration entscheidet

Auslöser und betroffene Versionen laut F5 und nginx.org, Marktanteil laut W3Techs, Stand 25. Oktober 2026.

9,2

von 10 Punkten nach CVSS 4.0 für jede der drei Lücken, auf nginx.org nur „mittel“

30,2 %

aller Websites mit bekanntem Webserver laufen auf Nginx

Nginx-Sicherheitslücken mit CVE-Nummer aus 2026, aus 2025 nur zwei

1.30.6

und 1.31.7 heißen die abgesicherten Versionen vom 14. Oktober

Wann ein Nginx-Server angreifbar ist

LückeAuslöser in der KonfigurationBetroffen

CVE-2026-15176alias mit rewrite und $request_filenameab 0.1.29

CVE-2026-93479map mit regulärem Ausdruck und Platzhaltern wie $11.30.0 bis 1.30.5, 1.31.2 bis 1.31.6

CVE-2026-97205aio zusammen mit SSI und „include virtual“ab 0.8.11

KorrekturUpdate oder Notlösung von F51.30.6, 1.31.7

Was sollten Betreiber jetzt tun?

Bei Shared und Managed Hosting spielt der Hoster das Update ein. Auf einem eigenen dedizierten Server oder einem V-Server bleibt die Aufgabe beim Betreiber. Debian 13 liefert die Korrektur mit DSA-6575-1, das Paket für Debian 12 war am 25. Oktober noch verwundbar.^[8] Dass Nginx-Server besondere Sorgfalt brauchen, zeigte Anfang Oktober auch das Backup-Plugin BackWPup, dessen Archive dort ungeschützt lagen.

Prüfen Sie mit nginx -v die Version und aktualisieren Sie auf 1.30.6, 1.31.7 oder das korrigierte Paket Ihrer Linux-Distribution.
Durchsuchen Sie die Ausgabe von nginx -T nach alias, $request_filename, map mit regulären Ausdrücken, aio und ssi.
Bis zum Update helfen die Notlösungen von F5: benannte Gruppen statt $1, aio abschalten oder keine SSI-Seiten ausliefern, alias meiden.^{[1], [2], [3]}
Kontrollieren Sie gerne, ob /proc/sys/kernel/randomize_va_space den Wert 2 zeigt, die volle Zufallsverteilung der Speicheradressen.^[9]