needhelp
← Zurück zum Blog

NGINX Rift (CVE-2026-42945): Ein 18 Jahre alter Heap-Overflow im Rewrite-Modul

von xingwangzhe
NGINX
CVE
Sicherheit
RCE
Heap-Overflow
Web-Server

NGINX Rift (CVE-2026-42945, CVSS 9.2): Ein kritischer Heap-Buffer-Overflow im Rewrite-Modul von NGINX, autonom entdeckt vom KI-Analysesystem von depthfirst. Eingeführt im Jahr 2008 und 18 Jahre NGINX-Release betreffend, ermöglicht es einem nicht authentifizierten Angreifer, mit einer einzigen präparierten HTTP-Anfrage Remote-Codeausführung zu erreichen.

Die Schwachstelle, Die Sich Versteckt Hat

Am 13. Mai 2026 haben F5 und depthfirst gemeinsam CVE-2026-42945 offengelegt — einen kritischen Heap-Buffer-Overflow im ngx_http_rewrite_module von NGINX. Die Schwachstelle befand sich seit 2008 im Codebestand, eingeführt in NGINX 0.6.27, und betraf jede nachfolgende Version bis 1.30.0.

Was diese Entdeckung besonders bemerkenswert macht, ist die Art und Weise, wie sie gefunden wurde: nicht durch einen menschlichen Forscher, der manuell Code prüfte, sondern durch das autonome Schwachstellenanalysesystem von depthfirst. Das KI-System wurde auf den NGINX-Quellcode gerichtet und innerhalb von sechs Stunden markierte es den Heap-Overflow, der der menschlichen Erkennung 18 Jahre lang entgangen war.

MetrikWert
CVECVE-2026-42945
CVSS v4.09.2 (Kritisch)
Entdeckt vondepthfirst (autonome KI-Analyse)
Eingeführt2008 (NGINX 0.6.27)
Verborgen seit18 Jahren
SchwachstellentypHeap-Buffer-Overflow (Zwei-Pass-Längenkonflikt)
Authentifizierung erforderlichKeine
AuswirkungRemote-Codeausführung (RCE) oder Worker-Absturz (DoS)
Behobene VersionNGINX 1.31.0 / 1.30.1

Betroffene Versionen

Die Schwachstelle betrifft nahezu jede NGINX-Produktlinie:

ProduktBetroffene Versionen
NGINX Open Source0.6.27 bis 1.30.0
NGINX PlusR32 bis R36
NGINX Instance Manager2.16.0 bis 2.21.1
F5 NGINX App Protect WAF4.9.0–4.16.0, 5.1.0–5.8.0
NGINX Ingress Controller3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1
NGINX Gateway Fabric1.3.0–1.6.2, 2.0.0–2.5.1

Da NGINX etwa ein Drittel aller Websites weltweit betreibt, ist der Explosionsradius dieser Schwachstelle enorm.

Technischer Tiefgang

Das Zwei-Pass-Design

Um den Fehler zu verstehen, müssen Sie die Skript-Engine von NGINX verstehen. Wenn NGINX eine rewrite- oder set-Direktive auswertet, arbeitet es in zwei Durchläufen:

  1. Längendurchlauf (ngx_http_script_len_code): Berechnet die gesamte Puffergröße, die benötigt wird, um die endgültige Ausgabe aufzunehmen
  2. Kopierdurchlauf (ngx_http_script_run / ngx_http_script_copy_code): Allokiert einen Puffer dieser Größe und schreibt die tatsächlichen Daten

Der Vertrag ist einfach: Durchlauf 1 sagt Ihnen genau, wie viele Bytes zu allokieren sind, Durchlauf 2 schreibt genau diese Anzahl von Bytes. Wenn die beiden nicht übereinstimmen — erhalten Sie einen Heap-Overflow.

Grundursache: Das Verwaiste is_args-Flag

Die Schwachstelle lebt in src/http/ngx_http_script.c. Wenn der Ersetzungsstring einer rewrite-Direktive ein Fragezeichen (?) enthält, setzt die Funktion ngx_http_script_start_args_code ein Flag in der Skript-Engine:

e->is_args = 1;

Dieses Flag signalisiert, dass nachfolgende URI-Komponenten als Query-Argumente behandelt und URI-escaped werden sollen (z.B. + → %2B, & → %26).

Das Problem: Dieses Flag wird nie zurückgesetzt. Es bleibt für den Rest der Anfrageverarbeitung auf der Haupt-Skript-Engine (e) gesetzt.

Die Diskrepanz

Wenn eine nachfolgende set-Direktive eine Regex-Erfassungsgruppe (z.B. $1) referenziert, wertet die Skript-Engine sie aus. Während des Längendurchlaufs erstellt ngx_http_script_complex_value_code eine frische, genullte Sub-Engine (le):

