CVE-2026-119977 w WordPress: instalacja poprawki może chwilowo otworzyć drogę do RCE

Wprowadzenie do problemu / definicja

W ekosystemie WordPress ujawniono podatność CVE-2026-119977, która dotyczy mechanizmu aktualizacji rdzenia i może prowadzić do zdalnego wykonania kodu. Problem jest szczególnie istotny, ponieważ zagrożenie nie dotyczy wyłącznie instancji pozbawionych poprawek. W określonych warunkach również sam proces instalowania aktualizacji bezpieczeństwa może na krótki czas pozostawić witrynę w stanie umożliwiającym atak.

Istota błędu sprowadza się do tego, że nowa wersja WordPress jest tymczasowo rozpakowywana przy użyciu starej logiki aktualizatora. Jeśli napastnik zdoła przewidzieć nazwę katalogu tymczasowego i trafi w bardzo krótkie okno czasowe, może uzyskać możliwość uruchomienia kodu PHP z uprawnieniami serwera WWW.

W skrócie

• Podatność dotyczy wersji WordPress od 4.7 do 7.1.3.
• Luka została powiązana z aktywnym wykorzystaniem w rzeczywistych atakach.
• Ryzyko pojawia się podczas aktualizacji rdzenia, gdy pakiet jest rozpakowywany do katalogu tymczasowego.
• Najpoważniejszym skutkiem jest możliwość zdalnego wykonania kodu po stronie serwera.
• Poprawki udostępniono w wersji 7.1.4 oraz w odpowiadających jej wydaniach bezpieczeństwa dla wspieranych starszych gałęzi.

Kontekst / historia

Mechanizm aktualizacji WordPress od lat działa według podobnego schematu: system pobiera pakiet nowej wersji, a następnie rozpakowuje go do katalogu tymczasowego w ścieżce wp-content/upgrade. Przez krótki czas na serwerze znajduje się więc pełna lub częściowa kopia nowego wydania aplikacji. Jeżeli zawarte w niej pliki instalacyjne są osiągalne z poziomu sieci, proces aktualizacji może stać się elementem powierzchni ataku.

Opis problemu wskazuje, że jego korzenie mogą sięgać starszych generacji platformy. Dla wspieranych wersji opublikowano poprawki bezpieczeństwa, ale środowiska działające na bardzo starych, niewspieranych wydaniach nie otrzymają już łat i wymagają migracji. Dodatkowo wysoka waga incydentu wynika z faktu, że luka została powiązana z aktywną eksploatacją.

Analiza techniczna

Sednem podatności jest wyścig czasowy występujący podczas aktualizacji rdzenia. W trakcie procesu update WordPress rozpakowuje pakiet do katalogu tymczasowego. W podatnych wydaniach nazwa tego katalogu może być przewidywalna albo częściowo przewidywalna, co zwiększa szansę powodzenia ataku.

Przykładowy scenariusz nadużycia wygląda następująco:

• atakujący identyfikuje moment rozpoczęcia aktualizacji,
• przewiduje lub odgaduje nazwę katalogu tymczasowego,
• uzyskuje dostęp do instalatora lub innych istotnych plików w rozpakowanej kopii,
• wykonuje działania prowadzące do uruchomienia kodu PHP przed usunięciem katalogu.

Kluczowy niuans polega na tym, że poprawka zmienia zachowanie aktualizatora dopiero po pełnym wdrożeniu. Oznacza to, że aktualizacja instalująca zabezpieczenie nadal może zostać przeprowadzona z użyciem wcześniejszej, podatnej logiki. W praktyce ostatnie niebezpieczne okno może pojawić się właśnie w momencie przechodzenia na wersję naprawioną.

Znaczenie ma także typ pakietu aktualizacyjnego. Pełne pakiety częściej zawierają komplet plików instalacyjnych, natomiast pakiety częściowe obejmują jedynie różnice między wersjami. Jeśli pakiet częściowy nie zawiera komponentów instalatora, praktyczna możliwość wykorzystania błędu spada, ale nie znika całkowicie. Ostatecznie poziom ryzyka zależy od lokalnie zainstalowanego mechanizmu aktualizacji i ekspozycji katalogu tymczasowego.

