Sechs Stunden, achtzehn Jahre: Was NGINX Rift dem Mittelstand sagt

Am 13. Mai 2026 veröffentlichen F5 und der Security-Researcher depthfirst eine Disclosure mit Sprengkraft. CVE-2026-42945, Codename NGINX Rift, CVSS 9.2. Unauthentifizierte Remote Code Execution im ngx_http_rewrite_module von NGINX. Betroffen: alle Open-Source-Versionen von 0.6.27 bis 1.30.0 und NGINX Plus R32 bis R36. Der Bug liegt seit 2008 im Code. Achtzehn Jahre.

Die eigentliche Pointe steht in der Disclosure-Fußnote. Den Bug fand kein menschlicher Researcher. Er fand ihn ein autonomes KI-Analyse-System. Sechs Stunden Laufzeit gegen eine der am intensivsten geprüften Open-Source-Codebasen der Welt. Das ist die direkte Bestätigung der These, die ich am 13. Mai im Artikel zur Mythos-Glasswing-Asymmetrie als kommende Realität skizziert habe. Sie ist eine Woche später eingetreten.

Dieser Beitrag entpackt den Bug technisch, ordnet ihn neben die anderen Funde dieser Woche ein und liefert ein konkretes Vorgehen für Mittelstand-IT-Teams, die in den nächsten Tagen patchen oder mindestens konfigurativ entschärfen müssen. Das Thema fällt in meine IT-Strategie- und Sicherheits-Beratung sowie in die KI- und Automatisierungsberatung für mittelständische Unternehmen.

Was NGINX Rift technisch ist

Der Bug sitzt in der rewrite-Direktive von NGINX. Konkret: Wenn eine rewrite-Direktive einen unbenannten PCRE-Capture nutzt ($1, $2, …) plus einen Replacement-String mit einem Fragezeichen, und direkt darauf ein weiteres rewrite, if oder set folgt, dann passieren zwei Buffer-Operationen nacheinander, die unterschiedlich rechnen.

Im ersten Pass wird die benötigte Buffer-Größe mit einer Escaping-Methode berechnet. Im zweiten Pass wird mit einer anderen Escaping-Methode geschrieben. Der zugrunde liegende is_args-Flag wird zwischen den beiden Operationen nicht sauber propagiert. Resultat: zu kleiner Heap-Buffer wird allokiert, zu viel attacker-kontrollierte URI-Daten werden hineingeschrieben, der Heap geht über.

Aus Sicht eines Angreifers bedeutet das: ein einzelner HTTP-Request gegen einen verwundbaren NGINX, kein Authentifizierungs-Schritt nötig, kein bestehender Session-Kontext erforderlich. Bei deaktiviertem ASLR ist Remote Code Execution im Worker-Prozess reproduzierbar. Bei aktiviertem ASLR ist zumindest ein zuverlässiger Denial-of-Service möglich. Ein Proof-of-Concept ist mit der Disclosure veröffentlicht.

Drei zusätzliche CVEs wurden zeitgleich offengelegt:

• CVE-2026-42946 (CVSS 8.3): exzessive Speicher-Allokation in den SCGI- und UWSGI-Modulen
• CVE-2026-40701 (CVSS 6.3): Use-after-free im SSL-Modul mit aktiviertem OCSP
• CVE-2026-42934 (CVSS 6.3): Out-of-bounds-Read im Charset-Modul

NGINX Rift selbst ist der kritischste der vier.

Wer betroffen ist

NGINX läuft global auf rund einem Drittel aller Websites. Reverse Proxy vor Anwendungs-Servern, Load Balancer im Rechenzentrum, API-Gateway in Container-Stacks, Frontend für Mail- und Streaming-Backends. In den meisten Mittelstands-Setups sitzt NGINX an mindestens einer der folgenden Stellen:

• Vor dem ERP-Webclient (SAP Fiori, Microsoft Dynamics 365 Self-Service, branchenspezifische Java-Frontends)
• Vor dem Onlineshop (Shopware, Magento, Spryker, Custom)
• Vor dem Kundenportal (B2B-Selbstbedienung, Lieferanten-Login)
• Im Office-Loadbalancer für Cloud-Apps und VPN-Gateways
• Im Container-Cluster als Ingress-Controller

Wer eine dieser Funktionen extern erreichbar betreibt, hat NGINX im Pfad. Auch dann, wenn die IT-Abteilung das auf Anhieb nicht sicher weiß, weil NGINX häufig als Default-Komponente in Standard-Distributionen, Docker-Images und Helm-Charts mitgeliefert wird.