ngx_http_script_len_code_ctx_t  le;
ngx_memzero(&le, sizeof(ngx_http_script_len_code_ctx_t));

Da le.ip und le.is_args beide null sind, nimmt die Längenberechnungsfunktion ngx_http_script_copy_capture_len_code den else-Zweig — sie gibt die rohe, nicht escaped Erfassungslänge zurück.

Während des Kopierdurchlaufs wird der Code auf der Haupt-Engine (e) ausgeführt, wo e->is_args immer noch 1 ist. Die Kopierfunktion ngx_http_script_copy_capture_code tritt in einen anderen Zweig ein:

if (e->is_args) {
    // Escaped die URI: expandiert + % & von 1 Byte auf 3 Bytes
    n = ngx_escape_uri(NULL, src, len, NGX_ESCAPE_ARGS);
    // ...allokiert und schreibt die escaped Version
}

Jedes escapable Zeichen in der vom Angreifer kontrollierten URI (+, %, &) expandiert von 1 Byte auf 3 Bytes. Der Puffer wurde für die rohe (nicht escaped) Länge dimensioniert — der Schreibvorgang überschreitet die Allokation.

// Längendurchlauf misst:   raw_len Bytes
// Kopierdurchlauf schreibt: raw_len + 2*N Bytes  (N = escapable Zeichen)
//                            ↑↑↑  HEAP-OVERFLOW

Dies ist eine klassische Zwei-Pass-Vertragsverletzung, ermöglicht dadurch, dass der is_args-Zustand von einer völlig unrelated rewrite-Direktive gesetzt und nie bereinigt wurde.

Ausnutzung

Die Forscher von depthfirst entwickelten einen funktionierenden Proof-of-Concept, der nicht authentifizierte RCE gegen NGINX mit deaktiviertem ASLR demonstriert. Die Schlüsseleigenschaften, die die Ausnutzung praktikabel machen:

EigenschaftDetail
Overflow-GrößeVom Angreifer vollständig kontrollierbar (Anzahl von +, &, % in URI)
Overflow-DatenVom Angreifer kontrolliert (escaped URI-Inhalt)
ReproduzierbarkeitDeterministisch — dieselbe Anfrage overflowt immer auf dieselbe Weise
WiederholungsbudgetUnendlich — abgestürzte Worker werden mit identischem Heap-Layout neu erstellt
AuthentifizierungKeine erforderlich — vom öffentlichen Internet erreichbar

Das unendliche Wiederholungsbudget ist besonders wichtig für die ASLR-Umgehung. Moderne Ausnutzung gegen ASLR erfordert typischerweise Informationsleckage oder Brute-Force. Da NGINX nach jedem Absturz Ersatz-Worker mit identischem Heap-Layout erzeugt, kann ein Angreifer unbegrenzte Versuche ohne Kosten unternehmen.

Die Forscher beschreiben eine theoretische Technik: Durch schrittweises Überschreiben von Pointer-Bytes über wiederholte Anfragen hinweg kann ein Angreifer den Ausführungsfluss zu einer kontrollierten Nutzlast umleiten und ASLR ohne expliziten Informationsleckage-Schritt besiegen.

Auslösebedingung: Sind Sie Betroffen?

Die Schwachstelle ist nur erreichbar, wenn Ihre NGINX-Konfiguration ein bestimmtes Muster enthält:

# Anfälliges Muster:
# 1. Ein rewrite mit ? im Ersatz UND unbenannten Erfassungsgruppen
# 2. Gefolgt von einem weiteren rewrite, if oder set im selben Gültigkeitsbereich

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

Das ? in /profile.php?id=$1&tab=$2 setzt is_args = 1. Die unbenannten Erfassungen $1, $2 lösen den anfälligen Codepfad aus, wenn eine nachfolgende Direktive sie auswertet.

Überprüfen Sie Ihre Konfiguration

grep -rn 'rewrite.*\?.*\$[0-9]' /etc/nginx/

Wenn dies Übereinstimmungen liefert, ist Ihre Konfiguration betroffen.

Minderung

Sofort: Aktualisieren

VersionAktion
NGINX Open SourceAktualisieren auf 1.31.0 oder 1.30.1
NGINX Plus R36R36 P4 anwenden
NGINX Plus R32R32 P6 anwenden

Workaround: Benannte Erfassungsgruppen

Wenn Sie nicht sofort aktualisieren können, ersetzen Sie unbenannte Erfassungen durch benannte Erfassungen in jeder betroffenen rewrite-Direktive:

# Anfällig — unbenannte Erfassungen mit ? im Ersatz
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# Gemindert — benannte Erfassungen umgehen den anfälligen Codepfad
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

