CVE-2025-1974 IngressNightmare: krytyczne RCE

CVE-2025-1974, znane jako IngressNightmare, to krytyczna podatność ingress-nginx oceniona na 9,8 w CVSS 3.1. Nie jest to zwykły błąd konfiguracji reverse proxy. Podmiot mający dostęp sieciowy do admission controllera może bez uwierzytelnienia wykorzystać mechanizm wstrzykiwania konfiguracji, wykonać kod w kontrolerze ingress, a następnie sięgnąć po sekrety dostępne jego kontu usługi. W typowej instalacji konsekwencją może być przejęcie całego klastra Kubernetes.

Najkrótsza rekomendacja: sprawdź wszystkie klastry, zaktualizuj ingress-nginx do co najmniej 1.11.5 lub 1.12.1, ogranicz dostęp do admission webhooka i potraktuj podatny, osiągalny kontroler jak potencjalny punkt naruszenia. Sam WAF przed aplikacją nie usuwa tej luki.

Potwierdzone fakty o CVE-2025-1974

Parametr	Potwierdzona informacja
Produkt	Kubernetes ingress-nginx controller
Ocena	CVSS 3.1: 9,8 — krytyczna
Podatne wersje	wszystkie wcześniejsze niż 1.11.0, linia 1.11.0–1.11.4 oraz 1.12.0
Wersje naprawione	1.11.5, 1.12.1 i nowsze
Warunek ataku	dostęp sieciowy do admission controllera; bez wymaganych poświadczeń
Skutek	RCE w kontekście kontrolera, dostęp do sekretów i możliwe przejęcie klastra
Ujawnienie	24 marca 2025 r. przez Kubernetes Security Response Committee
Publiczny PoC	tak — kod demonstracyjny jest dostępny publicznie

Zakres pochodzi z oficjalnego komunikatu Kubernetes i advisory społeczności Kubernetes. To ważne rozróżnienie: CVE-2025-1974 dotyczy projektu ingress-nginx, a nie każdego produktu noszącego w nazwie NGINX i nie każdego Ingress Controllera.

Jak działa IngressNightmare

Ingress-nginx przekłada obiekty Kubernetes Ingress na konfigurację serwera NGINX. Przed zapisaniem obiektu API może wysłać jego treść do Validating Admission Controller, aby kontroler sprawdził konfigurację. Właśnie ten wewnętrzny punkt walidacji powiększa powierzchnię ataku.

CVE-2025-1974 pozwala podmiotowi osiągającemu webhook admission przesłać żądanie prowadzące do wstrzyknięcia konfiguracji NGINX. Luka staje się szczególnie groźna w połączeniu z innymi błędami konfiguracji ujawnionymi w tym samym pakiecie poprawek. Skonstruowana konfiguracja może wymusić załadowanie danych kontrolowanych przez atakującego, co prowadzi do wykonania kodu w procesie kontrolera.

Techniczny root cause i granice podatności

Admission webhook odbiera od API servera obiekt AdmissionReview i ocenia kandydujący Ingress przed jego zapisaniem. W tym procesie ingress-nginx generuje konfigurację, którą następnie waliduje. Krytyczna granica zaufania powstaje więc między wejściem do webhooka, generatorem konfiguracji NGINX i procesem kontrolera posiadającym dostęp do Kubernetes API. Oficjalny komunikat Kubernetes opisuje CVE-2025-1974 jako możliwość wykorzystania podatności configuration injection przez Validating Admission Controller; pełny skutek RCE wynika z połączenia tej osiągalności z błędami obsługi konfiguracji poprawionymi w tym samym wydaniu.

Nie należy przypisywać samej luce niepotwierdzonych właściwości konkretnego payloadu. Dla obrony wystarcza udokumentowany model: nieuwierzytelniony podmiot z łącznością do webhooka może doprowadzić do wykonania kodu w kontekście kontrolera. NVD dla CVE-2025-1974 potwierdza warunek dostępu do Pod network, RCE i możliwość ujawnienia sekretów osiągalnych dla kontrolera.

