PHP2Shell: jedno żądanie POST, zero śladów i 2,6 miliona wystawionych serwerów

21 października 2026 roku Fundacja PHP wydała awaryjne poprawki na dwie krytyczne podatności typu memory corruption w rdzeniu PHP, określane wspólną nazwą PHP2Shell:

• CVE-2026-109618 (CVSS 9,2)

• CVE-2026-109619 (CVSS 9,2)

Obie pozwalają na zdalne wykonanie kodu bez uwierzytelnienia. Znaleźli je badacze z Calif, OpenAI i Wiz, a dotyczą każdego wydania z serii PHP 7.x i 8.x.

Powód, dla którego ta sprawa znaczy więcej niż typowe krytyczne CVE, leży w umiejscowieniu błędu. To nie jest luka w WordPressie, Magento ani we wtyczce. To luka w silniku, na którym one wszystkie działają. Analiza CrowdStrike ujmuje to bez ogródek: nie ma tu uwierzytelnienia do obejścia ani sesji do przejęcia, a ekspozycja nie zależy od tego, jakiego CMS-a, frameworka czy wtyczek używasz.

Cloudflare zwraca uwagę, że z PHP korzysta blisko 70% wszystkich stron internetowych.

To nie jest historia o reakcji pojedynczego dostawcy zabezpieczeń. To podatność o zasięgu całego internetu w najpowszechniej wdrożonym środowisku uruchomieniowym sieci WWW, wraz z procesem ujawnienia, który się rozpadł, i eksploatacją, która zaczęła się przed publikacją.

Co się wydarzyło

Na czym polega podatność

Fundacja PHP wyjaśniła, że oba błędy siedzą w zarządzaniu pamięcią i obsłudze błędów, czyli w częściach PHP, których dotyka niemal każde żądanie. To centralne położenie zadecydowało o ich powadze, a zarazem sprawiło, że trudno było je naprawić bez psucia kompatybilności, obniżania wydajności lub wymuszania zmian w rozległym ekosystemie rozszerzeń firm trzecich.

CrowdStrike potwierdził testami, że jedno nieuwierzytelnione żądanie POST wystarczy, by proces roboczy Apache mod_php uruchomił powłokę i wykonał polecenie wybrane przez napastnika, bez potrzeby istnienia podatnego kodu aplikacji. Firma odtworzyła błąd przy memory_limit obniżonym do 16M i post_max_size podniesionym do 64M wyłącznie po to, by zmniejszyć rozmiar testowego ładunku, zaznaczając, że ta sama luka jest osiągalna większymi ładunkami przy standardowych limitach.

Praktyczna konsekwencja: ryzykiem jest każdy osiągalny punkt końcowy PHP na serwerze, łącznie ze statycznymi formularzami, ścieżkami logowania i health checkami. Nie trzeba szukać podatnego endpointu, bo nada się dowolny.

Problem z materiałem dowodowym

To szczegół, który powinien najbardziej zaniepokoić zespoły reagowania na incydenty.

Według CrowdStrike procesy robocze pozostają stabilne, odpowiedzi zwracają HTTP 200, a logi aplikacji nie notują żadnych anomalii, ponieważ żaden kod aplikacji nigdy się nie wykonał. Jedynym śladem po stronie serwera jest pojedynczy błąd krytyczny limitu pamięci w logu błędów serwera WWW, rutynowo odrzucany jako szum.

Innymi słowy, atak nie zostawia obrońcom praktycznie niczego. Jeśli próbujesz ustalić po fakcie, czy zostałeś zaatakowany, telemetria webowa prawdopodobnie Ci tego nie powie.

Ujawnienie poszło źle

Skoordynowane ujawnienie zaplanowano na 22 października, godz. 14:00 UTC. Plan nie przetrwał.

• Szczegóły CVE oraz działający kod proof-of-concept wyciekły przed czasem, co skłoniło Fundację PHP do przyspieszenia wydania o jeden dzień.

• Niezależnie od tego firma Chainguard jednostronnie złamała embargo i opublikowała gotowe obrazy zawierające poprawkę. Chainguard otrzymał łatkę wcześniej po to, by jego użytkownicy mogli zaktualizować się w momencie ujawnienia. Zarzut Fundacji PHP jest precyzyjny i wart zrozumienia: każdy napastnik mógł teraz studiować poprawkę w postaci binarnej, podczas gdy wszyscy pozostali użytkownicy PHP wciąż czekali na wydanie.

• ELLIO odnotowało pierwsze żądanie PHP2Shell o 8:36 UTC 21 października, niecałą godzinę po publikacji obrazów Chainguard.

