Polski

← Powrót do listy

Luka w Nginx ukryta od 18 lat — CVE-2026-42945: pełna analiza mechanizmu, PoC i sposobów naprawy

itadol5j

Nginx CVE-2026-42945

🚨 Groźna luka w Nginx ukryta od 18 lat — CVE-2026-42945: mechanizm, PoC i sposoby naprawy

13 maja 2026 roku firma badawcza zajmująca się bezpieczeństwem depthfirstwspólnie z F5 ujawniła najpoważniejszą w historii lukę NGINX —CVE-2026-42945:

  • 9,2 pkt w skali CVSS v4.0: to podatność o krytycznie wysokim stopniu zagrożenia
  • przepełnienie bufora na stercie: może prowadzić do zdalnego wykonania kodu (RCE)
  • ukryta przez 18 lat: obecna w kodzie od 2008 roku
  • dotyczy 9,75 mln witryn na świecie: ponad 2,54 mln witryn w Chinach jest zagrożonych
  • PoC został upubliczniony: QiAnXin zdołało go powtórzyć

To historyczna luka w podstawowym module NGINX — napastnikowi wystarczy jedno spreparowane żądanie HTTP, by zdalnie przejąć serwer.

🔍 Przegląd luki

Informacje podstawowe

Cecha podatności Szczegóły
Identyfikator luki CVE-2026-42945
Ocena CVSS v4.0: 9.2 | v3.1: 8.1
Typ podatności przepełnienie bufora na stercie (Heap-based Buffer Overflow)
Rodzaj zagrożenia zdalne wykonanie kodu (RCE), odmowa usługi (DoS)
Warunki wykorzystania bez uwierzytelniania, wystarczy odpowiednio spreparowane żądanie HTTP
Dotknięty komponent ngx_http_rewrite_module (wbudowany moduł podstawowy NGINX)
Odkrywca depthfirst (system automatyczny wykrył ją w 6 godzin)

Zasięg

  • 9,75 mln witryn na świeciejest zagrożonych
  • 2,54 mln witryn w Chinachjest zagrożonych
  • NGINX obsługuje około 1/3 witryn na świecie, więc skala uderzenia jest ogromna
  • Kod trafił do repozytorium w 2008 roku i pozostawał niezauważony przez 18 lat

⚠️ Warunki wyzwolenia

Trzy warunki muszą zostać spełnione jednocześnie

Do wyzwolenia luki wymagane jest, by konfiguracja spełniała określoną kombinację warunków:

Warunek Opis Przykład
1. Nienazwane przechwytywanie PCRE dyrektywa rewrite używa nienazwanych grup przechwytujących $1, $2, $3…
2. Znak zapytania w ciągu zastępczym ciąg zastępczy zawiera znak ? /profile.php?id=$1&tab=$2
3. Kolejna dyrektywa rewrite/if/set po dyrektywie rewrite następuje kolejna dyrektywa rewrite … last; if (…) { … }

Przykład podatnej konfiguracji

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

Ta konfiguracja spełnia jednocześnie trzy warunki: nienazwane przechwytywanie $1/$2, ciąg zastępczy zawiera ?, po niej następuje dyrektywa if.

🔬 Mechanizm luki

Niespójność stanu między dwiema fazami przetwarzania

Silnik skryptowy NGINXkorzysta z przetwarzania dwufazowego:

  • pierwsza faza: obliczenie wymaganego rozmiaru bufora
  • druga faza: skopiowanie danych do bufora

Istota luki tkwi w błędnym zarządzaniu flagą is_args:

Faza stan is_args logika przetwarzania rezultat
Obliczanie długości is_args = 0 zwraca oryginalną długość przechwyconego ciągu niedoszacowanie rozmiaru bufora
Kopiowanie danych is_args = 1 wywołanie ngx_escape_uri, każdy bajt rozszerzany do 3 bajtów przepełnienie bufora na stercie