Model powierzchni ataku

Pytanie	Co trzeba sprawdzić	Dlaczego ma znaczenie
Czy admission jest włączony?	argumenty kontrolera, Service i `ValidatingWebhookConfiguration`	bez aktywnej funkcji ten konkretny wektor nie jest osiągalny
Kto może dotrzeć do Service?	NetworkPolicy, CNI, VPC, VPN, peering i hostNetwork	„ClusterIP” nie oznacza automatycznie izolacji
Jaka wersja działa?	tag, digest i wersja wewnątrz każdego uruchomionego Poda	manifest po zmianie nie dowodzi zakończonego rollout’u
Co może konto kontrolera?	Role, ClusterRole, bindings i montowane tokeny	wyznacza zasięg po RCE
Jakie sekrety są osiągalne?	namespace, TLS Secrets, external secret mounts i cloud identity	określa obowiązkowy zakres rotacji

Segmentację należy oceniać zgodnie z zasadą zero trust dla sieci i usług: workload wewnątrz klastra nie powinien otrzymywać dostępu tylko z powodu swojego położenia.

Nie należy upraszczać tego scenariusza do „każdy z Internetu może przejąć każdy klaster”. Oficjalny opis wskazuje na wymagany dostęp do sieci Podów lub admission controllera. W wielu środowiskach taki dostęp mają jednak wszystkie workloady w klastrze, zasoby w tej samej chmurowej sieci VPC, hosty w sieci firmowej albo systemy połączone VPN. Jedna wcześniej przejęta, niskokrytyczna aplikacja może więc stać się punktem startowym do ataku na warstwę zarządzającą ruchem.

Dlaczego skutkiem może być przejęcie klastra

Kontroler ingress musi odczytywać sekrety TLS i konfiguracje usług, aby terminować HTTPS i kierować ruch. Kubernetes podkreślił, że domyślne wdrożenia ingress-nginx często miały dostęp do sekretów w całym klastrze. RCE w takim Podzie nie kończy się zatem na jego systemie plików.

Realna ścieżka wpływu może wyglądać następująco:

napastnik uzyskuje łączność z admission webhookiem;
wykorzystuje łańcuch IngressNightmare do wykonania kodu w kontrolerze;
odczytuje token konta usługi, sekrety TLS lub dane konfiguracyjne dostępne procesowi;
używa nadmiernych uprawnień RBAC do dalszej enumeracji i przejęcia workloadów;
utrzymuje dostęp przez zmiany zasobów, obrazów kontenerów albo sekretów.

Dokładny skutek zależy od RBAC, segmentacji i sposobu przechowywania sekretów. Dlatego priorytetu nie można wyznaczać wyłącznie na podstawie publicznej ekspozycji aplikacji. Istotne są również ścieżki ruchu wewnętrznego i uprawnienia service account.

Publiczny PoC i bezpieczna walidacja

Publiczny PoC IngressNightmare dla CVE-2025-1974 pokazuje techniczną możliwość wykorzystania luki. Repozytorium należy traktować jako potencjalnie niebezpieczny kod. Nie uruchamiaj go na produkcji, cudzych klastrach ani systemach bez pisemnej zgody.

Bezpieczniejsza walidacja nie wymaga wykonywania RCE. Zespół może:

sporządzić listę klastrów i wykryć workloady z etykietą app.kubernetes.io/name=ingress-nginx;
odczytać wersję obrazu kontrolera z manifestu Deployment lub DaemonSet;
sprawdzić istnienie ingress-nginx-admission i reguły sieciowe prowadzące do webhooka;
przeanalizować RBAC konta usługi kontrolera, zwłaszcza możliwość odczytu sekretów poza jego namespace;
wykonać test poprawki na kopii klastra lub w odizolowanym laboratorium;
po aktualizacji ponownie potwierdzić wersję działających Podów, a nie tylko zmieniony plik Helm values.

