PHP2Shell: 70% internetu, 22 mln serwerów i 4 dni przewagi atakujących.

Co się stało, w jednym akapicie.

PHP2Shell to wspólna nazwa dwóch błędów w samym rdzeniu PHP: CVE-2026-109618 (uszkodzenie pamięci przy obsłudze przekroczenia limitu pamięci) i CVE-2026-109619 (use-after-free, czyli korzystanie z już zwolnionej pamięci). Obie mają ocenę 9,2 na 10 w skali CVSS v4.0; firma watchTowr oceniła je nawet na 10,0. Odpowiednio spreparowane zapytanie HTTP mogło uruchomić na serwerze dowolny kod, zanim aplikacja w ogóle zaczęła działać. W konfiguracji Apache z mod_php nie miało więc znaczenia, czy na serwerze stoi WordPress, Drupal, Laravel, czy strona napisana od zera. Błąd siedział w PHP od wersji 5.4, czyli od ponad dekady.

Liczby, które warto zapamiętać.

Uwaga do „70% internetu”: ta liczba, powtarzana w nagłówkach od CNN po Fortune, opisuje zasięg PHP, a nie liczbę serwerów, które dało się przejąć. Podatność zależała od wersji i konfiguracji. Mimo to nawet ostrożne szacunki to miliony maszyn.

Jak często PHP wydaje poprawki bezpieczeństwa.

Częściej, niż zakłada większość właścicieli stron. Każda wspierana gałąź PHP dostaje nowe wydanie mniej więcej co miesiąc. PHP 8.4 zadebiutowało w listopadzie 2024 roku, a październikowa poprawka miała numer 8.4.27, czyli 27 wydań poprawkowych w niespełna dwa lata, średnio co 3–4 tygodnie. W 2026 roku krytyczne poprawki pojawiły się co najmniej dwa razy: w maju (8.4.21, m.in. CVE-2026-6722 i CVE-2026-7261 w rozszerzeniu SOAP) i teraz w październiku.

Tempo rośnie. Według serwisu stack.watch w 2025 roku opublikowano 15 podatności PHP, a w 2026 roku do końca października już 31, przy wyższej średniej ocenie krytyczności. PHP Foundation pisze wprost, że zespół bezpieczeństwa dostaje dziś znacznie więcej zgłoszeń niż kiedyś, i łączy to z badaniami wspieranymi przez AI. W maju 2026 fundacja powołała osobny Ecosystem Security Team.

Jeśli Twoja strona nie dostała aktualizacji PHP od pół roku, to statystycznie ominęło ją około sześciu wydań poprawkowych.

Oś czasu: atakujący byli pierwsi.

• Sierpień 2026 — niezależnie od siebie błąd znajdują badacz Ryan Austin z firmy Calif oraz zespół Wiz. Obie strony korzystały z narzędzi AI. Zgłoszenie trafia do zespołu bezpieczeństwa PHP, który przygotowuje poprawkę w trybie poufnym.
• 17 października — honeypoty Amazona (MadPot) rejestrują pierwszą próbę wykorzystania luki. To cztery dni przed publikacją; do dziś nie wiadomo, skąd atakujący znali szczegóły.
• 20 października — anonimowy wpis na Hacker News zapowiada „dwie krytyczne luki RCE w PHP”. Po kilku godzinach watchTowr potwierdza, że są prawdziwe. O 19:30 UTC PHP publikuje wstępne ostrzeżenie i przyspiesza wydanie o jeden dzień.
• 21 października, rano — Cloudflare włącza reguły blokujące atak dla wszystkich klientów, również darmowych, około 9 godzin przed publikacją.
• 21 października, 14:00 UTC — wychodzą PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Według szefa Cloudflare liczba prób ataku rośnie z tysięcy (10 godzin przed publikacją) do dziesiątek tysięcy w 45 minut po niej, setek tysięcy w ciągu 2 godzin i milionów chwilę później.
• 22 października — Centralny Ośrodek Informatyki czasowo wyłącza strony BIP działające w systemie SSDIP (ssdip.bip.gov.pl). Po południu zaczyna je stopniowo przywracać.

