Am Morgen des 13. Mai 2026 las Daniel Reinhardt, Geschaeftsfuehrer und gleichzeitig technischer Leiter der Mehring & Reinhardt Engineering GmbH – ein Sondermaschinenbauer mit 184 Mitarbeitern aus dem suedlichen Sauerland –, die taegliche Sicherheits-Zusammenfassung seines IT-Dienstleisters. Ein Eintrag stach heraus: "CVE-2026-42945 (NGINX Rift, CVSS 9.2): Unauthentisierte Remote Code Execution in allen NGINX-Versionen 0.6.27 bis 1.30.0, Proof-of-Concept auf GitHub, F5 hat 1.30.1 und 1.31.0 veroeffentlicht." Reinhardt brauchte einen Augenblick, bis er den Umfang erfasste: NGINX laeuft als Reverse Proxy vor jeder einzelnen seiner sechs auf Kubernetes betriebenen Industrie-Anwendungen, als Ingress Controller in zwei produktiven Clustern, als Web-Frontend des kundengerichteten Service-Portals und – das hatte er fast vergessen – als Anlage zur SSL-Terminierung vor der Telekommunikationsanlage. Insgesamt 47 NGINX-Instanzen in unterschiedlichen Versionen, gewachsen ueber sieben Jahre, dokumentiert in einem Confluence-Wiki, das niemand mehr aktuell pflegte. Eine Schwachstelle, die seit 2008 in nahezu jeder ausgelieferten NGINX-Version geschlummert hatte. Diese Geschichte – mit veraendertem Namen und leicht angepasstem Sachverhalt – steht stellvertretend fuer viele Mittelstaendler, die in diesen Tagen NGINX Rift in ihren Stack-Inventaren wiederfinden.

Was NGINX Rift technisch ist

Die Schwachstelle CVE-2026-42945 wurde am 13. Mai 2026 von Forschern des Projekts DepthFirst Disclosures in koordinierter Veroeffentlichung mit F5 publik gemacht. Der Name "NGINX Rift" – auf Deutsch: "Riss" – ist nicht zufaellig gewaehlt. Es handelt sich um einen Heap Buffer Overflow im ngx_http_rewrite_module, also genau in jenem Modul, das NGINX seit 18 Jahren fuer URL-Rewrites, Redirects und Pfad-Mapping einsetzt. Genau diese Funktionalitaet ist im Kerngeschaeft jedes mittelstaendischen Webhostings allgegenwaertig: Sie steht in jedem Wordpress-Setup, in jedem Magento-Shop, in jeder typischen ".htaccess-Migration nach NGINX", in jedem ingress-nginx Controller auf Kubernetes.

Der eigentliche Bug

Die technische Wurzel liegt in einer Inkonsistenz zwischen Berechnungs- und Kopierphase im Rewrite-Code. Konkret: NGINX setzt im Verlauf der Verarbeitung einer Rewrite-Direktive ein internes Flag is_args, das anzeigt, ob die generierte URL ein Query-String-Trennzeichen ("?") enthaelt. Dieses Flag dient eigentlich der korrekten URL-Escaping-Logik im Modul ngx_escape_uri. Der Fehler: Das Flag, das in der Laengenberechnungs-Phase gesetzt wird, "leakt" durch in die Kopier-Phase. Die Folge ist, dass ngx_escape_uri bei bestimmten Eingaben mehr Bytes in den Heap-Buffer schreibt, als urspruenglich allokiert wurden. Klassisches Heap Buffer Overflow.

Der Bug schlaegt unter drei kumulativen Bedingungen zu:

  1. Eine rewrite-Direktive wird gefolgt von einer weiteren rewrite-, if- oder set-Direktive im selben Server- oder Location-Block.
  2. Im Ersatzteil der Rewrite-Regel kommt ein unnamed PCRE capture ($1, $2 usw.) vor.
  3. Die Ersatzzeichenkette enthaelt ein Fragezeichen ("?").

Konfigurationen wie die folgende sind also verwundbar:

location /api/ {
  rewrite ^/api/users/([0-9]+)$ /backend/profile.php?id=$1 last;
  rewrite ^/api/orders/([0-9]+)$ /backend/order.php?id=$1 last;
}

Genau dieses Konstrukt findet sich in vielen kundengerichteten Portalen, Stripe-Webhook-Receivers, B2B-EDI-Endpunkten und Service-Backends im Mittelstand.

Vom DoS zur RCE