PoC nie zastępuje inwentaryzacji. Negatywny wynik jednego skryptu może wynikać z konkretnej topologii sieci, wersji Pythona albo zabezpieczeń pośrednich i nie dowodzi, że podatny komponent jest bezpieczny.

Bezpieczna walidacja ekspozycji bez RCE

Najpierw potwierdź obecność, potem wersję, następnie osiągalność, a dopiero na końcu blast radius. Walidacja sieciowa może użyć zatwierdzonego Poda diagnostycznego i sprawdzić samo zestawienie połączenia z Service webhooka, bez przesyłania obiektu wykorzystującego lukę. Wynik zapisuj osobno dla każdej strefy: zwykłe workloady, namespace administracyjny, węzły, sieć VPC, VPN i peering.

Wersję ustal z kilku dowodów: specyfikacji workloadu, digestu obrazu, faktycznie uruchomionych Podów oraz danych z registry lub SBOM. Jeżeli choć jedna replika nadal działa na podatnym obrazie, usługa nie jest w pełni naprawiona. Następnie wykonaj can-i lub równoważną analizę RBAC dla service account bez pobierania sekretów. Taka procedura daje wystarczający dowód do priorytetyzacji i pasuje do wymagań weryfikacyjnych OWASP ASVS 5, mimo że podatność leży w infrastrukturze aplikacji.

Drzewo decyzji dla triage

Brak ingress-nginx — zamknij finding po udokumentowaniu używanego kontrolera.
Ingress-nginx, ale admission wyłączony — CVE-2025-1974 nie ma aktywnego wektora; nadal sprawdź inne CVE z pakietu i zaplanuj aktualizację.
Admission włączony, wersja naprawiona — zweryfikuj wszystkie repliki, digest i segmentację; przejdź do retestu negatywnego.
Admission włączony, wersja podatna, webhook nieosiągalny z niezaufanych stref — patchuj pilnie, ale udokumentuj kontrolę kompensującą i testuj możliwe ścieżki pośrednie.
Wersja podatna i webhook osiągalny — izoluj, aktualizuj w trybie awaryjnym, zachowaj logi i uruchom threat hunting.
Są oznaki wykonania kodu lub użycia sekretów — traktuj zdarzenie jako incydent, nie jako zwykły ticket patch management.

Jak naprawić CVE-2025-1974

1. Zaktualizuj kontroler

Docelową naprawą jest instalacja ingress-nginx 1.11.5, 1.12.1 lub nowszego wspieranego wydania. Trzeba sprawdzić zarówno wersję chartu Helm, jak i tag lub digest faktycznie uruchomionego obrazu. W środowisku z wieloma klastrami przydatne jest centralne zapytanie do rejestru zasobów lub narzędzia CSPM.

2. Ogranicz admission controller

Jeżeli aktualizacja nie może zostać wykonana natychmiast, Kubernetes zaleca tymczasowe wyłączenie Validating Admission Controller. W Helm odpowiada za niego ustawienie controller.admissionWebhooks.enabled=false. To ograniczenie awaryjne, nie równoważnik poprawki. Po aktualizacji funkcję można przywrócić, ponieważ wykrywa błędne obiekty Ingress przed ich wdrożeniem.

Niezależnie od patcha webhook powinien być osiągalny tylko z niezbędnych komponentów control plane. NetworkPolicy, reguły zapory VPC i segmentacja ograniczają możliwość wykorzystania podobnych błędów w przyszłości.

3. Zredukuj blast radius

Konto usługi kontrolera powinno mieć najmniejszy potrzebny zakres. Jeżeli kontroler obsługuje tylko wybrane namespace, nie powinien automatycznie czytać wszystkich sekretów klastra. Warto rozdzielić kontrolery według stref zaufania i nie montować do nich niepotrzebnych tokenów lub danych uwierzytelniających.

