PHP2Shell: krytyczne luki w PHP. Jak sprawdzić, czy Twoja strona jest bezpieczna?
21 października 2026 roku firmy i dostawcy hostingu pilnie aktualizowali serwery. Powód? Dwie krytyczne luki w PHP, które mogą umożliwić atakującym przejęcie strony bez logowania.
PHP napędza ogromną część internetu — od stron na WordPressie i sklepów WooCommerce po serwisy oparte na Drupalu, Joomli, Magento, Laravelu i rozwiązaniach tworzonych na zamówienie. Kiedy 20 października ujawniono szczegóły dwóch krytycznych błędów w samym PHP, stało się jasne, że nie chodzi o pojedynczą wtyczkę czy konkretny CMS. Zagrożenie może dotyczyć wielu różnych stron i systemów.
Serwisy administracji publicznej w Holandii, Niemczech i Francji były prewencyjnie wyłączane. Dostawcy hostingu prowadzili pilne prace serwisowe, a UptimeRobot odnotował 11 razy więcej alertów o niedostępności stron niż dzień wcześniej. Poprawki są już dostępne. Kluczowe jest jednak to, czy zostały wdrożone na serwerze, na którym działa Twoja strona.
W skrócie
- Luki określono jako PHP2Shell (CVE-2026-109618 i CVE-2026-109619). Ocena: 9,2 na 10.
- Dotyczą PHP od wersji 5.4, niezależnie od tego, na jakim CMS-ie czy frameworku działa strona.
- Podstawowym sposobem usunięcia tych podatności jest aktualizacja PHP do 8.2.35, 8.3.36, 8.4.27 lub 8.5.12 albo poprawionego pakietu od dostawcy serwera.
- PHP 8.1 i starsze nie dostaną oficjalnej poprawki. Jeśli Twoja strona korzysta z takiej wersji, zaplanuj jej aktualizację jak najszybciej.
- Sama aktualizacja WordPressa lub wtyczek nie wystarczy. Poprawkę PHP musi wdrożyć dostawca hostingu albo administrator serwera.
Czym jest PHP2Shell i co poszło nie tak?
Obie luki dotyczą sposobu, w jaki PHP zarządza pamięcią podczas obsługi żądań. Problem występuje na poziomie środowiska PHP, a nie WordPressa czy kodu konkretnej strony. Dlatego podatna może być nawet bardzo prosta witryna, jeśli działa na wersji PHP bez odpowiedniej poprawki.
- CVE-2026-109618 może zostać wywołana w sytuacji wyczerpania pamięci PHP. Odpowiednio przygotowane żądanie, przypominające przesłanie formularza z plikiem, prowadzi do błędu obsługi pamięci, którego skutki atakujący może wykorzystać.
- CVE-2026-109619 dotyczy pamięci wykorzystywanej podczas obsługi kolejnych żądań. Jeden proces PHP może obsługiwać wielu użytkowników po kolei. Po wystąpieniu błędu w pamięci mogą pozostać dane poprzedniego żądania, do których uzyskuje dostęp kolejne.
W praktyce może to prowadzić do dwóch poważnych scenariuszy: zdalnego wykonania kodu bez logowania, a w konsekwencji przejęcia kontroli nad serwerem, oraz odczytu danych znajdujących się w jego pamięci. Mogą to być między innymi hasła, tokeny sesji, klucze API czy certyfikaty. Badacze z Wiz zaprezentowali działające ataki w środowiskach wykorzystujących aktualne wersje WordPressa, Drupala i Joomli.
| Szczegóły | |
|---|---|
| Nazwa | PHP2Shell (CVE-2026-109618, CVE-2026-109619) |
| Ocena zagrożenia | CVSS 9,2 (krytyczna). Atak bez logowania i bez udziału użytkownika |
| Podatne wersje | PHP od 5.4 w górę |
| Wersje z poprawką | 8.2.35, 8.3.36, 8.4.27, 8.5.12 |
| Zagrożone konfiguracje | Apache z mod_php (największe ryzyko), PHP-FPM, php-cgi, LiteSpeed, FrankenPHP |
Jak rozwijały się wydarzenia
| Data (2026, UTC) | Co się stało |
|---|---|
| 19 sierpnia | Wiz Research, korzystając z narzędzi AI, znajduje pierwszą lukę |
| 24 sierpnia | Poufne zgłoszenie do zespołu bezpieczeństwa PHP |
| 20 października | Szczegóły wyciekają do sieci. PHP przyspiesza wydanie poprawek |
| 21 października, 03:02 | Cloudflare włącza tymczasowe reguły ochronne dla wszystkich klientów |
| 21 października, ok. 14:00 | PHP publikuje poprawione wersje |
| 21 października, 14:19 | watchTowr raportuje pierwsze aktywne próby ataków |
| 22 października | W sieci krążą publiczne exploity |
Warto zwrócić uwagę na jeszcze jeden szczegół. PHP Foundation przyznała, że pierwsze sygnały dotyczące jednego z błędów pojawiły się już podczas zewnętrznego audytu w 2024 roku. Prace nad poprawką zostały jednak wstrzymane na wiele miesięcy. Fundacja określiła to jako „błąd strukturalny” i od tamtego czasu zmieniła sposób podejmowania decyzji dotyczących bezpieczeństwa.
Czy Twoja wersja PHP jest zagrożona?
To jedno z najważniejszych pytań. Odpowiedź zależy od wersji PHP, na której działa Twoja strona.
| Twoja wersja PHP | Status | Co zrobić |
|---|---|---|
| 8.1, 8.0, 7.x, 5.x | Bez wsparcia. Brak oficjalnej poprawki PHP2Shell | Jak najszybciej zaplanuj aktualizację. Niektórzy dostawcy (Ubuntu, AlmaLinux, CloudLinux) udostępniają poprawki dla starszych wersji, ale traktuj je jako rozwiązanie przejściowe |
| 8.2 | Poprawka w 8.2.35, ale wsparcie bezpieczeństwa kończy się 31 grudnia 2026 | Wdróż poprawkę i zaplanuj przejście na PHP 8.4 lub 8.5 w ciągu kilku tygodni |
| 8.3, 8.4, 8.5 | Wspierane wersje z poprawką (8.3.36, 8.4.27, 8.5.12) | Sprawdź, czy poprawka jest faktycznie zainstalowana, a PHP zrestartowany |
Największe ryzyko dotyczy stron korzystających z niewspieranych wersji PHP. Według skanów cytowanych przez Recorded Future około 79% usług PHP, których wersję udało się ustalić, działa na gałęziach bez wsparcia. Samo PHP 7.4 odpowiada za niemal 880 tys. takich usług. Jeśli Twoja strona powstała kilka lat temu i od dawna nikt nie aktualizował jej środowiska, warto to sprawdzić.
Aktualizacja PHP nie zawsze sprowadza się do jednego kliknięcia. Starsze motywy, wtyczki i kod tworzony na zamówienie mogą wymagać dostosowania do nowszej wersji. Dlatego przed migracją warto przeprowadzić testy zgodności. To zwykle znacznie mniejszy koszt niż usuwanie skutków włamania.
Nie wiesz, na jakiej wersji działa Twoja strona? Podeślij nam adres, a odpowiedź otrzymasz w ciągu 1–2 dni roboczych.
Co już się wydarzyło
Duże organizacje nie czekały na potwierdzenie ataku. Część z nich prewencyjnie wyłączyła swoje serwisy, aby ograniczyć ryzyko.
- Holandia: czasowo wyłączono m.in. stronę krajowego centrum cyberbezpieczeństwa, DigiD i MijnOverheid, a także serwisy Izby Reprezentantów, Portu Rotterdam, największych partii politycznych i wielu szpitali.
- Reszta Europy: prewencyjnie wyłączono część rządowych stron w Niemczech, Francji, Finlandii, Belgii i Czechach. Wikimedia czasowo wyłączyła część swoich systemów. CERT Polska, CERT-EU i brytyjskie NCSC wezwały do natychmiastowej aktualizacji.
- Biznes: BambooHR wyłączył swoją platformę HR w USA, Kanadzie i Irlandii. W Japonii pilne prace serwisowe prowadzili dostawcy hostingu, m.in. Sakura Rental Server, a Bloomberg informował o wyłączonych usługach banków i linii lotniczych.
W szczytowym momencie 21 października UptimeRobot wysyłał około 37 tys. alertów o niedostępności stron na minutę — około 11 razy więcej niż dzień wcześniej. W Europie wzrost był dwudziestokrotny. Do 22 października nie pojawiło się publiczne potwierdzenie konkretnego udanego włamania. Nie oznacza to jednak, że ryzyko można zignorować.
Ile PHP2Shell może kosztować firmę?
Łatwo potraktować to jako sprawę wyłącznie dla działu IT. Tymczasem przejęcie strony może oznaczać przerwę w sprzedaży, straty finansowe, obowiązki prawne i utratę zaufania klientów. Oto sześć obszarów, w których konsekwencje incydentu mogą być szczególnie dotkliwe.
Sześć sposobów, w jakie włamanie uderza w biznes
Koszt 01
Koszty obsługi incydentu
Według raportu IBM Cost of a Data Breach 2025 średni koszt naruszenia danych na świecie to 4,44 mln dolarów, a w USA 10,22 mln. Dla mniejszych firm skala kosztów jest zwykle inna, ale analiza incydentu, przywracanie systemów i przestój również mogą poważnie obciążyć budżet.
- Koszt bezpośredni
Koszt 02
Przestój w najgorszym momencie
Awaryjne wyłączenie strony może oznaczać niedziałający formularz, niedostępny koszyk i utracone zapytania. Jeśli do awarii dojdzie podczas kampanii, budżet reklamowy nadal może kierować użytkowników na stronę, która nie działa.
- Przychody
Koszt 03
Prawo i zgodność
Jeśli incydent doprowadzi do naruszenia ochrony danych osobowych, może powstać obowiązek zgłoszenia go do UODO — co do zasady w ciągu 72 godzin od stwierdzenia naruszenia. Za naruszenia RODO przewidziano kary sięgające 20 mln euro lub 4% światowego rocznego obrotu, zależnie od tego, która kwota jest wyższa. Sklepy internetowe podlegają też PCI DSS, a firmy objęte NIS2 mają własne obowiązki zgłaszania incydentów.
- RODO
- NIS2
Koszt 04
Klienci i partnerzy
Klienci B2B coraz częściej pytają o aktualizacje w ankietach bezpieczeństwa. Brak wiedzy o aktualnej wersji PHP i procedurach aktualizacji może osłabiać zaufanie partnerów biznesowych.
- Zaufanie
Koszt 05
Problemy z odszkodowaniem
Ubezpieczyciele oferujący polisy cyber często sprawdzają, czy wdrażano poprawki do znanych krytycznych podatności. Długotrwały brak aktualizacji może utrudnić uzyskanie odszkodowania, zależnie od warunków polisy.
- Ubezpieczenie
Koszt 06
Utrata widoczności w wyszukiwarkach
Atakujący mogą umieszczać w witrynie spam i ukryte linki. Google może oznaczyć stronę jako niebezpieczną, a jej domena może trafić na listy blokowania. Odbudowa widoczności w wynikach wyszukiwania może potrwać tygodnie lub miesiące.
- Widoczność
Test na 10 sekund dla Twojego zespołu
Zadaj zespołowi jedno pytanie: kto odpowiada za aktualizacje PHP i kiedy ostatnio je wykonywano? Jeśli trudno wskazać osobę odpowiedzialną lub datę ostatniej aktualizacji, warto jak najszybciej uporządkować ten proces. Pomożemy Ci to zrobić.
AI a bezpieczeństwo stron: szybsze wykrywanie luk i szybsze ataki
PHP2Shell to jeden z pierwszych tak szeroko komentowanych przypadków, w których AI odegrała istotną rolę zarówno w wykrywaniu błędów, jak i w przygotowywaniu sposobów ich wykorzystania. Podatności były obecne w PHP od ponad dekady, a ich źródła wiązano z badaniami sięgającymi 2004 roku. Wykrył je zespół Wiz Research we współpracy z Calif i zespołem Codex Security z OpenAI, korzystając ze wsparcia modeli AI. Według Wiz jeden badacz wykonał w tydzień pracę, która wcześniej mogłaby zająć światowej klasy zespołowi wiele miesięcy.
Calif podkreśla jednak, że modele AI nie wykonały tej pracy samodzielnie. Niezbędna była wiedza specjalisty, który rozumiał historię i wewnętrzne mechanizmy PHP. AI nie zastąpiła eksperta — pozwoliła mu pracować znacznie szybciej.
Dla firm wynikają z tego trzy ważne wnioski:
- Czas na reakcję się kurczy. Między publikacją poprawek a pierwszymi atakami minęło 19 minut. Te same narzędzia, które pomogły znaleźć luki, pomagają atakującym dopasować exploity do różnych wersji i konfiguracji. Na pilne aktualizacje trzeba dziś reagować w ciągu godzin, nie tygodni.
- Takich alarmów będzie więcej. Jeżeli AI przyspiesza wykrywanie błędów nawet w tak dojrzałym i wielokrotnie sprawdzanym oprogramowaniu jak PHP, podobne sytuacje mogą dotyczyć również innych technologii.
- AI pomaga też w obronie. Zespół Gemini z Google pomagał przy poprawce, a Cloudflare miał reguły ochronne gotowe kilka godzin przed jej publikacją. Monitoring, sprawdzone kopie zapasowe i jasno określona odpowiedzialność za reakcję zwiększają szansę na ograniczenie skutków incydentu.
Jeszcze jedna ważna uwaga: nie korzystaj z niezweryfikowanych „poprawek” wygenerowanych przez chatbota ani z wtyczek obiecujących naprawę PHP z poziomu WordPressa. Patchstack wyraźnie przed tym ostrzega. Podatności w samym PHP nie da się usunąć wtyczką do CMS-a.
Co zrobić teraz? Lista kontrolna PHP2Shell
Nie musisz samodzielnie zarządzać serwerem, żeby zadbać o bezpieczeństwo strony. Wystarczy wiedzieć, co sprawdzić i do kogo zwrócić się po pomoc.
Dziś
- Sprawdź, na jakiej wersji PHP faktycznie działa Twoja strona. Ważna jest wersja obsługująca żądania WWW, a nie tylko wynik polecenia
php -vw konsoli. Dostawcy systemów mogą udostępniać poprawki do starszych pakietów bez zmiany głównego numeru wersji. Dlatego warto sprawdzić historię zmian pakietu pod kątem CVE-2026-109618 i CVE-2026-109619. - Zapytaj dostawcę hostingu lub administratora, czy poprawka PHP została już wdrożona i czy po aktualizacji zrestartowano Apache, PHP-FPM i procesy w tle. Bez restartu poprawka nie działa.
- Masz PHP 8.1 lub starsze? Sprawdź, czy dostawca systemu wydał poprawkę dla Twojej wersji. Jeśli nie, zaplanuj możliwie szybką migrację, najlepiej do PHP 8.4 lub 8.5.
- Nie instaluj „wtyczek naprawczych” ani nie wdrażaj niesprawdzonego kodu znalezionego na forum czy wygenerowanego przez chatbota.
- Nie możesz od razu wdrożyć poprawki? Administrator może rozważyć tymczasowe ograniczenia, np.
session.upload_progress.enabled=0oraz obniżoną wartośćpost_max_size. To środki ograniczające ryzyko, a nie zamiennik aktualizacji. Reguły WAF w Cloudflare pomagają tylko wtedy, gdy serwer nie przyjmuje ruchu z pominięciem Cloudflare. Przy wrażliwych danych rozważ tryb serwisowy do czasu aktualizacji.
W tym tygodniu
- Zrób inwentaryzację środowisk PHP. Sprawdź serwisy testowe, stare landing page’e, zapomniane subdomeny, kontenery i systemy zewnętrznych dostawców.
- Przejrzyj logi od 20 października. Zwróć uwagę na nietypowe żądania przesyłania plików, błędy wyczerpania pamięci, serie błędów 500, wyjątkowo duże pliki cookie
PHPSESSIDi nieoczekiwane restarty PHP. Brak podejrzanych wpisów w logach nie gwarantuje, że serwer jest bezpieczny. - Masz wątpliwości? Załóż, że serwer mógł zostać naruszony. Zmień hasła, klucze API i tokeny, które na nim były, bo mogły wyciec z pamięci. Sprawdź pliki pod kątem obcego kodu. Jeśli doszło do naruszenia ochrony danych osobowych, sprawdź również, czy powstał obowiązek zgłoszenia do UODO i czy obowiązuje termin 72 godzin.
Na stałe
Ustal, kto odpowiada za aktualizacje. Powinna to być konkretna osoba lub firma, z jasno określonym czasem reakcji. Dodaj monitoring dostępności, regularnie testowane kopie zapasowe i wspieraną wersję PHP. Dzięki temu kolejny incydent nie musi oznaczać działania w trybie kryzysowym.
PHP2Shell: najczęstsze pytania
Podsumowanie
PHP2Shell nie dotyczył jednej strony ani jednego CMS-a. Pokazał, jak ważna jest szybka reakcja, gdy krytyczna podatność pojawia się w oprogramowaniu wykorzystywanym przez wiele serwisów. Część organizacji prewencyjnie wyłączyła swoje strony, aby bezpiecznie wdrożyć poprawki. Inne nadal nie wiedzą, z jakiej wersji PHP korzystają.
Wniosek jest prosty: bezpieczeństwo strony wymaga regularnej opieki, nie jednorazowego wdrożenia. Ktoś powinien wiedzieć, jakie oprogramowanie działa na serwerze, śledzić aktualizacje i reagować na nowe zagrożenia.
Źródła
- Rapid7: analiza CVE-2026-109618 i CVE-2026-109619
- Wiz: badanie PHP2Shell
- The Hacker News: awaryjne poprawki i oś czasu
- Recorded Future: dane o ekspozycji
- Patchstack: wskazówki dla właścicieli stron na WordPressie
- UptimeRobot: dlaczego strony same się wyłączały
- Antyweb: ostrzeżenie CERT Polska
- CyberScoop: raport IBM Cost of a Data Breach 2025