Wenn ein Angreifer einen HTTP-Request gegen einen Pfad sendet, der eine verwundbare Rewrite-Direktive ausloest, schreibt NGINX-Worker einige Bytes hinter den Heap-Buffer. Im einfachsten Fall fuehrt das zum Absturz des Worker-Prozesses – der Service-Manager startet den Worker neu, ein Denial-of-Service-Effekt entsteht. Wirklich kritisch wird es im fortgeschrittenen Szenario, das in der veroeffentlichten Proof-of-Concept aufgezeigt wird: Bei deaktiviertem ASLR (Address Space Layout Randomization) – ein in containerisierten Umgebungen leider haeufig anzutreffender Zustand – gelingt es, mit einer Folge praezise konstruierter Requests Heap-Strukturen so zu manipulieren, dass beliebiger Code im Worker-Kontext zur Ausfuehrung kommt. Das ist unauthentisierte Remote Code Execution, vorgenommen ueber ein einfaches HTTP-Paket, ohne dass der Angreifer auch nur ein Login-Formular sehen muesste.

Die Reichweite der Schwachstelle

NGINX ist nach den Auswertungen von Netcraft und W3Techs aktuell auf rund einem Drittel aller oeffentlich erreichbaren Webserver weltweit im Einsatz. Im Container-Oekosystem ist die Verbreitung noch hoeher: Das Projekt ingress-nginx, das in einem grossen Teil aller Kubernetes-Cluster den eingehenden HTTP-Verkehr terminiert, basiert auf demselben verwundbaren Code. F5 NGINX Plus R32 bis R36 ist ebenfalls verwundbar. Wer eines der gaengigen Reverse-Proxy-Setups betreibt – sei es ein "Standard"-NGINX vor einer Apache-Anwendung, ein Cloudflare-Hinter-NGINX-Setup oder einen ingress-nginx im AKS/EKS/GKE-Cluster –, hat mit hoher Wahrscheinlichkeit verwundbare Binaries im Betrieb.

Die Patches

F5 hat am 13. Mai 2026 die folgenden Versionen mit Fix veroeffentlicht:

  • NGINX Open Source 1.30.1 (Stable Branch)
  • NGINX Open Source 1.31.0 (Mainline Branch)
  • NGINX Plus R36 P4
  • NGINX Plus R32 P6 (Long-Term-Support-Branch)

Fuer ingress-nginx auf Kubernetes ist die Lage komplexer: Der Patch ist in den Controller-Images ab Tag v1.13.2 enthalten. Wer Helm-Charts einsetzt, sollte die zugehoerige Chart-Version mindestens 4.13.x verwenden. Auch hier gilt: Der NGINX-Build wird im jeweiligen Release-Note des Controllers dokumentiert; die Aktualisierung des Container-Image-Tags ist der einzige verlaessliche Weg, den Patch wirksam einzuspielen. Ein simples kubectl apply mit veraenderter Konfiguration genuegt nicht, wenn das zugrundeliegende Worker-Binary verwundbar bleibt.

Workaround statt Patch

Wer aus Wartungsfenster-Gruenden nicht sofort patchen kann, hat zumindest eine konfigurationsseitige Notbremse. F5 empfiehlt, in allen Rewrite-Direktiven unnamed captures durch named captures zu ersetzen. Die problematische Zeile

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

wird durch die folgende, semantisch identische Variante geheilt:

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

Diese Umstellung umgeht den fehlerhaften Code-Pfad, weil ngx_escape_uri bei named captures eine andere Behandlung erfaehrt, die das fehlerhafte Flag-Verhalten nicht ausloest. Wichtig: Das ist ein Workaround, kein Fix. Wer ihn umsetzt, vermeidet die akute Ausnutzbarkeit – muss aber dennoch den Patch zeitnah einspielen, weil der zugrundeliegende Heap-Bug im Binary bleibt.

User Story: 96 Stunden bei der Mehring & Reinhardt Engineering GmbH

Zurueck zu Daniel Reinhardt. Die Mehring & Reinhardt Engineering GmbH baut hochpraezise Sondermaschinen fuer die Lebensmittelverpackungs-Industrie, vorwiegend in der DACH-Region. Das Unternehmen hat sich in den letzten fuenf Jahren systematisch digitalisiert: Ein eigenes Kundenportal fuer Wartungsdokumentation, ein IoT-Backend fuer Ferndiagnose der ausgelieferten Maschinen, ein internes ERP mit Webanbindung, ein Office-365-Tenant mit Conditional Access. NGINX ist in allen Schichten praesent. Reinhardt hatte vor zwei Jahren entschieden, Kubernetes als Plattform fuer alle Eigenentwicklungen einzusetzen. Heute laufen zwei Cluster – ein OnPrem-Cluster im eigenen Rechenzentrum, ein Cloud-Cluster im Rechenzentrum der Deutschen Telekom.