Wie der Bug gefunden wurde

NGINX ist eines der am intensivsten geprüften Open-Source-Projekte überhaupt. Tausende Entwickler, Security-Researcher und Contributoren haben den Code seit 2008 reviewed. Externe Audits, automatisierte Static-Analyzer, manuelle Code-Reviews, Bug-Bounty-Programme. Achtzehn Jahre lang hat niemand diesen spezifischen Bug gefunden.

depthfirst, das den Bug meldete, ließ ein autonomes Vulnerability-Analyse-System auf den NGINX-Quellcode laufen. Nach sechs Stunden lag der Heap-Overflow auf dem Tisch. Mit Reproducer, mit Pfad zur Ausnutzung, mit Workaround-Hinweis.

Das ist exakt das Pattern, das in der Mozilla-Mythos-Story aus der Vorwoche beschrieben wurde. Ein KI-System reasoniert sich durch komplexen Code und findet Bugs, die menschliches Review systematisch übersieht — nicht weil Menschen schlechter sind, sondern weil die Geduld und die parallele Aufmerksamkeit nicht skalieren. Sechs Tage liegen zwischen dem Mozilla-Bericht (271 Bugs in Firefox, ältester 15 Jahre alt) und der NGINX-Rift-Disclosure (4 CVEs in NGINX, der kritische 18 Jahre alt).

Sechs Tage. Das ist die neue Frequenz.

Was Sie diese Woche tun sollten

Ich teile das hier in zwei Tracks: einer für die unmittelbare Pflicht-Reaktion, einer für die Strategie der nächsten Monate.

Track 1: Patch oder Workaround in 48 Stunden

NGINX Plus Kunden bekommen die Fixes in R32 P6 und R36 P4. Open-Source-Anwender patchen auf 1.30.1 oder 1.31.0. Versionen 0.6.27 bis 0.9.7 sind End-of-Life, dort gibt es keinen Fix. Wer dort steht, muss migrieren.

Wenn ein Patch nicht in 48 Stunden möglich ist, gibt es einen sauberen Konfigurations-Workaround: alle unbenannten PCRE-Captures in rewrite-Direktiven durch benannte Captures ersetzen.

Vorher (verwundbar):

rewrite ^/users/([0-9]+)$ /profile.php?id=$1 last;

Nachher (sicher):

rewrite ^/users/(?<user_id>[0-9]+)$ /profile.php?id=$user_id last;

Der Workaround verändert die Funktionalität nicht. Er entfernt die Bug-Bedingung. Audit-Aufwand pro NGINX-Konfiguration: typischerweise unter einer Stunde, bei sehr großen Setups mit vielen rewrite-Direktiven einige Stunden.

Track 2: Asset-Inventory und Audit-Pipeline

Die unbequemere Übung beginnt nach dem Patch. Wer betreibt eigentlich welche NGINX-Instanz, in welcher Version, mit welcher Konfiguration? In den meisten Mittelstands-Setups ist die Antwort auf alle drei Fragen unscharf.

Ein pragmatisches Vorgehen für die kommenden zwei Wochen:

1. NGINX-Asset-Inventory auf Basis vorhandener Konfigurations-Management-Daten erstellen (Ansible, Puppet, Salt, Kubernetes-Manifeste). Dort, wo nichts existiert, mit ss -tlnp oder Nessus-Discovery beginnen.
2. Versions-Audit pro Instanz, geclustert nach „intern, niemals extern erreichbar" und „extern erreichbar oder über Reverse-Proxy erreichbar".
3. Patch-Plan mit Fenster, beginnend mit den extern erreichbaren Instanzen. Workaround für alles, was nicht in den ersten 72 Stunden patchbar ist.
4. Nach Abschluss: Setup für die nächste Welle. Wer beim aktuellen Bug improvisieren musste, wird beim nächsten ähnlichen Fund ebenfalls improvisieren. Ein dauerhafter Inventory- und Patch-Prozess kostet weniger als zwei dieser Welle-improvisierten Wochen pro Jahr.

Die Pflicht-Lektion: Sechs Tage sind die neue Frequenz

Wer den Mythos-Artikel der Vorwoche gelesen hat, kennt die These bereits. KI-Audits finden in Stunden, was menschliches Review in Jahren übersehen hat. Die Frage war nur, wann das jenseits von Frontier-Modellen wie Anthropics Mythos auch in der breiten Open-Source-Welt sichtbar wird.

