PHP2Shell: krytyczne luki w PHP i co zrobić, jeśli masz stronę na WordPressie

Co się stało 21 października 2026

Zespół PHP wydał awaryjne wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, które łatają dwie krytyczne luki: CVE-2026-109618 i CVE-2026-109619. W mediach branżowych przylgnęła do nich nazwa PHP2Shell. Obie pozwalają na zdalne wykonanie kodu bez logowania, czyli na przejęcie serwera przez kogoś, kto nie ma do niego żadnego dostępu. Obie dostały ocenę 9,2 w skali CVSS 4.0, a komunikat PHP zaczyna się od słów „update now”.

W uproszczeniu chodzi o dwie rzeczy. Pierwsza luka dotyczy sytuacji, w której PHP-owi kończy się pamięć w trakcie przyjmowania żądania – na przykład przy specjalnie spreparowanym wysyłaniu pliku – a sprzątanie po przerwanym żądaniu potraktuje niedokończone dane jak poprawne. Druga dotyczy stanu, który przeżywa jedno żądanie i zostaje użyty przez następne obsługiwane przez ten sam proces, choć pamięć pod nim została już zwolniona.

Według badaczy Wiz błędy siedziały w PHP od bardzo dawna, a dopiero modele AI obniżyły próg na tyle, że ktoś zamienił je w działający atak. Amazon odnotował w swojej sieci pułapek próbę ataku już 17 października, cztery dni przed publikacją poprawek.

Kogo to dotyczy

Krótka odpowiedź: każdej strony, której serwer uruchamia PHP przy obsłudze wejść z internetu. Komunikat PHP wymienia wprost PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed, czyli wszystkie popularne sposoby uruchamiania PHP na hostingu.

• Największe ryzyko: mod_php. Pokazano atak, w którym jedno żądanie bez logowania uruchamia lukę, zanim wykona się choćby linijka kodu samej strony. Nie ma więc znaczenia, czy WordPress, motyw i wtyczki są aktualne.
• PHP-FPM jest trudniejszym celem, bo przy awarii na starcie zamyka proces roboczy. Druga luka działa jednak także tutaj, gdy aplikacja da się doprowadzić do błędu krytycznego.
• Wersje bez poprawki: PHP 8.1 i starsze nie dostają już aktualizacji od zespołu PHP. Dla 7.4, 8.0 i 8.1 opublikowano tylko minimalne łatki w kodzie źródłowym, przydatne dla administratorów, którzy sami kompilują PHP. Na typowym hostingu współdzielonym nikt tego za Ciebie nie zrobi.

Stan na 22 października według Rapid7: publiczne exploity działają tylko na konkretnych zestawach systemu, wersji PHP i serwera, żaden nie jest uniwersalny. To dobra wiadomość na dziś i słaba pociecha na za tydzień. Przy lukach tej wagi uniwersalny exploit pojawia się zwykle szybko, a boty skanujące internet nie sprawdzają, czy strona jest ważna.

Problem, o którym mało kto mówi: stare PHP pod WordPressem

WordPress.org publikuje, na jakich wersjach PHP działają strony z WordPressem. Według danych z 23 października 2026:

• 34,7 % stron z WordPressem działa na PHP 8.1 lub starszym, czyli na wersjach, dla których zespół PHP nie wyda poprawki PHP2Shell,
• sama wersja 7.4, bez wsparcia od listopada 2022, to wciąż 15,5 % stron,
• kolejne 23,5 % działa na PHP 8.2, które dostało poprawkę teraz, ale 31 grudnia 2026 traci wsparcie. Jeśli nic się nie zmieni, od nowego roku ponad połowa WordPressów (58 %) będzie działać na PHP bez poprawek bezpieczeństwa.

Stare PHP rzadko jest wynikiem świadomej decyzji. Zwykle strona po prostu działa, nikt jej nie dotyka, a podniesienie wersji grozi tym, że stara wtyczka albo motyw przestaną działać. Właściciel nie wie więc nawet, że ma problem.

Co zrobić dziś, jeśli masz stronę na WordPressie

1. Sprawdź dokładną wersję PHP. W WordPressie: Kokpit → Narzędzia → Zdrowie witryny → Informacje → Serwer. Bezpieczne są wersje 8.2.35, 8.3.36, 8.4.27 i 8.5.12 lub nowsze. Sam numer „8.3” nie wystarczy, liczy się ostatnia cyfra.
2. Jeśli masz PHP 8.1 lub starsze, przełącz stronę w panelu hostingu na 8.3 albo 8.4. Najpierw zrób kopię zapasową i, jeśli hosting na to pozwala, sprawdź zmianę na kopii strony. Stare wtyczki i motywy potrafią się przy tym wysypać, dlatego nie warto tego robić w piątek po południu bez kopii.
3. Jeśli wersja jest wspierana, ale bez najnowszej łatki, napisz do hostingu z pytaniem, kiedy wgrają poprawione PHP. Na hostingu współdzielonym aktualizację robi firma hostingowa, nie Ty.
4. Jeśli strona stoi za Cloudflare, sprawdź, czy masz włączone zarządzane reguły WAF. Cloudflare wdrożył reguły na znane warianty ataku, także w darmowym planie. To osłona na czas aktualizacji, a nie jej zamiennik.
5. Po aktualizacji sprawdź, czy nikt nie był szybszy. Poprawka zamyka drzwi, ale nie wyrzuca kogoś, kto już wszedł. Objawy i siedem prostych kontroli opisaliśmy w tekście Jak sprawdzić, czy WordPress jest zainfekowany.

