Co wp2shell naprawdę robi

Gdy Adam Kues z Assetnote wysłał specjalnie spreparowane żądanie do zwykłej instalacji WordPressa, serwer uruchomił jego kod. Bez konta, bez hasła, bez wtyczki, bez żadnego nietypowego ustawienia. Badacze nazwali tę sekwencję wp2shell, WordPress przypisał jej CVE-2026-63030, a obie strony oceniły ją jako krytyczną.

Exploit łączy dwie słabości w trasie wsadowej REST API: pomyłkę w routingu, która pozwala nieuwierzytelnionemu wywołującemu dotrzeć do ścieżek kodu, które powinny być chronione, oraz osiągalne przez nią wstrzyknięcie SQL. Połączone, zamieniają anonimowe żądanie HTTP w wykonanie kodu, najcięższy skutek, jaki może mieć luka w sieci.

Dlaczego automatyczna poprawka to nie meta

WordPress wydał 6.9.5 i 7.0.2 dnia 17 lipca 2026 i, wobec powagi sytuacji, wymusił aktualizacje na dotkniętych witrynach, zamiast czekać na kliknięcie właściciela. To słuszna decyzja i większość witryn jest teraz zamknięta. Zasłania to jednak trudniejsze pytanie.

Luka bez uwierzytelniania oznacza, że każdy w sieci mógł jej użyć, zanim naprawiłeś, a instalacja poprawki tego nie cofa. Jeśli twoja witryna była osiągalna i niezaktualizowana w oknie ekspozycji, aktualizacja usunęła drzwi, ale nie to, co już przez nie weszło: podstawione konto administratora, zaplanowane zadanie, powłokę sieciową w folderze przesłanych plików.

Dlaczego niemal każdy właściciel jest objęty

To tkwiło w rdzeniu, oprogramowaniu uruchamianym przez każdą witrynę WordPress, więc narażenie nie zależało od niszowej wtyczki czy motywu. WordPress napędza blisko 40 procent sieci i dlatego pojedyncza luka rdzenia tej klasy to wydarzenie masowe, a nie przypadek na marginesie.

Wersje od 6.9.0 do 6.9.4 oraz od 7.0.0 do 7.0.1 były podatne na wp2shell. Druga usterka, wstrzyknięcie SQL w parametrze author__not_in klasy WP_Query z oceną CVSS 9.1, sięga aż do 6.8, więc witryna, która przez kilka miesięcy pomijała aktualizacje, niosła większe z dwóch okien ekspozycji.

W co zamieniają to przepisy UE

Dla europejskiej firmy luka nie jest tylko techniczna. Jeśli za tą witryną stoją dane osobowe, RODO daje ci 72 godziny na powiadomienie organu nadzorczego, gdy tylko dowiesz się o naruszeniu, a 'nie możemy tego wykluczyć' jest bliżej tej wiedzy niż spokoju.

Dla podmiotów kluczowych i ważnych na mocy NIS2 incydent tej wagi uruchamia własny zegar wczesnego ostrzegania i zgłoszenia, a organy coraz częściej oczekują dowodów wykrycia, a nie tylko dziennika poprawek. Wymuszona automatyczna aktualizacja to obrona, której nie wybrałeś; to, czy potem sprawdziłeś naruszenie, zostaje w twoim dzienniku.

Kontrola, która musi nastąpić teraz

Potwierdź, że witryna działa na 6.9.5 lub 7.0.2, a następnie potraktuj okno ekspozycji jako właściwą pracę. Przejrzyj konta administratorów i hasła aplikacji utworzone w lipcu, sprawdź zaplanowane zadania i niedawno zmienione pliki PHP oraz pobierz dzienniki serwera WWW pod kątem nietypowych żądań POST do REST API w okolicach daty ujawnienia.

Jeśli korzystasz z zarządzanego WordPressa, poproś dostawcę na piśmie o datę wgrania poprawki i o to, czy widział próby wykorzystania wobec twojej witryny. Uczciwa odpowiedź na 'czy nas trafiono' rzadko przychodzi od razu, ale właściciele, którzy pytają w tym tygodniu, to ci, którzy w przyszłym kwartale nie będą tłumaczyć cichego naruszenia.

Czytaj dalej: Martwy budynek kosztuje więcej niż okup  |  Sandbox zaatakowano miesiąc przed ostrzeżeniem