Die kritische Schwachstelle CVE-2026-42945 in NGINX Plus und NGINX Open, die einen Denial-of-Service oder unter bestimmten Bedingungen die Ausführung beliebigen Codes ermöglicht, wird nach Angaben von VulnCheck bereits von Angreifern ausgenutzt — nur wenige Tage nach der öffentlichen Offenlegung. Parallel dazu wurden Angriffe auf drei kritische Schwachstellen in openDCIM beobachtet, die zu einer Kette kombiniert werden, um Remote Code Execution zu erreichen. Organisationen, die diese Produkte einsetzen, müssen ihre Exponiertheit umgehend bewerten und verfügbare Patches anwenden.

CVE-2026-42945: heap buffer overflow in NGINX

Die Schwachstelle CVE-2026-42945 stellt einen heap buffer overflow im Modul ngx_http_rewrite_module dar. Betroffen sind den Angaben zufolge NGINX-Versionen von 0.6.27 bis 1.30.0. Bei erfolgreicher Ausnutzung kann ein nicht authentifizierter Angreifer mit speziell präparierten HTTP-Requests das Abstürzen von Worker-Prozessen auslösen, was zu einem Denial-of-Service führt.

Die Möglichkeit von Remote Code Execution (RCE) besteht, erfordert jedoch das gleichzeitige Erfüllen mehrerer Bedingungen. Sicherheitsforscher Kevin Beaumont merkte an, dass für die Ausnutzung eine bestimmte NGINX-Konfiguration nötig ist, die der Angreifer kennen oder herausfinden muss, und dass für das Erreichen von RCE auf dem Zielsystem die Address Space Layout Randomization (ASLR) deaktiviert sein muss.

Realistische Einschätzung der Bedrohung

Die Maintainer von AlmaLinux haben in ihrer Analyse eine abgewogene Einschätzung vorgelegt: Die Umwandlung eines heap buffer overflow in eine verlässliche Codeausführung ist in einer Standardkonfiguration nicht trivial, und auf Systemen mit aktivierter ASLR (was in allen unterstützten AlmaLinux-Releases die Standardeinstellung ist) erscheint die Entwicklung eines universellen und robusten Exploits äußerst schwierig. Dennoch, so betonen die Maintainer, bedeutet „nicht trivial“ nicht „unmöglich“, und bereits das Denial-of-Service-Szenario durch Abstürze der Worker-Prozesse ist realistisch genug, um diese Schwachstelle als dringend zu behandeln.

Diese Einschätzung ist entscheidend für die richtige Priorisierung. Organisationen, bei denen ASLR aus irgendwelchen Gründen deaktiviert ist (veraltete Systeme, spezielle Kompatibilitätsanforderungen), befinden sich in einer deutlich höheren Risikozone. Für alle anderen ist die Hauptbedrohung ein DoS-Angriff, der dennoch erheblichen Schaden anrichten kann, wenn NGINX als Reverse Proxy oder Load Balancer vor kritischen Services eingesetzt wird.

Laut VulnCheck wurden Exploit-Versuche bereits in ihrem Honeypot-Netzwerk registriert. Ziele und genauer Charakter der Angriffsaktivitäten sind derzeit noch nicht bekannt.

openDCIM-Schwachstellenkette: von SQL injection bis Reverse Shell

Parallel dazu berichtete VulnCheck von der Ausnutzung zweier kritischer Schwachstellen in openDCIM — einer Open-Source-Anwendung für das Management der Infrastruktur von Rechenzentren:

• CVE-2026-28515 (CVSS 9.3) — fehlende Autorisierungsprüfung, die es einem authentifizierten Benutzer ermöglicht, unabhängig von seinen zugewiesenen Rechten auf die LDAP-Konfigurationsfunktionalität zuzugreifen. In Docker-Deployments, in denen die Variable REMOTE_USER ohne erzwungene Authentifizierung gesetzt ist, kann der Endpunkt ohne Zugangsdaten erreichbar sein, was unbefugte Änderungen an der Applikationskonfiguration ermöglicht.
• CVE-2026-28517 (CVSS 9.3) — OS command injection in der Komponente report_network_map.php. Der Parameter dot wird ohne Sanitization an einen Shell-Befehl übergeben, was zur Ausführung beliebigen Codes führt.
• CVE-2026-28516 (CVSS 9.3) — SQL injection in openDCIM.

