PHP2Shell: krytyczna luka w PHP. Co sprawdzić na swojej stronie

21 października 2026 roku zespół PHP wydał awaryjne poprawki dwóch krytycznych podatności, nazwanych zbiorczo PHP2Shell (CVE-2026-109618 i CVE-2026-109619). Luki pozwalają przejąć serwer bez logowania, a siedzą w samym interpreterze PHP, nie we wtyczce ani motywie. Tego samego dnia część instytucji publicznych w Europie wyłączyła swoje serwisy, zanim zdążyła je załatać. Jeśli Twoja firmowa strona, sklep na WooCommerce albo system na WordPressie stoi na PHP, temat dotyczy Ciebie bezpośrednio.

Co się stało i dlaczego strony rządowe zgasły

Szczegóły luk wyciekły przed planowaną publikacją. Według PHP Foundation w sieci krążyły zrzuty ekranu narzędzia do ataku i usunięte nagranie z demonstracją, więc zespół PHP przyspieszył wydanie poprawek o dzień. Brytyjskie NCSC zaleciło natychmiastową aktualizację, a jeśli to niemożliwe – rozważenie wyłączenia podatnych systemów.

Część organizacji tak zrobiła. Według Insurance Business offline poszły m.in. serwis holenderskiego NCSC, logowanie DigiD, portal MijnOverheid i strona Izby Reprezentantów w Holandii, usługi fińskiego państwowego dostawcy IT Valtori, część serwisów niemieckiego ITZBund, a w Wielkiej Brytanii strony rad miejskich i Metropolitan Police. Przy serwisach holenderskich źródło mówi wprost o ostrożności, przy brytyjskich podaje tylko, że były niedostępne. W cytowanych źródłach nie ma informacji o potwierdzonym włamaniu do tych serwisów.

Czym jest PHP2Shell, prostym językiem

Oba błędy dotyczą tego, jak PHP sprząta po zapytaniu, które skończyło się błędem krytycznym – np. przekroczeniem limitu pamięci. W określonym momencie PHP zostawia po sobie uszkodzone dane, a kolejne zapytanie obsługiwane przez ten sam proces może je wykorzystać. Atakujący, wysyłając odpowiednio spreparowane żądania, może doprowadzić do wykonania własnego kodu na serwerze.

Najważniejsze fakty:

• Ocena powagi: CVSS v4.0 9.2 według zespołu bezpieczeństwa PHP. Wartość 10.0, która krążyła przed publikacją, PHP Foundation określiła jako błędną.
• Bez logowania. Na Apache z mod_php atak można wywołać, zanim wykona się jakikolwiek kod aplikacji. Zdalne wykonanie kodu potwierdzono też na PHP-FPM.
• Zagrożone są instalacje obsługujące ruch WWW: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP i LiteSpeed.
• Wiek błędu: według Wiz i Calif problem sięga PHP 5.4, czyli ponad dekady wstecz.
• Logowanie do aplikacji nie chroni, bo podatny kod jest w PHP, a nie w WordPressie czy sklepie.

Kto jest zagrożony

Według W3Techs (cytowanego przez Tenable) PHP działa na 69,3% stron, których język serwera da się ustalić. Stąd w mediach hasło o „70% internetu” – to udział PHP w rynku, a nie liczba stron potwierdzonych jako podatne. Szacunki niezależnych badaczy mówią o ponad 1,3 mln potencjalnie podatnych hostów dostępnych z internetu; to szacunek, nie pomiar.

CERT Polska wprost wskazuje WordPressa, Joomlę i WooCommerce jako oprogramowanie, które dziedziczy podatność po PHP. Wiz i Calif zademonstrowali przejęcie serwera m.in. na WordPressie i Drupalu.

W praktyce dla polskiej firmy oznacza to trzy sytuacje:

• Hosting współdzielony (najczęstszy w MŚP) – PHP aktualizuje dostawca. Nie zrobisz tego sam, ale możesz i powinieneś zapytać.
• Własny serwer lub VPS – aktualizacja jest po Twojej stronie albo Twojego administratora.
• Gotowe obrazy i urządzenia (np. kontenery Dockera, panele, appliance) – poprawka musi przyjść od producenta obrazu.

Co jest wykorzystywane, a co nie

Tu źródła się różnią i warto to powiedzieć wprost:

• PHP Foundation: zespół analizował krążące po wycieku proof-of-concepty i w chwili publikacji poprawek nie zidentyfikował działającego exploita.
• Amazon Threat Intelligence (za Tenable) odnotował próbę ataku już 17 października, cztery dni przed ujawnieniem, i ocenia, że luka jest teraz szeroko wykorzystywana.
• Cloudflare (wypowiedź CTO cytowana przez Tenable) widzi „pierwsze pojawiające się ataki”, a watchTowr deklaruje, że odtworzył obie luki i obserwuje próby wykorzystania.

Wniosek dla firmy jest prosty niezależnie od tego, kto ma rację: okno na spokojną aktualizację właśnie się zamyka.

Checklista dla właściciela strony

1. Sprawdź wersję PHP. W WordPressie: Narzędzia → Zdrowie witryny → Informacje → Serwer. Bezpieczne wersje to:

• 8.5.12 dla linii 8.5,
• 8.4.27 dla linii 8.4,
• 8.3.36 dla linii 8.3,
• 8.2.35 dla linii 8.2.

Uwaga: dystrybucje Linuksa często przenoszą poprawkę do starszego numeru wersji (np. AlmaLinux), więc niższy numer nie zawsze oznacza brak łatki. Na hostingu współdzielonym rozstrzyga odpowiedź dostawcy.

2. Starsze PHP (8.1 i niżej). Projekt PHP nie wyda dla nich oficjalnych wersji. Zespół PHP opublikował minimalne łatki źródłowe dla 7.4–8.1, ale realnie oznacza to jedno: zaplanuj migrację na wspieraną wersję PHP.

3. Zapytaj hostingodawcę. Wystarczy krótka wiadomość do supportu:

Czy PHP na moim koncie/serwerze jest już zaktualizowane pod kątem CVE-2026-109618 i CVE-2026-109619 (PHP2Shell)? Jeśli nie – kiedy będzie i jakie zabezpieczenia tymczasowe stosujecie?

4. Obejścia tymczasowe – tylko do czasu aktualizacji. CERT Polska zaleca ustawienie w php.ini:

• memory_limit na -1, jeśli pozwalają na to zasoby, a w przeciwnym razie 128M lub więcej,
• post_max_size na 8M lub mniej,
• max_input_vars na 1000 lub mniej,
• session.upload_progress.enabled na Off.

CERT podkreśla, że te ustawienia nie wykluczają ataku – w pełni chroni tylko aktualizacja. Alexandre Daubois z zespołu PHP zwraca uwagę, że najczęściej powtarzana rada (session.upload_progress.enabled = Off) dotyczy tylko jednej z dwóch luk. Po aktualizacji przywróć skończony memory_limit, inaczej pojedyncze zapytanie może zająć całą pamięć serwera.

5. WAF to pas bezpieczeństwa, nie naprawa. Cloudflare i inni dostawcy wdrożyli reguły blokujące znane wektory ataku. Pomagają zyskać czas, ale atakujący szukają nowych wariantów, a dostawcy aktualizują reguły na bieżąco.

6. Po aktualizacji przejrzyj logi. Jeśli serwer był podatny od 17 października, sprawdź nietypowe pliki PHP w katalogach z uploadami, nowe konta administratorów i nieoczekiwane zmiany w motywie czy wtyczkach.

Wątek AI: kto znalazł luki i co to zmienia

PHP2Shell to jeden z pierwszych tak głośnych przypadków, w których modele AI realnie przyspieszyły znalezienie krytycznej luki w fundamencie internetu.

• Calif zgłosił pierwszy błąd do PHP 11 sierpnia 2026; według firmy jej badacz korzystał przy tym z pomocy modelu językowego.
• Wiz według własnej osi czasu znalazł luki 19 sierpnia, korzystając m.in. z modeli Gemini i GPT, i zgłosił je 24 sierpnia.
• Według PHP Foundation tę samą przyczynę niezależnie zgłosiło też OpenAI (zespół Codex Security).
• Ślad problemu jest starszy: według Calif podobny błąd zgłoszono w 2020 roku, a audyt bezpieczeństwa PHP z 2024 roku wskazał powiązany problem, ale nie udowodniono wtedy, że da się go wykorzystać.

AI nie wynalazło więc nowej klasy błędów – pomogło ludziom dojść od „podejrzanego miejsca w kodzie” do działającego ataku. Ta sama zdolność działa w obie strony. PHP Foundation pisze, że od 1 lipca zespół opublikował 15 CVE i przerobił ponad 100 zgłoszeń, które okazały się nieważne, zdublowane lub nie do odtworzenia, i apeluje do firm, hostingodawców i instytucji publicznych o finansowanie pracy nad bezpieczeństwem PHP.

Dla firmy wniosek jest praktyczny: czas między ujawnieniem luki a pierwszymi atakami się skraca. Strona, której nikt regularnie nie aktualizuje, przestaje być „małym ryzykiem”.

Wnioski praktyczne i rekomendacje

• Dziś sprawdź wersję PHP i zapytaj hostingodawcę o łatkę na CVE-2026-109618 i CVE-2026-109619.
• Jeśli masz PHP 8.1 lub starsze – traktuj migrację jako pilne zadanie, nie projekt „na kiedyś”.
• Obejścia z php.ini i reguły WAF traktuj jako tymczasowe, nie jako rozwiązanie.
• Ustal, kto w firmie odpowiada za aktualizacje strony – i jak szybko jest w stanie zareagować następnym razem.

• CERT Polska – Krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu (php2shell)
• PHP Foundation – Today’s PHP Security Release, and How We’re Strengthening PHP Security
• php.net – News Archive 2026
• Alexandre Daubois – What the PHP2Shell rumors got wrong
• Tenable – php2shell FAQ
• Wiz Research – PHP2Shell
• Calif – php2shell
• Insurance Business – UK councils and Met Police among sites pulled offline after NCSC alert
• AlmaLinux – php2shell: Patched PHP packages released