CVE-2026-119977: Luka RCE w Rdzeniu WordPressa Wykorzystywana Podczas Aktualizacji Oprogramowania

Poważna podatność w WordPress Core jest aktywnie wykorzystywana w atakach, co skłoniło Amerykańską Agencję Bezpieczeństwa Cybernetycznego i Infrastruktury (CISA) do dodania tej luki do katalogu Znanych Wykorzystywanych Słabości (KEV). Śledzona jako CVE-2026-119977, podatność ta ma wynik CVSS wynoszący 8,1 i może pozwolić nieautoryzowanemu atakującemu na wykonanie dowolnego kodu na podatnym serwerze w trakcie aktualizacji WordPress Core.

Podatność wynika z wyścigu kontrola-użytkowanie (TOCTOU) w procesie aktualizacji WordPress. Podczas pełnych aktualizacji Core, WordPress tymczasowo umieszcza pliki instalacyjne w przewidywalnych, dostępnych z sieci lokalizacjach. Atakujący mogą wielokrotnie sprawdzać te miejsca i próbować dotrzeć do komponentów instalacyjnych w krótkim okresie, w którym trwa aktualizacja.

WordPress rozwiązał problem w wersji 7.1.4, wydanej 28 października 2026 roku. Podatność dotyczy wersji WordPress od 4.7 do 7.1.3, podczas gdy poprawki zostały także wstecznie przeniesione do starszych wersji. WordPress podkreśla, że tylko najnowsze wydanie jest aktywnie wspierane.

Ryzyko przeniosło się poza teoretyczne wykorzystanie. Telemetria Wordfence cytowana przez The Hacker News zanotowała ponad 18,500 żądań celujących w ścieżki instalacyjne setup-config.php w ciągu pierwszych 21 godzin po ujawnieniu. CISA następnie potwierdziła dowody na wykorzystanie i zażądała, aby odpowiednie agencje cywilne rządu USA naprawiły podatność do 6 listopada 2026 roku.

Zespoły ds. bezpieczeństwa mogą użyć platformy SOC Prime, aby wzmocnić pokrycie detekcji przeciwko pojawiającym się technikom wykorzystywania i poszukiwać podejrzanej aktywności związanej z podatnymi systemami internetowymi. Wykryj wykorzystanie CVE-2026-119977, monitorując nieprawidłowe żądania do lokalizacji aktualizacji WordPress, nieoczekiwane wykonanie PHP, nowo utworzone konta administracyjne, podejrzane pliki i zachowanie poeksploatacyjne.

Zawartość detekcji może nie być dostępna dla każdego CVE. Sprawdź platformę SOC Prime dla obecnych pokryć. Jeśli odpowiednie detekcje nie są jeszcze dostępne, sprawdzaj ponownie, ponieważ nowe wywiady na temat zagrożeń i treści detekcji są ciągle dodawane.

Skontaktuj się ze Sprzedażą

Analiza CVE-2026-119977

CVE-2026-119977 jest klasyfikowana jako wyścig TOCTOU pod kodem CWE-367 i ma wynik CVSS 3.1 wynoszący 8,1. Jej wektor odzwierciedla eksploatację sieciową niewymagającą uprawnień ani interakcji użytkownika, z dużym potencjalnym wpływem na poufność, integralność i dostępność. Złożoność ataku oceniana jest jako wysoka, ponieważ pomyślna eksploatacja zależy od dostępu do podatnego zasobu w wąskim momencie aktualizacji.

CVE-2026-119977 dotyczy wersji WordPress Core od 4.7 do 7.1.3. Słabość ta nie jest związana z żadną wtyczką lub motywem innych firm; istnieje w mechanizmie aktualizacji samego Core.

Problem występuje podczas pełnych aktualizacji Core. WordPress tymczasowo wyodrębnia nową paczkę do lokalizacji inscenizacji pod katalogiem wp-content/upgrade, zanim zastąpi istniejącą instalację. W dotkniętych wersjach, części tej lokalizacji inscenizacji mogą być przewidywalne i dostępne z sieci podczas gdy trwa aktualizacja.

Szczególnie ważnym komponentem jest inscenizator setup-config.php. Nieautoryzowany atakujący, który prawidłowo przewidzi tymczasową ścieżkę i dotrze do tego komponentu przed zakończeniem czyszczenia przez WordPress, może być w stanie wejść w interakcję z inscenizowaną instalacją i ostatecznie wykonać kod PHP na serwerze.

