Deutsch

← Zurück zur Liste

Nginx-Sicherheitslücke CVE-2026-42945, 18 Jahre unentdeckt: Funktionsweise, PoC und Behebung im Detail

itadol5j

Nginx CVE-2026-42945

🚨 Kritische Sicherheitslücke in Nginx, 18 Jahre unentdeckt: CVE-2026-42945 – Funktionsweise, PoC und Behebung

Am 13. Mai 2026 hat das Sicherheitsforschungsinstitutdepthfirstgemeinsam mit F5 eine der schwerwiegendsten Sicherheitslücken in der Geschichte von NGINX offengelegt –CVE-2026-42945:

  • CVSS v4.0 Score 9.2: als kritische Schwachstelle eingestuft
  • Heap-Pufferüberlauf: kann zur Remotecodeausführung (RCE) führen
  • 18 Jahre unentdeckt: seit 2008 im Codebestand
  • betrifft 9,75 Millionen Websites weltweit: über 2,54 Millionen Websites in China betroffen
  • PoC veröffentlicht: von Qianxin erfolgreich reproduziert

Es handelt sich um eine historische Schwachstelle imNGINX-Kernmodul: Angreifer benötigen nur einen einzigen speziell präparierten HTTP-Request, um einen Server aus der Ferne zu übernehmen.

🔍 Überblick über die Schwachstelle

Grundlegende Informationen

Eigenschaft Details
Schwachstellen-ID CVE-2026-42945
CVSS-Score v4.0: 9.2 | v3.1: 8.1
Schwachstellentyp Heap-basierter Pufferüberlauf (Heap-based Buffer Overflow)
Bedrohungstyp Remotecodeausführung (RCE), Denial of Service (DoS)
Ausnutzungsvoraussetzungen Keine Authentifizierung erforderlich, nur ein präparierter HTTP-Request
Betroffene Komponente ngx_http_rewrite_module (in den NGINX-Kern integriertes Modul)
Entdeckt von depthfirst (automatisiertes System fand sie binnen 6 Stunden)

Auswirkungen

  • 9,75 Millionen Websites weltweitbetroffen
  • 2,54 Millionen Websites in Chinabetroffen
  • NGINX betreibt rund 1/3 aller Websites weltweit, die Auswirkungen sind enorm
  • Der Code wurde2008eingefügt und blieb18 Jahre lang unentdeckt

⚠️ Auslösebedingungen

Alle drei Bedingungen müssen gleichzeitig erfüllt sein

Zum Auslösen der Schwachstelle mussdie Konfiguration eine bestimmte Kombination von Bedingungen erfüllen:

Bedingung Beschreibung Beispiel
1. Unbenannte PCRE-Captures Die rewrite-Direktive verwendet unbenannte Capture-Gruppen $1, $2, $3…
2. Ersetzungszeichenkette enthält Fragezeichen Die Ersetzungszeichenkette enthält das Zeichen ? /profile.php?id=$1&tab=$2
3. Gefolgt von rewrite/if/set Auf die rewrite-Direktive folgt unmittelbar eine weitere Direktive rewrite … last; if (…) { … }

Anfälliges Beispiel

# 易受攻击配置
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
# 后跟其他指令
if ($arg_debug) {
    set $debug_flag 1;
}

Diese Konfiguration erfüllt alle drei Bedingungen gleichzeitig:unbenannte Captures $1/$2, Ersetzungszeichenkette mit ?, gefolgt von einer if-Direktive.

🔬 Technische Funktionsweise

Inkonsistenter Zustand bei der zweiphasigen Verarbeitung

Die Skript-Engine von NGINXarbeitet zweiphasig:

  • Phase 1: Berechnung der benötigten Puffergröße
  • Phase 2: Kopieren der Daten in den Puffer

Der Kern der Schwachstelle liegt ineinem Fehler bei der Verwaltung des is_args-Flags:

Phase is_args-Status Verarbeitungslogik Ergebnis
Längenberechnungsphase is_args = 0 gibt die ursprüngliche Capture-Länge zurück Puffergröße wird unterschätzt
Datenkopierphase is_args = 1 ruft ngx_escape_uri auf, jedes Byte wird auf 3 Bytes erweitert Heap-Pufferüberlauf

Detaillierter Ablauf

  1. rewrite-Direktiveenthält unbenannte Captures $1/$2
  2. Ersetzungszeichenketteenthält ?, wodurch is_args = 1 ausgelöst wird
  3. Längenberechnungsphase: nutzt eine neu initialisierte Sub-Engine, is_args = 0
  4. gibt die ursprüngliche Länge zurück: es wird ein zu kleiner Heap-Puffer allokiert
  5. Datenkopierphase: nutzt die Haupt-Engine, is_args = 1
  6. Aufruf von ngx_escape_uri: Bytes werden erweitert, der Puffer läuft über
  7. Angreiferkontrollierte URI-Datenwerden in den Überlaufbereich geschrieben

Ausnutzungsmethode