Jak zweryfikować poprawkę i wykonać retest

Retest powinien wykazać nie tylko nowy numer wersji, ale zmianę całego warunku ryzyka:

wszystkie Deploymenty, DaemonSety i Pody używają naprawionego digestu;
nie ma osieroconej repliki, starego węzła ani równoległej instalacji Helm;
połączenie do admission Service z nieuprawnionego namespace jest blokowane zgodnie z polityką;
control plane nadal może wykonywać legalną walidację Ingressów;
niejednoznaczny lub niedozwolony obiekt testowy jest bezpiecznie odrzucany w izolowanym środowisku;
service account nie może czytać sekretów poza wymaganym zakresem;
rollout, logi i alerty nie pokazują crash loop, błędu webhooka ani obejścia przez alternatywny endpoint.

Pozytywny test funkcjonalny jest równie ważny jak test negatywny. Wyłączenie webhooka może ograniczyć ryzyko, lecz zepsuty proces admission potrafi zablokować wdrożenia. Dla organizacji wykonującej regularne testy penetracyjne aplikacji i infrastruktury webowej ta kontrola powinna wejść do regresji po każdej zmianie ingressu lub CNI.

Detekcja i threat hunting po ujawnieniu luki

Aktualizacja usuwa podatność, ale nie usuwa śladów wcześniejszego włamania. Dla podatnych i osiągalnych instalacji przejrzyj:

zdarzenia Kubernetes Audit dotyczące zmian ValidatingWebhookConfiguration, Ingressów, Secretów, RoleBindingów i ClusterRoleBindingów;
logi admission controllera pod kątem nietypowych, odrzuconych i powtarzalnych żądań;
procesy potomne kontrolera, nieoczekiwane narzędzia sieciowe oraz outbound traffic z jego Podów;
nowe service accounts, tokeny, sekrety i workloady utworzone poza pipeline CI/CD;
zmiany obrazów, init containers, wolumenów hostPath i uprzywilejowanych Podów;
użycie sekretów TLS i poświadczeń chmurowych po dacie możliwej ekspozycji.

Nie istnieje jeden uniwersalny IOC, który wiarygodnie potwierdza lub wyklucza wykorzystanie. Traktuj powyższe elementy jako sygnały telemetryczne, a nie sygnaturę exploita. Najmocniejsza korelacja łączy nietypowe wywołanie admission, anomalię procesu kontrolera, ruch wychodzący oraz późniejsze użycie sekretu albo zmianę zasobu Kubernetes. W logach zachowuj timestamp, source IP lub Pod identity, request UID, namespace, nazwę zasobu i wynik webhooka. Ogranicz treść obiektów, jeżeli może zawierać dane poufne.

Jeżeli są oznaki wykonania kodu, samo odtworzenie Poda nie wystarczy. Należy uruchomić procedurę reagowania: zabezpieczyć logi, odizolować węzeł lub namespace, rotować dostępne sekrety i tokeny, sprawdzić control plane oraz odbudować z zaufanego stanu.

Lista kontrolna dla administratora Kubernetes

Co CVE-2025-1974 mówi o bezpieczeństwie Kubernetes

IngressNightmare pokazuje, że komponent „wewnętrzny” nie jest automatycznie zaufany. Admission webhooks wykonują złożoną logikę na danych pochodzących z API, a kontrolery często posiadają szerokie uprawnienia. Dlatego przegląd bezpieczeństwa klastra powinien obejmować nie tylko publiczne serwisy, lecz także segmentację, RBAC i kontrolę obrazów kontenerów.

Jeżeli chcesz potwierdzić ekspozycję bez ryzykownego testowania na produkcji, możemy przeprowadzić autoryzowany pentest infrastruktury chmurowej i Kubernetes z bezpiecznym zakresem, dowodami i retestem poprawek.