21 października 2026 r. twórcy PHP wydali poprawki dla dwóch krytycznych błędów, które otrzymały wspólną nazwę php2shell. Jeszcze tego samego dnia CERT Polska ostrzegł, że luki CVE-2026-109618 i CVE-2026-109619 pozwalają na zdalne wykonanie dowolnych poleceń na serwerze, a pierwsze masowe próby ich wykorzystania już trwają. Centralny Ośrodek Informatyki na wszelki wypadek czasowo wyłączył część stron BIP.
Najważniejsza rzecz dla właściciela firmowej strony jest mało intuicyjna: aktualizacja WordPressa, wtyczek czy motywu niczego tu nie zmienia. Dziurawy jest sam PHP, czyli silnik, na którym działa strona. Trzeba go zaktualizować na serwerze – a to, kto ma to zrobić, zależy od tego, gdzie stoi Twoja strona.
Najważniejsze w skrócie:
- Podatne są według CERT Polska wszystkie wersje PHP od 5.4 wzwyż – a więc praktycznie każda strona na WordPressie, Joomli, Drupalu czy WooCommerce.
- Bezpieczne wersje to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla starszych gałęzi (m.in. 5.6, 7.0, 8.0, 8.1) poprawek trzeba szukać u dostawcy systemu lub hostingu.
- Jedyną pełną ochroną jest aktualizacja PHP. Zmiany w konfiguracji tylko zmniejszają ryzyko.
- Po aktualizacji warto sprawdzić, czy serwer nie został przejęty wcześniej – poprawka nie usuwa tego, co atakujący zdążył zostawić.
Mapa artykułu
Spis treści
Co się stało i dlaczego to tak poważne
Obie luki dotyczą błędów w zarządzaniu pamięcią w samym interpreterze PHP. W praktyce oznacza to, że odpowiednio przygotowane żądanie do strony może skończyć się wykonaniem poleceń systemowych na serwerze. Atakujący nie potrzebuje do tego loginu ani hasła do panelu.
Skala jest ogromna, bo PHP obsługuje większość stron internetowych, dla których da się ustalić technologię serwera. Według ITwiz reakcje były widoczne w całej Europie: część serwisów administracji wyłączyła Holandia, Dania i Finlandia, a w Polsce COI czasowo wyłączył strony BIP działające w systemie SSDIP, żeby wdrożyć zabezpieczenia.
Jest też drugi powód do pośpiechu. Po publikacji poprawek atakujący mogą porównać starą i nową wersję kodu i dokładnie zobaczyć, co zostało naprawione. Każdy dzień zwłoki działa na ich korzyść.
Kto powinien zaktualizować PHP – Ty czy hosting?
| Gdzie działa strona | Kto aktualizuje PHP | Co sprawdzić |
|---|---|---|
| Hosting współdzielony | Dostawca hostingu | Czy w panelu wybrana jest wspierana wersja PHP – stare wersje mogą nie dostać poprawki |
| VPS lub serwer dedykowany | Administrator serwera – Ty albo firma IT | Pakiety PHP z repozytorium systemu, restart PHP-FPM lub serwera WWW |
| Kontenery (Docker) | Zespół, który buduje obrazy | Przebudowa obrazu na poprawionej wersji i ponowne wdrożenie |
| Gotowe urządzenia i aplikacje z PHP w środku | Producent | Komunikaty producenta i dostępność aktualizacji |
Na hostingu współdzielonym najczęstszy problem to stara wersja PHP wybrana lata temu, bo „strona na nowszej się sypała”. Dla takich wersji poprawka może w ogóle nie powstać. Wtedy trzeba przenieść stronę na wspieraną wersję – i to jest dobry moment, żeby sprawdzić zgodność motywu i wtyczek.
Jak sprawdzić, czy Twoja wersja jest bezpieczna
- W panelu hostingu – sekcja „Wersja PHP” lub „Konfiguracja PHP” przy domenie.
- W WordPressie – Narzędzia → Zdrowie witryny → Informacje → Serwer.
- Na własnym serwerze – polecenie
php -v. Uwaga: wersja w konsoli może być inna niż ta, która obsługuje stronę (PHP-FPM). Sprawdź oba.
Wersja jest bezpieczna, jeśli to co najmniej 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 w swojej gałęzi albo wersja z oficjalną poprawką od dostawcy systemu (np. pakiet z łatką bezpieczeństwa w dystrybucji Linuksa).
Nie możesz zaktualizować od razu? Tymczasowe ustawienia
CERT Polska podał ustawienia, które ograniczają ryzyko, ale go nie usuwają:
memory_limit: -1, jeśli zasoby na to pozwalają, w przeciwnym razie co najmniej 128M,post_max_size: 8M lub mniej,max_input_vars: 1000 lub mniej,session.upload_progress.enabled: Off.
Zmniejszenie post_max_size może zablokować wysyłanie większych plików przez formularze czy panel – to cena za czas do aktualizacji. Dodatkową warstwą może być firewall aplikacyjny (WAF) z regułami dla tej podatności, ale też tylko jako pomost.
Po aktualizacji: czy ktoś już nie był w środku?
Poprawka zamyka drzwi, ale nie wyprowadza intruza, który wszedł wcześniej. Po aktualizacji warto sprawdzić:
- nowe lub zmienione pliki PHP w katalogach strony, zwłaszcza w folderach z uploadem,
- nowe konta administratorów w CMS i nowe klucze SSH na serwerze,
- zadania cron, których nikt nie dodawał,
- logi serwera WWW z okresu po 21 października pod kątem nietypowych żądań,
- ruch wychodzący z serwera – przejęte maszyny często łączą się z serwerem atakującego.
Jeśli coś budzi wątpliwości, nie sprzątaj na własną rękę – najpierw zabezpiecz logi. Ślady włamania można zgłosić do CERT Polska przez incydent.cert.pl, a firmy objęte ustawą o KSC powinny ocenić, czy to incydent poważny wymagający zgłoszenia w 24 godziny.
Lekcja na przyszłość: kto pilnuje serwera Twojej strony?
php2shell pokazał prostą rzecz: strona firmowa to nie tylko WordPress i wtyczki. To także PHP, serwer WWW, system operacyjny i certyfikaty. Jeśli nikt nie ma w obowiązkach śledzenia komunikatów bezpieczeństwa i aktualizacji tych warstw, firma dowiaduje się o problemie z mediów albo od klienta, który zobaczył dziwną treść na stronie. O typowych sygnałach, że strona jest niebezpieczna, pisaliśmy w artykule czy strona jest bezpieczna.
FAQ – php2shell
Czy wystarczy zaktualizować WordPressa?
Nie. Podatność jest w samym PHP na serwerze, a nie w WordPressie. Aktualizacja CMS i wtyczek jest potrzebna, ale tej luki nie zamyka.
Które wersje PHP są bezpieczne?
8.5.12, 8.4.27, 8.3.36 i 8.2.35 oraz nowsze w tych gałęziach, a także wersje z poprawką wydaną przez dostawcę systemu dla starszych gałęzi.
Mam stronę na hostingu. Czy muszę coś robić?
Tak – sprawdź w panelu, jaką wersję PHP masz wybraną, i upewnij się, że dostawca wgrał poprawki. Jeśli korzystasz z bardzo starej wersji, przejdź na wspieraną.
Czy luki są już wykorzystywane?
CERT Polska informował o pierwszej fali masowych prób wykorzystania podatności. Dlatego po aktualizacji warto sprawdzić serwer pod kątem śladów włamania.
Co jeśli strona działa na PHP 7.4 i nie da się jej przenieść?
Trzeba szukać poprawki u dostawcy systemu (niektóre dystrybucje łatają starsze wersje) albo zaplanować pilną migrację. Do tego czasu – tymczasowe ustawienia, WAF i ścisły monitoring.