Eksploatacja zaczęła się przed ujawnieniem

Zespół Amazon Threat Intelligence wykrył próbę eksploatacji wymierzoną w swój honeypot MadPot już 17 października, cztery dni przed publicznym udostępnieniem poprawek, z adresu IP zlokalizowanego w Australii i powiązanego z komercyjną siecią anonimizującą.

CJ Moses, CISO Amazona, zauważył, że atakowanie honeypota z anonimizowanego adresu w czasie obowiązywania embarga wskazuje na działanie grupy przestępczej, choć pozostaje niejasne, skąd sprawca wziął informacje o exploicie przed ujawnieniem.

Po wydaniu poprawek eksploatacja szybko stała się masowa. Amazon wskazał najwcześniejszą próbę po publikacji na około 02:00 UTC 21 października, po której nastąpiło sześć godzin prób z anonimizowanej infrastruktury, a różnorodność ładunków wskazuje na wiele niezależnych grup.

Skala ekspozycji

Analiza VulnCheck obejmująca cały internet wykryła PHP na 2 608 039 hostach dostępnych z sieci:

Ponad milion hostów dostępnych z internetu działa na wersjach PHP, które nigdy nie dostaną poprawki na tę lukę.

Dlaczego to ma znaczenie

Powierzchnią ataku jest sama sieć WWW. Podatność w CMS dotyczy użytkowników tego CMS-a. Podatność w rdzeniu PHP dotyczy wszystkich korzystających z PHP, niezależnie od tego, co na nim zbudowali. Cloudflare już zaobserwował, że napastnicy mutują ładunki, żeby omijać reguły WAF, a platforma Pantheon zgłosiła zablokowanie ponad 60 000 podejrzanych żądań sondujących te luki.

Niewidoczna eksploatacja łamie standardowy scenariusz powypadkowy. Gdy jedynym artefaktem jest linijka w logu błędów wyglądająca jak rutynowy szum, pytanie „czy nas dotknęło" przestaje być proste. Organizacje będą potrzebowały telemetrii na poziomie procesów, a nie logów webowych, i dokładnie to zalecało FBI: obserwujcie procesy PHP nieoczekiwanie uruchamiające powłoki poleceń lub pobierające pliki.

Skoordynowane ujawnianie jest kruche przy tej skali. Gdy kilkunastu dostawców potrzebuje wcześniejszego dostępu, żeby przygotować zabezpieczenia, rośnie też liczba podmiotów mogących złamać embargo. Jedna firma publikująca za wcześnie skróciła przewagę obrońców do niespełna godziny.

Sztuczna inteligencja działa dziś po obu stronach cyklu życia podatności. Te luki znaleźli z pomocą AI badacze z OpenAI, Wiz i Calif, i to jest strona obronna. Moses z Amazona opisał stronę ofensywną: zależność od wąskiej grupy zdolnych aktorów budujących exploity słabnie, bo analiza wspierana przez AI czyni przerobienie różnicy w kodzie poprawki na działający exploit tańszym, więc więcej podmiotów może działać w ciągu godzin, a nawet minut.

To właśnie ta zmiana strukturalna jest warta zapamiętania. Okno między wydaniem poprawki a istnieniem uzbrojonego exploita nie mierzy się już w tygodniach.

PHP po końcu wsparcia jest dziś czynnym obciążeniem. Ponad miliona wystawionych hostów nie da się załatać. Dla tych systemów pozostają trzy opcje: aktualizacja, wirtualne łatanie na brzegu sieci albo zdjęcie z internetu.

Kogo to dotyczy

• Każdej organizacji uruchamiającej PHP 7.x lub 8.x na serwerze dostępnym z internetu, czyli większości sieci WWW.

• Instalacji WordPress, Magento, Drupal, Laravel i Joomla, nie z powodu błędu w tych platformach, lecz dlatego że działają na podatnym środowisku uruchomieniowym.

• Firm hostingowych i agencji zarządzających dużą liczbą stron klientów na współdzielonej infrastrukturze.

• Organizacji używających PHP bez wsparcia, według VulnCheck ponad milion hostów dostępnych z internetu, które nie mają dostępnej poprawki.

• Każdego, kto ma PHP wbudowane w urządzenie, dystrybucję systemu lub produkt dostawcy. To długi ogon, przed którym ostrzegał Ilkka Turunen z Sonatype, i najtrudniejsza kategoria do zinwentaryzowania.

Co powinny zrobić organizacje

Natychmiast

1. Zaktualizuj PHP do wersji z poprawką. CISA i brytyjskie NCSC wezwały organizacje do jak najszybszego wdrożenia łatek albo rozważenia odłączenia podatnych systemów.