Szczegółowy przebieg

  1. dyrektywa rewritezawiera nienazwane przechwytywanie $1/$2
  2. ciąg zastępczyzawiera ?, co ustawia is_args = 1
  3. faza obliczania długości: użycie nowo zainicjowanego silnika podrzędnego, is_args = 0
  4. zwrócenie oryginalnej długości: przydzielenie zbyt małego bufora na stercie
  5. faza kopiowania danych: użycie głównego silnika, is_args = 1
  6. wywołanie ngx_escape_uri: rozszerzenie bajtów, przepełnienie bufora
  7. Dane URI kontrolowane przez napastnikatrafiają do obszaru poza buforem

Sposób wykorzystania

kształtowanie sterty między żądaniami (Heap Feng Shui):

  • ciało żądania POSTwypełnia pamięć sterty (URI nie może zawierać bajtu null)
  • dane przepełnieniauszkadzają wskaźnik cleanup sąsiedniego ngx_pool_t
  • sfałszowana struktura ngx_pool_cleanup_swskazująca na system()
  • przy niszczeniu poolwywoływana jest funkcja system()
  • co daje RCE

Wpływ ASLR

  • ASLR włączone: tylko awaria procesu roboczego (DoS)
  • ASLR wyłączone: możliwe zdalne wykonanie kodu (RCE)

📊 Dotknięte wersje

NGINX Open Source

zakres wersji wersja z poprawką
0.6.27 – 1.30.0 1.31.0, 1.30.1

NGINX Plus

zakres wersji wersja z poprawką
R32 – R36 R36 P4, R35 P2, R32 P6

Inne dotknięte komponenty

  • 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

🔥 Status PoC

PoC został upubliczniony

  • Repozytorium na GitHub: https://github.com/DepthFirstDisclosures/Nginx-Rift
  • QiAnXin odtworzyło exploit: badaczom z centrum analizy zagrożeń udało się go powtórzyć
  • Szczegóły techniczne są publiczne: depthfirst opublikowało analizę techniczną
  • Wykorzystanie w środowisku produkcyjnym: jak dotąd nie odnotowane

Jak użyć PoC

# 构建容器
./setup.sh

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

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

✅ Sposoby naprawy

Metoda 1: aktualizacja wersji

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

# 升级后重启 NGINX
nginx -s reload

Metoda 2: zmiana konfiguracji (środek łagodzący)

Zamień nienazwane grupy przechwytujące na grupy nazwane: 

# 易受攻击配置（未命名捕获）
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;

Grupy nazwanenie wyzwalają luki.

Metoda 3: sprawdzenie konfiguracji

Sprawdź, czy nie występuje podatna konfiguracja: 

# 搜索易受攻击的 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/

🔍 Przebieg odkrycia

Odkrycie przez zautomatyzowany system

depthfirst: system analizy bezpieczeństwa tej firmy

  • w ciągu 6 godzinznalazł 5 problemów
  • 4 z nich potwierdził NGINX
  • CVE-2026-42945to najpoważniejsza z luk
  • sięgająca 2008 roku, obecna w niemal wszystkich standardowych kompilacjach

Powiązane luki

  • CVE-2026-42946: uszkodzenie pamięci
  • CVE-2026-40701: uszkodzenie pamięci
  • CVE-2026-42934: uszkodzenie pamięci

📝 Podsumowanie

CVE-2026-42945to najpoważniejsza w historii luka NGINX:

  • Ukryta przez 18 lat: w kodzie od 2008 roku
  • CVSS 9.2: przepełnienie bufora na stercie, może skutkować RCE
  • Warunki wyzwolenia: dyrektywa rewrite z nienazwanym przechwytywaniem + ciąg zastępczy zawierający ? + kolejna dyrektywa po niej
  • Zasięg: 9,75 mln witryn na świecie, z tego 2,54 mln w Chinach
  • PoC upubliczniony: repozytorium na GitHub + odtworzony przez QiAnXin
  • Naprawa: aktualizacja wersji albo przejście na nazwane grupy przechwytujące

Luka ujawniła się po 18 latach — zalecamy jak najszybszą aktualizację lub zmianę konfiguracji.

Komunikat oficjalny: https://my.f5.com/manage/s/article/K000161019

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

Analiza techniczna: https://depthfirst.com/research/nginx-rift