Najważniejsza liczba z tej osi czasu: ok. 18 godzin od ostrzeżenia do poprawki i 45 minut od publikacji do skoku liczby ataków o rząd wielkości. Firma, która sprawdza aktualizacje raz w miesiącu, w takim scenariuszu nie ma szans zdążyć.

Jak głośno było o PHP2Shell.

Bardzo, i to poza branżą IT. Ostrzeżenia wydały m.in. amerykańska NSA (z zaleceniem „zaktualizuj albo wyłącz system”), brytyjskie NCSC, CERT-EU, singapurska CSA i CERT Polska. Według Computer Weekly Finlandia, Holandia, Francja i Dania prewencyjnie zdjęły z sieci część serwisów rządowych. W Polsce pilny komunikat wydało Ministerstwo Cyfryzacji, a temat trafił do RMF24, Rzeczpospolitej, money.pl i Wprost. Za granicą pisały o nim CNN, Fortune i Newsweek, a część mediów ochrzciła sytuację „PHPokalipsą”.

Dla równowagi: do 23 października nie potwierdzono publicznie żadnego udanego włamania przez PHP2Shell, a luki nie trafiły jeszcze do katalogu aktywnie wykorzystywanych podatności amerykańskiej CISA. Sophos wycofał swój wcześniejszy raport o udanym ataku; jego telemetria pokazała tylko skanowanie i nieudane próby, m.in. z ładunkiem botnetu Mirai. Brak potwierdzonych włamań to jednak głównie zasługa szybkiej reakcji: poprawek, reguł WAF i wyłączania serwisów.

Co skutecznie chroniło, a co nie.

Najgorzej mieli właściciele stron na nieaktualnych gałęziach. Wersje 7.4–8.1 dostały tylko łatkę w kodzie źródłowym, bez gotowych paczek, a dla wersji 5.4–7.3 nie ma żadnej poprawki. Według różnych skanów od 45% do ponad 70% stron, które ujawniają swoją wersję PHP, działa na gałęziach bez wsparcia. Dla nich jedynym ratunkiem jest migracja albo płatne wsparcie rozszerzone.

Kto przeszedł przez to spokojnie.

Wspólny mianownik firm, dla których PHP2Shell był zwykłym czwartkiem, jest prosty i mało efektowny:

• Wiedziały, co mają. Lista serwisów z wersją PHP i odpowiedzialną osobą. CERT Polska zaczął swoje zalecenia właśnie od inwentaryzacji.
• Były na wspieranej gałęzi PHP. Aktualizacja z 8.4.26 do 8.4.27 to kwestia minut. Skok z 7.4 na 8.4 w środku kryzysu to projekt na tygodnie.
• Miały powtarzalne wdrożenie. Przebudowanie obrazu Dockera albo jedno polecenie menedżera pakietów, a nie ręczne grzebanie na serwerze.
• Ktoś śledził komunikaty. Wstępne ostrzeżenie PHP pojawiło się dzień przed poprawkami. Kto je przeczytał, miał czas, żeby zaplanować okno serwisowe i włączyć tymczasowe zabezpieczenia.
• Miały kopie zapasowe i testową kopię strony. Dzięki temu aktualizację dało się sprawdzić i wdrożyć bez strachu.

To dokładnie te same elementy, które opisuję w tekście o regularnych aktualizacjach Drupala. PHP2Shell pokazał tylko, że dotyczą one całego stosu technologicznego, nie samego CMS-a.

Monitorowanie zagrożeń to nie paranoja, tylko higiena.

Łatwo uznać PHP2Shell za wyjątek, ale liczby mówią coś innego. Krytyczne luki w PHP zdarzały się już wcześniej (choćby CVE-2024-4577 w PHP-CGI w 2024 roku), poprawki wychodzą co miesiąc, a narzędzia AI przyspieszają szukanie błędów po obu stronach. Wiz pisze, że jeden badacz z pomocą AI zrobił w tydzień to, co wcześniej zajmowało zespołowi miesiące. Te same narzędzia mają atakujący, a czas od publikacji do masowych ataków liczy się w minutach.