2. Znajdź swoje PHP. Zinwentaryzuj każdą usługę dostępną z internetu korzystającą z PHP, łącznie z instancjami wbudowanymi w urządzenia i produkty dostawców. Nie załatasz tego, czego nie znalazłeś.

3. Jeśli nie możesz łatać, ogranicz ryzyko na brzegu sieci. AWS, Cloudflare, Akamai, Fastly i Imperva opublikowały zalecenia dla WAF. Traktuj je jako rozwiązanie tymczasowe, skoro Cloudflare już obserwuje mutacje ładunków obliczone na ich obejście.

4. Sprawdź, czy jesteś podatny, korzystając z narzędzia opublikowanego przez OpenAI do testowania strony lub lokalnego pliku binarnego PHP.

5. Potraktuj priorytetowo wersje bez wsparcia. PHP 7.3 i starsze nie zostaną naprawione.

Wykrywanie, przy braku użytecznej telemetrii webowej

6. Monitoruj procesy PHP uruchamiające powłoki. Wytyczna FBI jest konkretna: obserwujcie PHP nieoczekiwanie uruchamiające powłoki poleceń lub pobierające pliki i upewnijcie się, że monitoring procesów faktycznie działa.

7. Nie polegaj na logach dostępowych serwera WWW. Udana eksploatacja zwraca HTTP 200 bez żadnych anomalii w logach aplikacji.

8. Przeszukaj logi błędów pod kątem błędów krytycznych limitu pamięci, które mogą być jedynym artefaktem po stronie serwera. Ich skupiska traktuj jako powód do analizy, a nie jako szum.

9. Zaimportuj treści detekcyjne dostawców. CrowdStrike dodał wykrywanie PHP2Shell do Falcon Next-Gen SIEM, a analogiczne materiały udostępniła większość dużych dostawców.

10. Poluj na znaną infrastrukturę skanującą, w tym na user agent php2shell-scan/109618 zidentyfikowany przez VulnCheck, i przejrzyj ruch wstecz do 17 października.

Zakładaj kompromitację tam, gdzie ekspozycja trwała długo

11. Jeśli niezałatany serwer PHP dostępny z internetu działał 21 października, uznaj kompromitację za prawdopodobną i prowadź analizę na poziomie hosta, zamiast wnioskować z czystych logów webowych, że nic się nie stało.

12. Sprawdź mechanizmy utrwalania dostępu, w tym webshelle, zmodyfikowane zadania cron, nowe konta i połączenia wychodzące z procesów serwera WWW.

13. Zmień poświadczenia i sekrety osiągalne z serwera WWW. NSA zwróciła uwagę, że te luki mogą dać napastnikom bezpośrednią ścieżkę do systemu plików lub bazy danych serwera.

Podsumowanie i kluczowa lekcja

Jedno nieuwierzytelnione żądanie POST, wysłane do dowolnego punktu końcowego PHP, które wykonuje polecenie i zostawia w logu dostępowym wpis HTTP 200. To cały atak. Żadnej podatnej wtyczki do znalezienia, żadnego logowania do pokonania, żadnego użytecznego śladu.

Lekcja: gdy podatność siedzi w środowisku uruchomieniowym, a nie w aplikacji, wszystkie założenia oparte na obronie warstwy aplikacyjnej przestają obowiązywać. Reguły WAF celują w znane kształty ładunków, a napastnicy już wokół nich krążą. Logi dostępowe pokazują sukces. Logi aplikacji nie pokazują nic, bo aplikacja się nie uruchomiła. Obrona musi zejść warstwę niżej, do zachowania procesów na hoście.

Druga lekcja dotyczy czasu. Próbę eksploatacji odnotowano cztery dni przed ujawnieniem, ze strony kogoś, kto nie powinien był dysponować tą wiedzą. Po wydaniu poprawek wiele grup działało w ciągu godzin, a pierwsze żądanie padło niecałą godzinę po złamaniu embarga przez jednego dostawcę. Ocena Amazona brzmi tak: analiza wspierana przez AI skraca odstęp między łatką a exploitem z przyczyn strukturalnych, które się nie cofną.

Jeśli Twój proces aktualizacji zakłada kilka dni zapasu po krytycznym ostrzeżeniu, to założenie zawiodło publicznie już dwa razy w ciągu tygodnia.

Dwie rzeczy do zrobienia dziś: znajdź każdą instancję PHP wystawioną przez Ciebie do internetu, łącznie z tymi ukrytymi w cudzych produktach, oraz sprawdź, czy Twój monitoring zauważyłby proces PHP uruchamiający powłokę.