Zespół PHP podaje też ustawienia, które ograniczają konkretne ścieżki ataku, między innymi wyłączenie session.upload_progress.enabled i niski post_max_size. Sam zaznacza jednak, że nie czynią one instalacji bezpieczną, a na hostingu współdzielonym większości z nich i tak nie zmienisz. Jedynym pełnym rozwiązaniem jest aktualizacja.

To nie jest jednorazowy pech

PHP2Shell jest wyjątkowy, bo uderza w sam język, a nie w dodatki. Codzienność WordPressa wygląda inaczej, ale wcale nie spokojniej. Według raportu Patchstack za 2025 rok:

• w ekosystemie WordPressa zgłoszono 11 334 nowe luki, o 42 % więcej niż rok wcześniej,
• 91 % z nich dotyczyło wtyczek, 9 % motywów, a w samym rdzeniu WordPressa znaleziono tylko 6,
• 46 % luk nie miało poprawki od autora w dniu publikacji,
• dla luk masowo wykorzystywanych mediana czasu do pierwszego ataku wyniosła 5 godzin,
• w testach Patchstack zabezpieczenia hostingów zatrzymały tylko 26 % ataków na znane luki WordPressa.

Sam WordPress jest więc pilnowany dobrze. Słabym punktem jest to, co się do niego dokłada, i to, na czym go uruchamiamy. Każda wtyczka to kod napisany przez kogoś innego, wykonywany na Twoim serwerze przy każdym wejściu na stronę. To właśnie widzimy przy czyszczeniu zainfekowanych stron: wejście prawie zawsze prowadzi przez wtyczkę, stare PHP albo jedno i drugie.

Dlaczego strona w Astro nie ma tego problemu

Strony, które budujemy w Astro, działają inaczej u samych podstaw. Przy publikacji zmian strona jest raz budowana do gotowych plików HTML, CSS i obrazów, a te pliki trafiają na serwery sieci CDN. Gdy ktoś wchodzi na stronę, serwer niczego nie uruchamia, tylko oddaje gotowy plik.

• Nie ma PHP. Nie ma interpretera, któremu można zabrać pamięć spreparowanym plikiem, ani procesu, który przenosi stan między żądaniami. Luki w rodzaju PHP2Shell nie mają w co trafić.
• Nie ma bazy danych na serwerze strony. Treść edytujesz w zewnętrznym CMS (u nas zwykle Sanity), który działa na infrastrukturze dostawcy, z logowaniem dwuetapowym. Strona publiczna nie ma do niego adresu administracyjnego.
• Nie ma panelu /wp-admin, który boty sprawdzają bez przerwy, i nie ma katalogu z przesłanymi plikami, w którym da się zostawić skrypt.
• Nie ma wtyczek instalowanych jednym kliknięciem. Każda funkcja to kod, który przechodzi przez nasze ręce, a zależności aktualizujemy w jednym miejscu i sprawdzamy przed publikacją.
• Kod po stronie serwera jest wąski. Formularz kontaktowy to zwykle jedna mała funkcja, która robi jedną rzecz: wysyła wiadomość. To nieporównanie mniej miejsca na atak niż PHP z kilkunastoma wtyczkami.

Efekt uboczny jest przyjemny: strona statyczna jest też szybka, bo nie składa się na nowo przy każdym wejściu. Ale w kontekście tego tekstu ważniejsze jest to, że nie wymaga awaryjnej aktualizacji w nocy, gdy ktoś znajdzie lukę w języku programowania.

Uczciwie: JavaScript i React też mają luki

Byłoby nieuczciwe pisać, że problem dotyczy tylko PHP. W grudniu 2025 React miał własną lukę z oceną 10/10, CVE-2025-55182, nazwaną React2Shell. Dotyczyła React Server Components, czyli kodu Reacta wykonywanego na serwerze przy każdym żądaniu, i objęła między innymi aplikacje Next.js 15 i 16 z App Routerem. Pierwsze ataki zauważono dwa dni po publikacji poprawek. Ekosystem npm regularnie notuje też przejęte paczki, które próbują wykraść dane programistom.

Wniosek nie brzmi więc „JavaScript jest bezpieczny, a PHP nie”. Brzmi tak: ryzyko rośnie razem z ilością kodu, który serwer wykonuje na prośbę obcej osoby. Strona w pełni statyczna takiego kodu prawie nie ma. Aplikacja, która renderuje strony na serwerze – w PHP, w Next.js czy w czymkolwiek innym – ma go dużo i wymaga takiej samej dyscypliny aktualizacji. Nasza własna strona działa na Next.js z serwerem, więc pilnujemy wersji tak samo jak przy WordPressie.

Czy to znaczy, że trzeba porzucić WordPressa?

Nie zawsze. WordPress na aktualnym PHP, z kilkoma sprawdzonymi wtyczkami, regularnymi aktualizacjami, kopią zapasową i zaporą aplikacyjną jest rozsądnym wyborem. Problem zaczyna się wtedy, gdy nikt się nim nie opiekuje, a tak wygląda wiele stron firmowych, które do nas trafiają.

Przejście na Astro ma największy sens, gdy:

• strona jest wizytówką lub serwisem firmowym, a treść zmienia się raz na jakiś czas,
• WordPress działa na PHP 8.1 lub starszym i podniesienie wersji coś psuje,
• strona była już zainfekowana albo ma kilkanaście wtyczek, z których połowa nie jest aktualizowana,
• zależy Ci na szybkości i nie chcesz co miesiąc płacić za pilnowanie aktualizacji.

WordPress zostaje lepszym wyborem przy rozbudowanym sklepie na WooCommerce z wieloma integracjami albo gdy kilka osób codziennie publikuje treści i przyzwyczaiło się do jego panelu. Wtedy warto zainwestować w stałą opiekę techniczną, a nie w przeprowadzkę.