Podsumowanie
| Parametr | Wartość |
|---|---|
| CVE ID | CVE-2026-42945 |
| Źródło alertu | F5 Security Advisory (K000160932) |
| Rok publikacji CVE | 2026 |
| Data publikacji | 2026-05-28 |
| Producent | F5 (NGINX) |
| Produkt | NGINX (ngx_http_rewrite_module) |
| Typ podatności | Remote Code Execution (Heap Buffer Overflow) |
| CVSS Score | 9.2 (Krytyczny) |
| Publiczny PoC | TAK - dostępny na GitHub |
| CISA KEV | Nie (jeszcze) |
| Ransomware | Nie potwierdzono |
Opis podatności
Źródło: F5 Security Advisory
Krytyczna podatność w module
ngx_http_rewrite_moduleNGINX umożliwia nieuwierzytelnionemu zdalnemu atakującemu wykonanie dowolnego kodu na podatnych systemach. Problem jest spowodowany przepełnieniem bufora na stercie (heap buffer overflow), wywoływanym przez nieprawidłową obsługę dyrektywrewriteisetw konfiguracji NGINX. Specjalnie spreparowane żądania HTTP mogą doprowadzić do zdalnego wykonania kodu w kontekście procesu workera NGINX.
Według badaczy podatność istnieje w kodzie źródłowym NGINX od 2008 roku i dotyczy szerokiego zakresu produktów opartych na NGINX i F5. Dla tej podatności opublikowano działający exploit Proof-of-Concept (PoC) na GitHub, co znacząco zwiększa ryzyko masowej eksploitacji w najbliższych dniach.
W tym samym advisory F5 opublikowało również 3 dodatkowe podatności klasy memory corruption (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934).
Wymagane działania
Najwyższy priorytet aktualizacji - publiczny PoC oznacza realne ryzyko masowej eksploitacji.
Zaktualizuj podatne produkty NGINX/F5 do wersji z poprawką producenta:
- NGINX Open Source (0.6.27 - 1.30.0) - aktualizacja do najnowszej naprawionej wersji
- NGINX Plus (R32 - R36) - aktualizacja zgodnie z advisory F5
- 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 i 5.1.0 - 5.8.0)
- F5 DoS for NGINX (4.8.0)
- NGINX App Protect DoS (4.3.0 - 4.7.0)
- NGINX Gateway Fabric (1.3.0 - 1.6.2 i 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)
Workaround dla systemów, których nie można natychmiast załatać:
- Przejrzyj konfiguracje NGINX pod kątem łącznego użycia dyrektyw
rewriteiset(główny wektor ataku) - tymczasowo wyłącz złożone reguły rewrite, jeśli to możliwe. - Umieść podatne systemy za dodatkową warstwą ochrony WAF (np. AWS WAF, Cloudflare, Imperva) z włączonymi regułami inspekcji złośliwych payloadów HTTP.
- Wdroż reguły IDS/IPS wykrywające próby eksploitacji znanego PoC.
- Monitoruj logi NGINX i procesy workerów pod kątem nietypowych crashów (typowy sygnał próby eksploitacji buffer overflow).
Kogo dotyczy?
Podatność dotyczy ogromnej części infrastruktury internetowej - NGINX serwuje obecnie ok. 1/3 stron WWW na świecie. Praktycznie każda organizacja powinna sprawdzić ekspozycję:
- Produkcyjne serwery WWW - NGINX Open Source i NGINX Plus jako reverse proxy, load balancer, edge gateway
- Kontenery i Kubernetes - NGINX Ingress Controller jest domyślnym ingress w wielu klastrach K8s
- API Gateway - NGINX jako frontend dla mikroserwisów
- WAF i ochrona aplikacji - F5 WAF for NGINX, NGINX App Protect (ironia: WAF sam podatny)
- Edge / CDN - NGINX często stanowi pierwszą linię odbioru ruchu
Ponieważ podatność istnieje od 2008 roku i wymaga jedynie HTTP requesta do nieuwierzytelnionego endpointu, można zakładać, że automatyczne skanery i botnety zaczną masową eksploitację w ciągu godzin/dni od publikacji PoC.
Źródła
Potrzebujesz wsparcia w zabezpieczeniu systemów? Zespół nFlo oferuje usługi zarządzania podatnościami oraz SOC 24/7. Skontaktuj się z nami.