To tworzy nietypowy model eksploatacji. Podatna strona WordPress niekoniecznie jest ciągle eksploatowalna. Zamiast tego, atakujący musi złapać stronę w krótkim okresie, kiedy pełna aktualizacja pakietu naraża pliki stagingowe. Badacze wskazują, że szansa ta może trwać tylko kilka sekund.

Atakujący mogą zrekompensować to ograniczenie poprzez automatyzację. Zamiast składać pojedyncze żądanie, aktorzy zagrażający mogą nieprzerwanie sprawdzać potencjalne ścieżki aktualizacji i czekać na rozpoczęcie aktualizacji przez cel. Wordfence zaobserwował, że atakujący wielokrotnie prosili o różne wersje lokalizacji inscenizatorów, co świadczy, że rzeczywiści aktorzy szybko zrozumieli, jak celować w wyścig warunków.

Niemniej jednak duża liczba zaobserwowanych żądań powinna być interpretowana ostrożnie. Zgłoszone liczby reprezentują zablokowane żądania lub próby wykorzystania i nie oznaczają, że każde żądanie zakończyło się powodzeniem w zdalnym wykonaniu kodu. Eksploatacja wciąż wymaga, aby żądanie zbiegało się z aktywną pełną aktualizacją pakietu i innymi wymaganymi warunkami serwera.

Początkowa telemetria Wordfence pokazała ponad 18,500 żądań skierowanych na ścieżki inscenizatorów w pierwszych 21 godzinach. GBHackers później doniósło o prawie 59,000 prób zablokowanych w ciągu 24 godzin, podczas gdy The Hacker News cytowało dodatkową telemetrię wskazującą na kontynuującą się aktywność eksploatacyjną.

Niezależna telemetria honeypot cytowana przez The Hacker News zarejestrowała próby eksploatacji 30 października, co dodatkowo wspiera decyzję CISA o sklasyfikowaniu podatności jako aktywnie wykorzystywanej. Dodanie przez CISA tej luki do KEV znacznie zwiększa pilność dla organizacji obsługujących publiczną infrastrukturę WordPress.

W momencie pisania, przeglądane źródła nie dokumentują powszechnie dostępnego, publicznie zweryfikowanego repozytorium PoC dla CVE-2026-119977. Jednakże, publiczny kod eksploatacyjny nie jest wymagany do ustalenia ryzyka, ponieważ próby wykorzystania zostały już zaobserwowane na dużą skalę, a CISA potwierdziła aktywną eksploatację.

WordPress 7.1.4 zmienia podatny proces aktualizacji. Według dostępnych raportów technicznych, naprawa obejmuje uczynienie lokalizacji stagingowych mniej przewidywalnymi, wprowadzenie dodatkowych zabezpieczeń przeciwko bezpośredniemu dostępowi oraz zapobieganie promowaniu danych konfiguracyjnych w sposób niebezpieczny.

WordPress przypisał zasługę badaczowi bezpieczeństwa Umutowi Bayramowi za zgłoszenie słabości procesu aktualizacji. Wersja 7.1.4 została wydana 28 października 2026 roku, a rekord CVE został później opublikowany 31 października.

Dla wykrycia CVE-2026-119977, obrońcy powinni zwracać szczególną uwagę na żądania internetowe wymierzone w nietypowe ścieżki pod wp-content/upgrade, szczególnie żądania odnoszące się do inscenizowanych kopii setup-config.php. Powtarzające się żądania przez wiele możliwych katalogów stagingowych mogą wskazywać na zautomatyzowane sondowanie próbujące wygrać wyścig warunków.

Pomyślna eksploatacja może potencjalnie umożliwić zdalne wykonanie kodu PHP w kontekście podatnego serwera internetowego. Obrońcy powinni zatem skorelować podejrzane żądania ścieżki aktualizacji z późniejszymi dowodami, takimi jak nieoczekiwane pliki PHP, modyfikacja danych konfiguracyjnych WordPress, nieznane konta administratorów, złośliwe wtyczki, nietypowe procesy potomne uruchamiane przez serwer internetowy lub nieoczekiwane połączenia wychodzące.