Benannte Erfassungen ((?<name>...)) durchlaufen nicht die anfällige Escaping-Logik, da die Funktion ngx_http_script_copy_capture_code URI-Escaping nur auf unbenannte Erfassungen anwendet. Diese Konfigurationsänderung entfernt die Angriffsfläche ohne ein binäres Update.

Überprüfen Sie die Korrektur

# Version prüfen
nginx -v

# Nach dem Upgrade prüfen: sollte 1.31.0 oder 1.30.1+ sein
nginx -v 2>&1 | grep -E '1\.31\.0|1\.30\.[1-9]'

Zeitleiste

DatumEreignis
2008Schwachstelle in NGINX 0.6.27 eingeführt (Commit zur Initialisierung des Rewrite-Moduls)
2026-04depthfirst autonomes System scannt NGINX-Quellcode, markiert Heap-Overflow innerhalb von 6 Stunden
2026-04-24F5 bestätigt das Problem und koordiniert die Offenlegung
2026-05-13F5 veröffentlicht NGINX 1.31.0 / 1.30.1 mit Korrektur; CVE-2026-42945 veröffentlicht
2026-05-14Dieser Artikel veröffentlicht

Breitere Auswirkungen: KI-entdeckte Schwachstellen

CVE-2026-42945 ist nicht nur aufgrund seiner Schwere bemerkenswert, sondern auch wegen der Art und Weise, wie es entdeckt wurde. Ein autonomes KI-System fand einen Fehler in einem Codebestand, der von Tausenden von Ingenieuren, Sicherheitsforschern und Open-Source-Mitwirkenden über 18 Jahre auditiert wurde — in sechs Stunden.

Dies folgt einem Muster, das sich 2026 beschleunigt hat:

SchwachstelleEntdeckt vonZeit bis zur Entdeckung
Copy Fail (Linux-Kernel LPE)Xint Code (KI)~1 Stunde
Dirty Frag (Linux-Kernel LPE)Mensch (Hyunwoo Kim)Manuelle Prüfung
CVE-2026-42945 (NGINX Rift)depthfirst (autonome KI)6 Stunden
CVE-2026-42946 (NGINX Überlesen)depthfirst (autonome KI)Gleicher Scan

Die Kluft zwischen dem, was ein entschlossenes KI-System finden kann, und dem, was menschliche Prüfer historisch erfasst haben, wächst rapide. Für Betreiber kritischer Infrastruktur bedeutet dies:

  1. Gehen Sie davon aus, dass es mehr unentdeckte Fehler gibt in Ihren Abhängigkeiten — die bisher gefundenen sind nur das, was die aktuelle Generation von KI-Tools erfassen kann
  2. Minimieren Sie die Angriffsfläche — entfernen Sie ungenutzte Module, deaktivieren Sie unnötige Funktionen, verwenden Sie das Prinzip der geringsten Funktionalität
  3. Verteidigung in der Tiefe — selbst wenn eine Komponente kompromittiert wird, sollten andere Schichten den Explosionsradius begrenzen

NGINX selbst ist ein interessanter Fall: Es ist bekannt für seinen sauberen Codebestand und seine starke Sicherheitsbilanz. Und dennoch versteckte sich eine 18 Jahre alte kritische RCE in aller Offenheit. Wenn NGINX nicht sicher vor dieser Art von Fehler ist, ist es kein C-Codebestand.

Fazit

CVE-2026-42945 (NGINX Rift) ist ein kritischer Heap-Overflow in einem der am weitesten verbreiteten Softwareprojekte im Internet. Es erfordert keine Authentifizierung, kann vom öffentlichen Internet aus ausgelöst werden und gibt einem Angreifer vollständige Codeausführung im NGINX-Worker-Prozess.

Wenn Sie NGINX betreiben, gehen Sie davon aus, dass Sie betroffen sind — es sei denn, Sie haben überprüft, dass Ihre Konfiguration nicht das anfällige Rewrite-Muster enthält, oder Sie haben auf 1.31.0 / 1.30.1 aktualisiert.

Die 18-jährige Lebensdauer dieses Fehlers ist eine eindringliche Erinnerung: Unsere Infrastruktur wird von Code zusammengehalten, der noch nie umfassend von modernen Werkzeugen auditiert wurde. Das KI-Zeitalter der Schwachstellenentdeckung hat gerade erst begonnen, und wir sollten mit mehr Enthüllungen wie dieser rechnen — nicht mit weniger.

Referenzen

Infografik

NGINX Rift Heap-Overflow-Diagramm

Abbildung 1: NGINX Rift — wie die Zwei-Pass-Pufferlängendiskrepanz einen Heap-Overflow erzeugt

Diese Seite teilen