Antwort: sechs Tage später.

Das ist die strategische Pointe für mittelständische IT-Verantwortliche. Wer heute Custom-Code im Einsatz hat, der nie KI-auditiert wurde, hat eine endliche Zeitspanne, bevor jemand anderes dieselbe Code-Basis mit einem Frontier-Modell scannt. Im günstigsten Fall ist das ein Security-Researcher, der zuerst eine Disclosure macht. Im ungünstigsten Fall jemand mit anderen Motiven.

Drei zusätzliche Stories aus dieser Woche zeigen, wie eng die Lage geworden ist:

• Am 11. Mai wurde CVE-2026-44338 in PraisonAI veröffentlicht, einem KI-Multi-Agent-Framework. Drei Stunden 44 Minuten nach der Disclosure begann automatisierte Scanner-Aktivität auf öffentlich exponierten Instanzen. Authentifizierung war im Default-Konfigurationsmodus per Hard-Code deaktiviert. Die Time-to-Exploit ist auf unter vier Stunden gesunken.
• Am 12. Mai bestätigte Foxconn einen Ransomware-Vorfall durch die Gruppe Nitrogen. 8 Terabyte, 11 Millionen Dateien, darunter Hardware-Schematics für Apple, Nvidia, Google, Dell, Intel und AMD. Manufacturing-Betriebe stehen im Visier wie nie zuvor.
• Heute, am 13. Mai, kommt NGINX Rift dazu.

Drei Stories in 72 Stunden, in einem Themengebiet, das gestern noch wie ein eher abstraktes Risiko aussah.

Lehren für mittelständische IT-Verantwortliche

Lehre 1: Patch-SLAs unter sieben Tage werden Standard

Bisher galten in mittelständischen IT-Setups Patch-Zyklen von 30 bis 90 Tagen für Standard-Software als akzeptabel, mit Ausnahmen für kritische CVEs. Diese Norm hält die KI-Beschleunigung nicht aus. Wenn zwischen Disclosure und aktiver Ausnutzung 3 Stunden 44 Minuten liegen, ist ein 30-Tage-SLA praktisch ein „wir akzeptieren ein knappes Monatsfenster Angreifer-Vorteil".

Konkret: Patch-SLA für intern und extern erreichbare Kerndienste auf 7 Tage senken. Patch-SLA für kritische CVEs mit verfügbarem PoC auf 72 Stunden. Wer das organisatorisch nicht aufstellen kann, braucht entweder einen Managed-Service-Partner oder eine WAF mit aktivem Vendor-Feed.

Lehre 2: Configuration-as-Code ist keine Option mehr

Wer NGINX-Konfigurationen in der Hand pflegt, also nicht via Ansible, Puppet, Helm oder vergleichbarem Tool versioniert, hat beim NGINX-Rift-Workaround ein operatives Problem. Wie viele rewrite-Direktiven mit unbenannten Captures gibt es in den eigenen 40 NGINX-Instanzen? Niemand weiß es ohne grep-Audit. Bei Config-as-Code dauert das eine Stunde.

Das ist nicht spezifisch für NGINX. Es gilt für jede Komponente, die in einem Sicherheitsvorfall konfigurativ entschärft werden muss.

Lehre 3: Eigene KI-Audits sind heute günstiger als der erste Vorfall

Die genaue Frequenz, in der KI-Systeme Open-Source-Bugs aufdecken, wird sich beschleunigen. NGINX, Firefox, PraisonAI sind die ersten Stationen. Apache, OpenSSH, Postfix, MySQL und PostgreSQL sind im Wahrscheinlichkeitsfeld für die nächsten 12 Monate. Vermutlich auch SAP-NetWeaver-Komponenten, sobald jemand mit Mythos-Zugang den Anreiz hat.

Für mittelständische Unternehmen mit eigenem Custom-Code lohnt sich ein selbst initiiertes KI-Audit mit Claude Opus 4.6 oder vergleichbaren öffentlich verfügbaren Modellen. Konkretes Vorgehen habe ich im Mythos-Beitrag ausgearbeitet. Setup-Aufwand 3 bis 5 Tage, Lauf-Aufwand pro Modul ein paar Stunden, Kosten pro Token kalkulierbar.

Was NGINX Rift NICHT bedeutet

Vier Klarstellungen, weil die Story in den nächsten Tagen breiter zitiert werden wird.

