Neues NGINX-Sicherheitsloch ermöglicht Angreifern Fernauslösung bösartiger Code

Wenn ein Location dann eine NJS-Funktion aufruft, die ngx.fetch() verwendet, können Angreifer speziell gestaltete HTTP-Anfragen senden, die zu einem heap-basierten Pufferüberlauf im NGINX-Worker-Prozess führen.

NGINX-Pufferüberlauf-Schwachstelle Die Schwachstelle wird als CWE-122: Heap-basierter Pufferüberlauf klassifiziert und wird intern von F5 unter der ID 160 für NGINX Plus und NGINX OSS verfolgt.

Dieser Fehler führt primär Abstürzen der Worker-Prozesse und deren automatischen Neustarts, was im NGINX-Datenplan effektiv einen Denial-of-Service (DoS)-Zustand erzeugt.

Sicherheitslage und Risiko

Auf Systemen, bei denen die Address Space Layout Randomization (ASLR) deaktiviert ist oder fehlerhaft konfiguriert wurde, kann das Überlaufproblem ausgenutzt werden, um beliebigen Code Worker-Kontext auszuführen. Die Schwachstelle betrifft NGINX JavaScript (njs)-Versionen 0.9.4 bis 0.9.8; die Behebung wurde in njs 0.9.9 eingeführt.

Betroffen ist das ngx_http_js_module-Modul, das NJS-basierte HTTP-Verarbeitungsrichtlinien wie js_content und js_fetch_proxy bereitstellt.

Ein typisches verwundbares Muster ist eine Konfiguration, bei der js_fetch_proxy eine Proxy-URL unter Verwendung erstellt, beispielsweise $http_x_user und $http_x_password, und js_content auf eine NJS-Funktion (beispielsweise main.fetcher) verweist, die ngx.fetch() mit dieser URL aufruft.

Technischer Hintergrund

In dieser Konfiguration kann ein Angreifer diese Header-Werte manipulieren, um den Heap-Speicher in einem NGINX-Worker zu beschädigen und diesen wiederholt abstürzen zu lassen. F5 gab Artikel K000161307 an, dass das Problem auf die Datenebene beschränkt ist und die Steuerungsplane nicht betrifft.

Andere F5-Produkte und -Dienste, wie BIG‑IP, BIG‑IQ, BIG‑IP Next, F5OS und F5 Distributed Cloud-Dienste, werden in ihren evaluierten Versionen als nicht anfällig für CVE‑2026‑8711 gemeldet. Administratoren, die, werden dringend aufgefordert, auf NGINX JavaScript 0.9.9 oder eine neuere Version zu aktualisieren, da dies die primäre Gegenmaßnahme darstellt.

Umgebungen, auf die die Spalte „Versions known to be vulnerable" zutrifft, sollten auf eine Version wechseln, die in der Spalte „Fixes introduced in" oder einer späteren Version aufgeführt ist.

Wenn eine sofortige Aktualisierung nicht möglich

Wenn eine sofortige Aktualisierung nicht möglich ist, sollten Betreiber die Konfigurationen auf den Einsatz von js_fetch_proxy mit clientgesteuerten Variablen überprüfen, diese Muster umgestalten oder entfernen, und sicherstellen, dass ASLR auf allen NGINX-Hosts aktiviert ist, Code-Ausführungsversuche zu erschweren.

Abi ist Sicherheitsredakteurin und Reporterin bei