Tag 1 – 13. Mai, 10:42 Uhr

Reinhardt ruft Mareike Kessler an, die zustaendige Cloud-Architektin im IT-Team. Innerhalb einer Stunde laeuft das erste Inventarisierungs-Skript. Das Ergebnis ist erst einmal ernuechternd: 47 NGINX-Instanzen, davon 6 als Ingress Controller, 18 als sidecar in Microservice-Pods, 11 in dedizierten VMs als Reverse Proxy vor Drittanwendungen, 12 als statische File-Server fuer interne Tools. Versionen reichen von 1.18 (in einem aelteren OnPrem-Setup) bis 1.29.4 (im aktuellsten Cluster-Stand). Alle 47 Instanzen sind potenziell verwundbar.

Tag 1 – 14:30 Uhr

Das Team trifft die erste Prioritaetsentscheidung: Die extern erreichbaren Endpunkte werden vorrangig adressiert. Das sind der Ingress Controller des kundengerichteten Portals (Cloud-Cluster), drei API-Gateways in der DMZ, sowie die SSL-Terminierung der internen VPN-Einwahl. Kessler erstellt eine Tabelle, in der jeder Instanz eine von vier Prioritaeten zugewiesen wird: P1 (extern erreichbar, hochsensible Daten), P2 (extern erreichbar, weniger sensibel), P3 (intern, aber kritische Funktion), P4 (intern, Standardfunktion). 8 von 47 Instanzen sind P1. Das ist die initiale Patch-Pflicht der naechsten 24 Stunden.

Tag 2 – 14. Mai, ab 06:00 Uhr

Fuer den extern erreichbaren Ingress Controller wird die Container-Image-Version von v1.12.4 auf v1.13.2 hochgezogen. In einer Staging-Replik wird der Tag vorher getestet – Rewrite-Regeln, TLS-Setup, Logging. Das Production-Update laeuft in einem Rolling-Restart der Controller-Pods, kein einziger der eingehenden Kundenrequests faellt aus. Mareike Kessler ist erleichtert: Der investierte Aufwand in eine saubere ingress-nginx-Architektur mit mehreren Controller-Replicas zahlt sich aus.

Die drei VM-basierten API-Gateways sind die unangenehmen Kandidaten. Sie laufen auf alten Debian-11-VMs mit selbst kompilierten NGINX-Builds aus der Zeit, als das Team noch keine Standardpakete vertraute. Eine Neukompilierung dauert pro VM rund zwei Stunden, das Hineinbringen der Binaries in die Wartungsroutine weitere eineinhalb. Bis 22:00 Uhr sind alle drei P1-VMs auf NGINX 1.30.1.

Tag 3 – 15. Mai

An Tag drei werden die P2-Instanzen abgearbeitet. Eine davon entpuppt sich als unerwartete Stolperfalle: Ein NGINX-Container in einem Legacy-Microservice greift auf eine spezifische 1.18er Konfiguration zurueck, in der eine if-Direktive mit unnamed capture eingesetzt wird, die unter NGINX 1.30+ deprecated ist. Das Team setzt den Workaround mit named captures ein, verifiziert das mit synthetischen Lasttests, und plant fuer die kommende Sprintwoche die saubere Migration auf eine zeitgemaesse Konfiguration. Pragmatismus statt Perfektionismus.

Tag 4 – 16. Mai

Die P3- und P4-Instanzen werden in einer geplanten Wartung am Samstag-Vormittag aktualisiert. Hier kann das Team ohne Zeitdruck arbeiten, weil die Instanzen nicht extern erreichbar sind. Bis 14:00 Uhr ist die gesamte NGINX-Population im Unternehmen auf einer Version >= 1.30.1 oder im genannten Workaround-Modus.

Was Reinhardt aus dem Vorfall mitnimmt