Nowsze wydania wprowadzają losowanie nazwy katalogu tymczasowego oraz dodatkowe zabezpieczenia ograniczające możliwość nadpisania krytycznych plików. To znacząco utrudnia wykorzystanie błędu po zakończeniu aktualizacji.

Konsekwencje / ryzyko

Najgroźniejszym skutkiem CVE-2026-119977 jest zdalne wykonanie kodu z uprawnieniami procesu serwera WWW. W zależności od konfiguracji środowiska może to umożliwić pełne przejęcie aplikacji, modyfikację zawartości serwisu lub trwałe osadzenie złośliwych komponentów.

• odczyt i modyfikacja plików witryny,
• instalacja backdoora lub web shella,
• manipulacja treścią i konfiguracją aplikacji,
• przejęcie kontroli administracyjnej nad środowiskiem,
• dalsza eskalacja w ramach hostingu współdzielonego lub zaplecza infrastrukturalnego.

Ryzyko operacyjne jest podwyższone, ponieważ luka była aktywnie wykorzystywana, a okno ataku — choć krótkie — może zostać skutecznie namierzone przez automatyczne kampanie skanujące. Dodatkowym problemem jest błędne założenie, że samo uruchomienie procesu aktualizacji od razu eliminuje zagrożenie. W tym przypadku przez chwilę może ono nadal istnieć.

Szczególnie narażone pozostają środowiska z publicznie dostępnym katalogiem wp-content/upgrade, automatycznymi aktualizacjami działającymi bez nadzoru oraz ograniczonym monitoringiem logów HTTP i zmian w systemie plików.

Rekomendacje

Najważniejszym działaniem ochronnym przed rozpoczęciem aktualizacji jest zablokowanie dostępu HTTP do katalogu wp-content/upgrade. WordPress korzysta z niego lokalnie na poziomie systemu plików, dlatego odcięcie ruchu sieciowego do tej lokalizacji nie powinno zakłócić samego procesu aktualizacji, a jednocześnie utrudni wykorzystanie tymczasowo rozpakowanych plików.

Z perspektywy operacyjnej warto wdrożyć następujące kroki:

• zablokować serwowanie ścieżki wp-content/upgrade w konfiguracji serwera WWW,
• zweryfikować, że żądania do tego katalogu zwracają kod 403,
• przeprowadzić aktualizację do WordPress 7.1.4 lub właściwego wydania bezpieczeństwa dla używanej gałęzi,
• rozważyć ręczną aktualizację poza web rootem w środowiskach o podwyższonych wymaganiach bezpieczeństwa,
• monitorować logi pod kątem żądań do plików PHP w katalogu aktualizacji,
• sprawdzić, czy nie pojawiły się nieautoryzowane konta administratorów, nieznane wtyczki lub podejrzane pliki PHP,
• potraktować starsze, niewspierane wersje WordPress jako wymagające pilnej migracji.

W organizacjach o wyższym poziomie dojrzałości bezpieczeństwa warto dodatkowo:

• objąć proces aktualizacji oknem serwisowym z aktywnym nadzorem,
• włączyć detekcję zmian w krytycznych plikach aplikacji,
• skorelować logi aplikacyjne, systemowe i WAF,
• wykonać kontrolę integralności po zakończeniu aktualizacji.

Podsumowanie

CVE-2026-119977 pokazuje, że ryzyko w WordPress może wynikać nie tylko z braku aktualizacji, ale także z samego sposobu jej wdrażania. Mechanizm update może pozostawić krótkie, lecz realne okno umożliwiające zdalne wykonanie kodu, jeśli tymczasowa kopia pakietu pozostaje osiągalna z sieci.

Dla administratorów oznacza to konieczność traktowania procesu patchowania jako elementu powierzchni ataku. Kluczowe znaczenie ma nie tylko szybkie przejście na wersję naprawioną, ale także wcześniejsze odcięcie dostępu do katalogu aktualizacji, monitoring logów oraz kontrola artefaktów potencjalnej kompromitacji.

Źródła

1. The Hacker News — https://thehackernews.com/2026/11/installing-fix-for-exploited-wordpress.html
2. WordPress/wordpress-develop Security Advisories — https://github.com/WordPress/wordpress-develop/security/advisories
3. CVE Record: CVE-2026-119977 — https://www.cve.org/CVERecord?id=CVE-2026-119977