Heap Feng Shui über mehrere Requests hinweg:

  • POST-Request-Bodyzum Spraying des Heap-Speichers (da eine URI keine Null-Bytes enthalten darf)
  • Überlaufdatenbeschädigen den cleanup-Zeiger eines benachbarten ngx_pool_t
  • ein gefälschtes ngx_pool_cleanup_s, das auf system() zeigt
  • Beim Zerstören des Poolswird der system()-Aufruf ausgelöst
  • und RCE erreicht

Auswirkungen von ASLR

  • ASLR aktiviert: führt lediglich zum Absturz von Worker-Prozessen (DoS)
  • ASLR deaktiviert: Remotecodeausführung (RCE) ist möglich

📊 Betroffene Versionen

NGINX Open Source

Versionsbereich Behobene Version
0.6.27 – 1.30.0 1.31.0, 1.30.1

NGINX Plus

Versionsbereich Behobene Version
R32 – R36 R36 P4, R35 P2, R32 P6

Weitere betroffene Komponenten

  • NGINX Instance Manager: 2.16.0 – 2.21.1
  • NGINX App Protect WAF: 4.9.0 – 5.8.0
  • NGINX Ingress Controller: 3.5.0 – 5.4.1
  • NGINX Gateway Fabric: 1.3.0 – 2.5.1
  • F5 DoS for NGINX: 4.8.0

🔥 PoC-Status

PoC ist öffentlich verfügbar

  • GitHub-Repository:https://github.com/DepthFirstDisclosures/Nginx-Rift
  • Von Qianxin reproduziert: Sicherheitsforscher des Threat-Intelligence-Zentrums haben sie erfolgreich reproduziert
  • Technische Details veröffentlicht: depthfirst hat eine technische Analyse veröffentlicht
  • Ausnutzung in freier Wildbahn: bislang nicht beobachtet

Verwendung des PoC

# 构建容器
./setup.sh

# 启动易受攻击的 NGINX 服务器
docker compose -f env/docker-compose.yml up

# 执行 PoC 获取 Shell
python3 poc.py --shell

✅ Behebung

Methode 1: Version aktualisieren

# 升级到修复版本
NGINX Open Source >= 1.31.0
NGINX Open Source >= 1.30.1
NGINX Plus >= R32 P6
NGINX Plus >= R36 P4

# 升级后重启 NGINX
nginx -s reload

Methode 2: Konfiguration anpassen (Minderungsmaßnahme)

Ersetzen Sieunbenannte Capture-Gruppendurchbenannte Capture-Gruppen:

# 易受攻击配置（未命名捕获）
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# 修复后配置（命名捕获）
rewrite ^/users/(?[0-9]+)/profile/(?.*)$ /profile.php?id=$user_id&tab=$section last;

Benannte Capture-Gruppenlösen die Schwachstelle nicht aus.

Methode 3: Konfiguration prüfen

Prüfen Sie, ob anfällige Konfigurationen vorhanden sind:

# 搜索易受攻击的 rewrite 指令
grep -E "rewrite.*\$[0-9]+.*\?.*(rewrite|if|set)" /etc/nginx/nginx.conf
grep -rE "rewrite.*\$[0-9]+.*\?.*(rewrite|if|set)" /etc/nginx/conf.d/

🔍 Entdeckungsgeschichte

Entdeckt durch ein automatisiertes System

depthfirst– das Sicherheitsanalyssystem:

  • binnen 6 Stunden5 Probleme gefunden
  • 4 von NGINX bestätigt
  • CVE-2026-42945ist die schwerwiegendste Schwachstelle
  • lässt sich bis 2008 zurückverfolgen und existiert in praktisch allen Standard-Builds

Weitere verwandte Schwachstellen

  • CVE-2026-42946: Speicherkorruption
  • CVE-2026-40701: Speicherkorruption
  • CVE-2026-42934: Speicherkorruption

📝 Fazit

CVE-2026-42945ist eine der schwerwiegendsten Schwachstellen in der Geschichte von NGINX:

  • 18 Jahre unentdeckt: seit 2008 im Codebestand
  • CVSS 9.2: Heap-Pufferüberlauf, kann zu RCE führen
  • Auslösebedingungen: rewrite-Direktive mit unbenannten Captures + Ersetzungszeichenkette mit ? + darauffolgende weitere Direktive
  • Auswirkungen: 9,75 Millionen Websites weltweit, 2,54 Millionen in China
  • PoC öffentlich: GitHub-Repository + von Qianxin reproduziert
  • Behebung: Version aktualisieren oder benannte Capture-Gruppen verwenden

Nach 18 Jahren ist die Schwachstelle nun ausgebrochen – ein baldiges Update oder eine Konfigurationsanpassung wird dringend empfohlen.

Offizielle Ankündigung:https://my.f5.com/manage/s/article/K000161019

PoC-Repository:https://github.com/DepthFirstDisclosures/Nginx-Rift

Technische Analyse:https://depthfirst.com/research/nginx-rift