In der nachgelagerten Lessons-Learned-Runde der Mehring & Reinhardt Engineering GmbH werden drei Themen festgehalten:

  1. Die Inventarisierung war zu spaet. Es war reines Glueck, dass ein Skript die 47 Instanzen ueberhaupt fand. Eine kontinuierliche Software-Bill-of-Materials (SBOM) pro Umgebung haette die Zeit von der Disclosure bis zur ersten Triage von 90 Minuten auf etwa 10 Minuten gedrueckt.
  2. Selbst gebaute Pakete sind eine Patch-Hypothek. Die drei VMs mit selbstkompilierten NGINX-Builds waren der zeitaufwaendigste Anteil der Aktion. Das Team beschliesst, kuenftig nur noch Pakete aus dem F5-Repository oder offizielle Container-Images zu verwenden.
  3. Memory-safe Alternativen gehoeren in die Strategie. Fuer neue Mikroservices wird die Team-Architektin Hagen Lemke (Plattform-Engineering) ab Q3 2026 NGINX-Unit, Caddy und ggf. envoy als Optionen pruefen lassen. Die zugrundeliegende Frage – ist ein in C geschriebener Reverse Proxy aus 2008 noch zeitgemaess? – ist offen.

Reinhardt selbst sagt am Ende seiner Aufzeichnung dazu: "Wir hatten Glueck, dass keiner unserer Endpunkte in den 48 Stunden zwischen Disclosure und Patch aktiv ausgenutzt wurde. Beim naechsten Mal wollen wir das nicht mehr von Glueck abhaengig machen."

Breitere Einordnung: Memory Safety, Supply Chain und das Risiko der 18 Jahre alten Module

Die NGINX Rift Schwachstelle ist kein isoliertes Ereignis. Sie reiht sich in eine Folge von 2025 und 2026 dokumentierten Faellen ein, in denen lang etablierte Open-Source-Komponenten ploetzlich als kritische Schwachstellenquellen sichtbar werden: Die xz-utils-Backdoor 2024, das libcurl-Heap-Issue von Februar 2026, die OpenSSH-DoS-Schwachstellen vom April 2026. Das gemeinsame Muster: Code in C oder C++, der jahrzehntelang verlaesslich lief, enthaelt Memory-Safety-Bugs, die mit zunehmender Sophistikation der Angreifer-Tooling-Stacks – einschliesslich KI-gestuetzter Fuzzing-Pipelines – jetzt erkannt und ausgenutzt werden.

Fuer den deutschen Mittelstand ergeben sich daraus drei strategische Konsequenzen:

1. Software-Bill-of-Materials wird Pflicht – nicht nur regulatorisch

Mit dem Cyber Resilience Act, der ab September 2026 fuer Produkthersteller bindend wird, ist die SBOM-Pflicht zwar primaer fuer ausgelieferte Hardware-/Software-Produkte definiert. Aber: Jeder Mittelstaendler, der intern Software betreibt und in regulierten Lieferketten (Maschinenbau, Automotive, Pharma) operiert, wird in den naechsten 18 Monaten von Kunden und Versicherern dieselbe Transparenz einfordern. Wer im Juni 2026 nicht binnen einer Stunde sagen kann, in welchen Versionen welche NGINX-Builds laufen, wird in der Schadensregulierung schlechter dastehen.

2. Patch-Latenz ist die entscheidende KPI

Die durchschnittliche Zeit zwischen Veroeffentlichung einer kritischen Schwachstelle und der ersten beobachteten massenhaften Ausnutzung hat sich nach Daten des Mandiant M-Trends Reports 2026 auf 11 Tage reduziert (von 32 Tagen im Jahr 2022). Wer als Mittelstand mehr als 14 Tage fuer einen kritischen Patch braucht, ist statistisch zu spaet. Das setzt eine geprobte Patch-Routine, ein dediziertes Wartungsfenster pro Woche und ein dokumentiertes Eskalationsverfahren voraus.

3. Memory-safe Alternativen gehoeren in die Roadmap

Es waere unredlich, NGINX wegen einer Schwachstelle pauschal zu verteufeln. Aber im strategischen Horizont 2026 bis 2028 sollten IT-Leiter im Mittelstand ihre Reverse-Proxy-Strategie ueberpruefen. Caddy (in Go geschrieben, memory-safe), NGINX-Unit mit seinem moderneren Architekturansatz oder envoy in Cloud-Native-Setups sind reale Optionen. Wer heute eine neue Plattform aufbaut, muss nicht zwingend bei der C-basierten 2004er-Architektur landen.

Konkrete Handlungsempfehlungen fuer Ihr Setup