Erstens: NGINX ist nicht „unsicher". Ein 18-Jahre-Bug in einer der am intensivsten geprüften Codebasen sagt etwas über die Grenzen menschlichen Reviews aus, nicht über die Qualität des Projekts. Vergleichbare Bugs gibt es vermutlich in jeder Codebasis dieser Größe.

Zweitens: Sie müssen NGINX nicht ersetzen. Patch oder Workaround sind die richtige Reaktion. NGINX bleibt für die meisten Mittelstands-Setups das passendste Frontend-Tool.

Drittens: Eine WAF allein reicht nicht. WAFs filtern Patterns, die Angreifer ändern können. Der saubere Fix ist Patch oder Konfigurations-Anpassung am NGINX selbst.

Viertens: Die Geschwindigkeit ist kein Sonderfall dieser Woche. Sie ist die neue Frequenz. Wer den Patch-Prozess nicht in den nächsten 60 Tagen so umstellt, dass 7-Tage-Reaktionen funktionieren, wird beim übernächsten ähnlich gelagerten Fund hinten anliegen.

Häufige Fragen zu NGINX Rift

Bin ich betroffen, wenn ich NGINX nur intern einsetze?

Vermutlich ja. Auch interne NGINX-Instanzen sind über das interne Netz erreichbar und damit aus jedem internen System angreifbar, das selbst kompromittiert wurde. Lateral-Movement nach einem Phishing-Treffer ist der typische Pfad. Internes NGINX gehört genauso in den Patch-Plan wie externes.

Reicht ein Update der Linux-Distribution?

In den meisten Fällen ja, sobald das jeweilige Distributions-Repository die gefixte Version übernommen hat. AlmaLinux hat schon am 13. Mai ein Update im Testing-Repository. Debian, RHEL, Ubuntu, SUSE folgen je nach Update-Policy in den nächsten Tagen. Wer Distro-Pakete nutzt, prüft den Distro-Tracker und stellt die unattended-upgrades oder dnf-automatic so ein, dass Security-Updates ohne manuelle Freigabe einlaufen.

Was, wenn ich F5 NGINX Plus mit kommerziellem Support nutze?

R32 P6 und R36 P4 sind die Patches. F5 stellt die Updates über das offizielle Customer Portal bereit. Support-Tickets zur Verifikation der eingesetzten Version sind über den Standardkanal anlegbar.

Soll ich den PoC selbst testen?

Nur in einer isolierten Testumgebung. Der PoC ist öffentlich, was bedeutet, dass auch andere ihn jetzt nachstellen. Eigenes Testen schadet nicht, ersetzt aber den Patch oder Workaround nicht.

Wie wahrscheinlich ist es, dass ich in den nächsten Wochen einen ähnlichen Fund sehe?

Sehr wahrscheinlich. depthfirst und vergleichbare Tooling-Anbieter haben gerade angefangen, populäre Open-Source-Projekte mit KI-Systemen zu auditieren. Apache HTTP Server, OpenSSH und gängige Datenbank-Server stehen mutmaßlich in den nächsten Disclosure-Pipelines. Wer einen 7-Tage-Patch-Prozess hat, ist vorbereitet. Wer 30 Tage Standard-SLA hat, wird unter Druck geraten.

Nächster Schritt

Sie betreiben NGINX als Reverse Proxy, API-Gateway oder Ingress, sind sich aber unsicher über Asset-Stand und Patch-Disziplin? Ich begleite mittelständische IT-Teams bei der Aufstellung eines pragmatischen Vulnerability- und Patch-Management-Prozesses, einschließlich Asset-Inventory, SLA-Definition und Anschluss an KI-gestützte Audits.

→ Kostenloses Erstgespräch buchen

→ Oder vorher weiterlesen: Glasswing-Asymmetrie: Mythos und der Mittelstand · PocketOS Database-Wipe · Chipotle Pepper Chatbot · IT-Strategie und Systemauswahl · KI- und Automatisierungsberatung

Quellen und weiterführende Links: The Hacker News: 18-Year-Old NGINX Rewrite Module Flaw Enables Unauthenticated RCE · Security Affairs: NGINX Rift, an 18-year-old flaw in the world’s most deployed web server · Picus Security: NGINX Rift CVE-2026-42945 Critical Heap Buffer Overflow Explained · SOC Prime: CVE-2026-42945 Critical NGINX Rewrite Flaw · AlmaLinux: NGINX Rift Patched in testing · NVD: CVE-2026-42945 Detail