W praktyce oznacza to trzy rzeczy: aktualny stos (wspierana wersja PHP, systemu i CMS-a), ktoś, kto śledzi komunikaty bezpieczeństwa i reaguje w ciągu godzin, a nie tygodni, oraz infrastruktura, w której aktualizacja jest rutyną, a nie operacją na otwartym sercu. Jeśli nie masz na to czasu, tym zajmuje się stała opieka techniczna. Ile to kosztuje, opisuję w tekście ile kosztuje utrzymanie strony Drupal.

Najczęściej zadawane pytania.

Czy aktualizacja WordPressa, Drupala lub wtyczek chroni przed PHP2Shell? Nie. Luka siedzi w samym interpreterze PHP, a nie w CMS-ie. Trzeba zaktualizować PHP na serwerze (lub przebudować obraz kontenera) i zrestartować Apache albo PHP-FPM. Aktualizacja CMS-a, wtyczek czy composer update niczego tu nie zmienia.

Które wersje PHP są bezpieczne? PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 lub nowsze. Dystrybucje Linuksa często przenoszą poprawkę do własnych pakietów pod innym numerem wersji, więc sprawdź komunikat bezpieczeństwa swojej dystrybucji. Wersje 7.4–8.1 dostały tylko łatkę w kodzie źródłowym, a 5.4–7.3 nie dostały żadnej.

Czy WAF (np. Cloudflare) wystarczy zamiast aktualizacji? Nie. Reguły WAF kupują czas, ale same firmy, które je wdrożyły, nazywają je rozwiązaniem tymczasowym. Chronią tylko ruch, który przez nie przechodzi, i tylko znane warianty ataku. Jedyną pełną ochroną jest poprawiona wersja PHP.

Skąd mam wiedzieć, że moja strona była podatna? Wystarczy znać wersję PHP na serwerze: jeśli była starsza niż wersje poprawione z 21 października 2026, strona była podatna. Jeżeli nie wiesz, jaką wersję PHP masz ani kto odpowiada za jej aktualizację, to najważniejszy wniosek z tej historii.

Podsumowanie.

PHP2Shell nie był pierwszą krytyczną luką w PHP i nie będzie ostatnią. Różnicę między „zaktualizowaliśmy przed obiadem” a „wyłączyliśmy stronę na dobę” zrobiło nie szczęście, tylko to, czy ktoś wcześniej zadbał o aktualny stos, inwentaryzację i proces aktualizacji. Jeśli chcesz sprawdzić, jak wygląda to u Ciebie, napisz. Zacznę od tego, jaką wersję PHP faktycznie ma Twoja strona.

Źródła

• The PHP Foundation — wydanie poprawek z 21.10.2026, Ecosystem Security Team
• Wiz Research — opis odkrycia, zakres wersji od 5.4, rola AI
• Unit 42 (Palo Alto Networks) — 22,6 mln potencjalnie podatnych instancji
• Cloudflare — reguły WAF i ich ograniczenia; The Next Web — skala prób ataku
• Infosecurity Magazine — próba ataku z 17.10 w danych Amazon MadPot
• Tenable i watchTowr — FAQ, status w katalogu CISA KEV
• Computer Weekly — ostrzeżenia NSA, NCSC, CERT-EU i wyłączenia serwisów rządowych
• Rzeczpospolita i ITwiz — komunikat Ministerstwa Cyfryzacji, wyłączenie BIP w SSDIP
• W3Techs — udział PHP i rozkład wersji
• TechnologyChecker i CybelAngel — udział stron na wersjach bez wsparcia
• stack.watch — liczba podatności PHP w latach 2025–2026

Stan na 24.10.2026. Sytuacja wciąż się rozwija; część liczb pochodzi od pojedynczych firm i różni się metodologią.