Innerhalb der naechsten 72 Stunden

  • Inventarisieren Sie alle NGINX-Instanzen in Ihrer Umgebung. Containerisierte Workloads, VM-basierte Reverse Proxies, Ingress Controller, Builds in Hardware-Appliances (manche Firewalls und Lastverteiler nutzen NGINX intern). Eine sauber gepflegte SBOM ist hier Gold wert.
  • Identifizieren Sie alle Instanzen, die extern erreichbar sind – das ist die Top-Prioritaet.
  • Pruefen Sie die NGINX-Versionen. Alles < 1.30.1 (Stable) oder < 1.31.0 (Mainline) ist verwundbar.
  • Wo ein Patch nicht binnen 24 Stunden moeglich ist: Setzen Sie den named capture-Workaround in allen relevanten Rewrite-Direktiven um.
  • Aktivieren Sie auf den Reverse-Proxy-Hosts ASLR (in Linux ueber kernel.randomize_va_space=2). Das erhoeht den Aufwand fuer eine erfolgreiche RCE erheblich, auch wenn es kein Patch ist.

Innerhalb der naechsten 14 Tage

  • Vollstaendiger Rollout der gepatchten Versionen auch fuer P3/P4-Instanzen.
  • Aktualisierung der Helm-Charts und Container-Image-Tags fuer alle Kubernetes-Cluster.
  • Verifikation der Logging-Konfiguration: Werden alle Worker-Restarts korrekt erfasst? Ein erhoehtes Crash-Aufkommen ist ein moeglicher Indikator fuer aktive Ausnutzungsversuche.
  • Pruefung der Web Application Firewall (WAF) auf die Verfuegbarkeit von Signaturen fuer NGINX-Rift-Exploitversuche. Cloudflare, Akamai und Imperva haben binnen 48 Stunden nach Disclosure Signaturen ausgespielt.

Strategisch in den naechsten 90 Tagen

  • Etablierung eines internen SBOM-Prozesses mit toolgestuetzter Erkennung (z. B. Anchore, Syft, Trivy in der CI/CD-Pipeline).
  • Festlegung einer organisationsweiten Patch-Latenz-KPI: Kritische Schwachstellen extern: max. 72 Stunden; kritische Schwachstellen intern: max. 7 Tage.
  • Pruefung der Reverse-Proxy-Strategie auf Diversifikation und memory-safe Alternativen.
  • Diese Themen sind Teil einer modernen Informationssicherheits-Architektur und gehoeren in die jaehrliche IT-Sicherheitsplanung – nicht in den nachtraeglichen Krisenmodus.

Ausblick: Was die naechsten Monate bringen werden

Die Veroeffentlichung des Proof-of-Concept auf GitHub und die zugehoerige Analyse-Literatur (DepthFirst, F5, SocRadar, Picus Security) haben das Feld der Ausnutzung weitgehend dokumentiert. Es ist davon auszugehen, dass automatisierte Scanner – wie sie etwa von Akira- und Sinobi-Affiliates eingesetzt werden – binnen weniger Wochen die noch verwundbaren NGINX-Endpunkte im Internet identifizieren und ausnutzen werden. Zugleich werden die Sicherheitsforscher von F5 und der Open-Source-Community den Code der Rewrite-Engine in den naechsten Monaten weiter pruefen. Es ist nicht unwahrscheinlich, dass weitere, verwandte Schwachstellen in NGINX in den kommenden Monaten ans Licht kommen.

Fuer den Mittelstand bedeutet das: Die Welle ist nicht mit dem Patch vom 13. Mai abgehakt. Sie ist eine Etappe in einem laengeren Prozess, der die Robustheit der eigenen Infrastruktur kontinuierlich auf die Probe stellt. Die Mehring & Reinhardt Engineering GmbH hat in 96 Stunden gepatcht. Sie kann das nur, weil sie eine kompetente Plattform-Engineering-Kapazitaet, eine geuebte Reaktionsroutine und eine Geschaeftsfuehrung hat, die Sicherheitsbudgets als Investition versteht. Mittelstaendler ohne diese Bausteine sollten die NGINX-Rift-Episode als Anlass nehmen, in den naechsten Monaten genau diese Faehigkeiten aufzubauen.

Wenn Sie Unterstuetzung bei der Inventarisierung, der Patch-Strategie oder dem Aufbau eines kontinuierlichen Vulnerability-Managements benoetigen, steht das Team von pleXtec Ihnen zur Verfuegung. Eine Uebersicht ueber unsere Leistungen finden Sie auf Leistungen, fuer projektspezifische Anfragen erreichen Sie uns ueber das Kontaktformular. Wenn Sie ueber das Patchen hinaus die strategische Architektur Ihrer Plattform-Engineering-Aufstellung neu denken wollen, sprechen wir gerne ueber Softwareentwicklung und Projektmanagement.