Publiczne raporty nie zidentyfikowały kompleksowego zestawu IOC specyficznych dla atakującego dotyczącego CVE-2026-119977, takich jak stabilne domeny dowodzenia i kontroli lub hashe złośliwego oprogramowania. To sprawia, że detekcja oparta na zachowaniu jest szczególnie ważna. Żądania do przewidywalnych ścieżek stagingowych, podejrzana aktywność podczas okna aktualizacji i modyfikacje poeksploatacyjne oferują bardziej trwałe możliwości łowienia niż poleganie wyłącznie na statycznych wskaźnikach.

Łagodzenie CVE-2026-119977

Podstawową metodą łagodzenia dla CVE-2026-119977 jest natychmiastowa aktualizacja WordPress. WordPress 7.1.4 zawiera poprawkę bezpieczeństwa, a poprawki zostały również udostępnione lub wstecznie przeniesione dla kwalifikujących się starszych wersji. Organizacje powinny priorytetowo traktować migrację do najnowszej aktywnie wspieranej wersji WordPressa, zamiast polegać bez końca na wstecznych poprawkach bezpieczeństwa.

Administratorzy powinni podjąć następujące działania:

1. Zaktualizuj instalacje WordPress widoczne z internetu do wersji 7.1.4 lub późniejszej.
2. Zweryfikuj, że automatyczne aktualizacje zakończyły się pomyślnie, zamiast zakładać, że aktualizacja została zastosowana.
3. Sporządź inwentarz starszych instalacji WordPress, w tym zapomnianych środowisk deweloperskich, testowych i dziedzictwa.
4. Przejrzyj dzienniki serwera internetowego i WAF pod kątem żądań kierujących na wp-content/upgrade i ścieżki inscenizacji setup-config.php.
5. Zbadaj nieoczekiwane pliki PHP, nowe konta administratorów WordPress, nieautoryzowane wtyczki i niewyjaśnione zmiany konfiguracyjne.
6. Przejrzyj połączenia wychodzące i procesy potomne serwera internetowego w poszukiwaniu dowodów aktywności poeksploatacyjnej.
7. Upewnij się, że ochrona WAF działa wystarczająco wcześnie w ścieżce żądania, aby obejmować bezpośrednie żądania do tymczasowych plików PHP.
8. Rozważ ograniczenie bezpośredniego dostępu sieciowego do tymczasowych katalogów aktualizacji, gdzie jest to operacyjnie wykonalne.

Zasady zapory ogniowej aplikacji internetowej mogą zmniejszyć narażenie na zautomatyzowane próby eksploatacji, ale nie powinny być traktowane jako zamiennik dla poprawek. Ponieważ podatny zasób może tymczasowo istnieć poza normalnym przepływem żądań WordPress, administratorzy powinni zweryfikować, czy ich wdrożenie WAF faktycznie sprawdza bezpośrednie żądania do plików staged PHP.

Organizacje, które dokonały aktualizacji w czasie, gdy aktywne ataki już się odbywały, powinny również rozważyć retrospektywne dochodzenie. Zakończenie aktualizacji usuwa podatne zachowanie, ale nie dowodzi, że serwer nie został skompromitowany, gdy podatny katalog stagingowy był dostępny.

Przejrzyj dzienniki dostępu związane z precyzyjnym czasem aktualizacji. Żądania do dotkniętych ścieżek stagingowych występujące bezpośrednio przed lub podczas aktualizacji powinny być uważnie analizowane. Zespoły ds. bezpieczeństwa powinny następnie skorelować te żądania z zmianami w systemie plików, modyfikacjami kont WordPress, wykonaniem PHP, podejrzanymi połączeniami sieciowymi i innymi wskaźnikami post-eksploatacyjnymi.

Jeśli podejrzewa się kompromitację, odizoluj dotknięty host, gdzie to praktyczne, zachowaj odpowiednie dzienniki sieciowe, aplikacyjne, uwierzytelniania i systemowe oraz zbierz podejrzane pliki przed naprawą. Dane uwierzytelniające i tajemnice dostępne dla procesu WordPress/PHP powinny być uznane za potencjalnie ujawnione i zamienione zgodnie z wynikami dochodzenia.

Dodanie przez CISA tej podatności do KEV potwierdza, że naprawa powinna być traktowana jako natychmiastowy priorytet operacyjny, a nie rutynowy element cyklu poprawek. Agencje wchodzące w skład federalnej egzekutywy zostały zobowiązane do rozwiązania problemu do 6 listopada 2026 roku.