Alle drei Schwachstellen wurden im Februar 2026 vom VulnCheck-Sicherheitsforscher Valentin Lobstein entdeckt. Seiner technischen Beschreibung zufolge können die drei Schwachstellen zu einer Kette kombiniert werden, um mit fünf HTTP-Requests Remote Code Execution zu erreichen und anschließend eine reverse shell zu starten. Dadurch lässt sich die Angriffskette praktisch vollständig automatisieren.

Bewertung der Auswirkungen

Das Ausmaß der potenziellen Auswirkungen der NGINX-Schwachstelle wird durch die allgegenwärtige Verbreitung dieses Webservers bestimmt: Er wird weltweit von Millionen von Websites und Services als Webserver, Reverse Proxy und Load Balancer eingesetzt. Selbst wenn das RCE-Szenario schwer zu erreichen ist, kann ein DoS-Angriff auf die NGINX-Worker-Prozesse zu kaskadierenden Ausfällen der dahinterliegenden Services führen. Besonders gefährdet sind Organisationen mit ungewöhnlichen Rewrite-Modul-Konfigurationen und veralteten Systemen ohne ASLR.

Für openDCIM konzentriert sich das Risiko auf den Bereich des Rechenzentrums-Managements. Die Kompromittierung eines Systems zur Verwaltung der Rechenzentrumsinfrastruktur kann einem Angreifer detaillierte Informationen über die physische und logische Netzwerktopologie, die Positionierung von Hardware und Konfigurationen liefern und damit eine Ausgangsbasis für weitere Angriffe auf kritische Infrastrukturen schaffen. Das Vorhandensein einer vollständig automatisierbaren Exploit-Kette aus drei Schwachstellen senkt die Einstiegshürde für Angreifer erheblich.

Empfehlungen zum Schutz

Für NGINX

• Installieren Sie die neuesten Updates von F5 für NGINX Plus und NGINX Open, die CVE-2026-42945 beheben.
• Stellen Sie sicher, dass ASLR auf allen Servern mit NGINX aktiviert ist — dies erschwert die Ausnutzung des RCE-Szenarios erheblich.
• Führen Sie ein Audit der Konfigurationen des ngx_http_rewrite_module durch — die Schwachstelle erfordert für die Ausnutzung eine bestimmte Konfiguration.
• Ziehen Sie die Implementierung von WAF-Regeln in Betracht, um ungewöhnlich aufgebaute HTTP-Requests zu erkennen, die auf das Rewrite-Modul abzielen.
• Überwachen Sie Abstürze von NGINX-Worker-Prozessen als potenziellen Indikator für Exploit-Versuche.

Für openDCIM

• Prüfen Sie, ob Updates für openDCIM verfügbar sind, die CVE-2026-28515, CVE-2026-28516 und CVE-2026-28517 beheben.
• Stellen Sie in Docker-Deployments sicher, dass die Variable REMOTE_USER nicht ohne einen geeigneten Authentifizierungsmechanismus gesetzt ist.
• Beschränken Sie den Netzwerkzugriff auf openDCIM — die Anwendung sollte nicht aus dem Internet erreichbar sein.
• Untersuchen Sie Server auf ungewöhnliche PHP-Dateien, bei denen es sich um Webshells handeln könnte, die im Zuge einer Kompromittierung platziert wurden.

Beide Gruppen von Schwachstellen erfordern eine sofortige Reaktion: Für NGINX haben die Aktualisierung und die Überprüfung der ASLR-Konfiguration Priorität, für openDCIM sind Aktualisierung und Abschottung gegenüber externem Zugriff vorrangig. Angesichts der bestätigten aktiven Ausnutzung beider Produkte und der Verfügbarkeit automatisierter Angriffswerkzeuge schrumpft das Zeitfenster für sicheres Patchen rapide.