PHP2Shell: dlaczego jedna luka w PHP zagraża niemal każdej stronie internetowej?

Czym jest PHP2Shell?

PHP2Shell to nazwa, którą badacze nadali łańcuchowi dwóch podatności: CVE-2026-109618 i CVE-2026-109619. Zespół bezpieczeństwa PHP ocenił obie na 9.2 w skali CVSS v4.0. Krążąca początkowo w internecie ocena 10.0 była błędna, ale 9.2 to wciąż podatność krytyczna.

Nazwa opisuje skutek. Przez PHP atakujący uzyskuje „shell” – możliwość wykonywania poleceń na Państwa serwerze. Nie potrzebuje do tego ani hasła, ani konta na stronie: wystarczy jedno specjalnie przygotowane żądanie HTTP.

Badacze potwierdzili działające ataki na strony WordPress, Drupal, Joomla i Magento. Podatne są wszystkie sposoby, w jakie PHP obsługuje żądania internetowe:

• PHP-FPM – najpopularniejszy na współczesnych serwerach;
• Apache mod_php – tu zespół PHP ocenia ryzyko jako najwyższe;
• php-cgi, LiteSpeed i FrankenPHP.

Dlaczego wtyczka bezpieczeństwa nie ochroni Państwa strony

Najważniejsza cecha PHP2Shell to moment, w którym następuje atak. PHP przetwarza dane żądania jeszcze przed uruchomieniem kodu strony. Dlatego żadne zabezpieczenie działające wewnątrz strony nawet nie dowiaduje się o ataku.

Wniosek jest prosty: jedynym pełnym rozwiązaniem jest aktualizacja samego PHP. Wszystko inne to środki tymczasowe, które pomagają zyskać na czasie.

Dwie podatności, jeden łańcuch

Obie podatności są związane ze sposobem, w jaki PHP zarządza pamięcią podczas przetwarzania żądań. Właściciel strony nie musi znać szczegółów technicznych, ale warto wiedzieć, czym się różnią, bo tymczasowe środki ochrony są dla każdej inne.

Jak to przebiegało

1. 2024

   Podczas pierwszego od lat zewnętrznego audytu bezpieczeństwa PHP zespół zauważa pierwsze oznaki problemu z pamięcią, który później stał się CVE-2026-109618. Działającej metody ataku wtedy nie znaleziono, nic nie ogłoszono publicznie, a prace nad poprawką utknęły. PHP Foundation przyznała później, że to opóźnienie było błędem.

2. 11 sierpnia 2026

   Badacze z Calif i OpenAI niezależnie od siebie zgłaszają zespołowi PHP, że ten sam problem pozwala uruchomić kod na serwerze. Poprawka staje się priorytetem.

3. 17 października

   Amazon Threat Intelligence rejestruje w swojej sieci pułapek (honeypotów) pierwszą próbę wykorzystania – cztery dni przed publicznym ujawnieniem.

4. 20 października

   Identyfikatory CVE wyciekają do sieci. Zespół PHP publikuje wcześniejsze powiadomienie o krytycznej aktualizacji bezpieczeństwa.

5. 21 października

   Z powodu wycieku poprawione wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 zostają wydane dzień wcześniej niż planowano. Cloudflare informuje o pierwszych atakach i wdraża tymczasowe reguły WAF.

6. Teraz

   Ataków przybywa, przeprowadza je kilka różnych grup. Amazon zaleca szukanie oznak włamania od 17 października, a nie od dnia ujawnienia.

Czy Państwa strona jest podatna?

Podatna jest każda strona obsługiwana przez niezałataną wersję PHP. Oto wersje, które mają już poprawkę:

Dlaczego numer wersji może wprowadzać w błąd

• Dystrybucje Linuksa często instalują poprawkę bez zmiany numeru wersji. „Stary” numer nie oznacza więc jeszcze, że PHP jest podatne.
• PHP widoczne w wierszu poleceń może różnić się od tego, które faktycznie obsługuje stronę.
• Na hostingu współdzielonym może działać jednocześnie kilka wersji PHP, a różne domeny mogą korzystać z różnych.

Co można zrobić już dziś

1. Ustalić dokładną wersję PHP, która obsługuje stronę, i porównać ją z tabelą powyżej.
2. Zaktualizować PHP do poprawionej wersji lub poprosić o to dostawcę hostingu. Przed przejściem na nową gałąź warto wykonać kopię zapasową i sprawdzić, czy strona, motyw i wtyczki z nią działają.
3. Jeśli aktualizacja od razu nie jest możliwa, włączyć środki tymczasowe zalecane przez zespół PHP (patrz niżej) i zrestartować wszystkie procesy PHP.
4. Sprawdzić, czy nie doszło już do włamania: nieznane pliki PHP, nowi administratorzy, shelle uruchomione przez procesy strony, błędy wyczerpania pamięci „on line 0” w logach – od 17 października.
5. Traktować WAF jako dodatkową warstwę, a nie poprawkę. Chroni on tylko ruch, który przez niego przechodzi.

Środki tymczasowe w konfiguracji PHP:

memory_limit = -1                  ; CVE-2026-109618
session.upload_progress.enabled = 0  ; CVE-2026-109619
fatal_error_backtraces = 0         ; tylko PHP 8.5

memory_limit należy ustawić tak, by aplikacje nie mogły go zmienić (np. przez php_admin_value w ustawieniach PHP-FPM). Ponieważ usuwa to limit pamięci PHP, zespół PHP zaleca zapewnić go na poziomie kontenera lub cgroup i ograniczyć rozmiar żądań na serwerze WWW. Te środki zmniejszają ryzyko, ale nie czynią PHP bezpiecznym.

Kiedy warto zwrócić się do specjalisty

Aktualizacja PHP często zajmuje tylko kilka minut. Trudniej odpowiedzieć na trzy pytania: czy poprawka naprawdę działa w PHP, które obsługuje Państwa stronę, czy strona będzie działać z nową wersją i czy ktoś nie wykorzystał podatności wcześniej.

Właśnie to sprawdza audyt PHP2Shell od Redfox Cloud. Stronę ręcznie sprawdza inżynier serwerów, a nie automatyczny skaner, a wyniki otrzymują Państwo na piśmie, zrozumiałym językiem. Nie trzeba być naszym klientem hostingowym.

Kontaktujemy się w ciągu 2 godzin roboczych od otrzymania płatności (pon.–pt. 9:00–18:00 czasu wileńskiego). Płatność jednorazowa. Wycenę naprawy przedstawiamy po audycie, a decyzja, czy prace wykonamy my, należy do Państwa.

Najczęściej zadawane pytania

Źródła: PHP, PHP Foundation, Tenable, Datadog Security Labs, Help Net Security. Informacje według stanu na 22 października 2026 r.