Przejdź do treści

PHP2Shell: luka w PHP grozi 70% stron internetowych. Znalazło ją AI

Adam Marzec
Okładka artykułu o luce PHP2Shell: CVSS 9,2 dla obu luk, cztery wersje naprawcze PHP od 8.2 do 8.5 wydane 21 października, 70% stron chodzi na PHP

21 października 2026 roku o 14:00 UTC projekt PHP wydał cztery awaryjne wersje: 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Naprawiają dwie krytyczne luki w samym silniku języka, śledzone jako CVE-2026-109618 i CVE-2026-109619, które pozwalają wykonać kod na serwerze bez żadnego logowania. Piszę to jako osoba prowadząca stronę na WordPressie i PHP 8.4, więc czytam te materiały z taką samą uwagą jak ty. Porównania do Heartbleed czy log4j nie są tu retoryką, bo PHP napędza około 70% stron w sieci, a wadliwy kod sięga wersji 5.4.

Luki znalazł między innymi zespół Wiz Research, czyli Sagi Tzadik, Shir Tamari, Nir Ohfeld i Tomer Schwartz, przy pomocy modeli AI: narzędzia Wiz Atlas oraz Gemini 4 Argon i GPT-5.6 Sol. Niezależnie dotarli do tego samego problemu badacze firmy Calif i OpenAI. Dla czytelnika oznacza to jedno: jeśli twoja strona, sklep czy panel działają na PHP, aktualizacja jest jedynym pełnym rozwiązaniem, a na hostingu współdzielonym trzeba już dziś zapytać obsługę, kiedy wdrożą 8.4.27 albo odpowiednik dla twojej gałęzi.

Najważniejsze informacje

CoSzczegóły
IdentyfikatoryCVE-2026-109618 (GHSA-w8hw-w9fx-j79w), CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
Ocena ważnościCVSS v4.0 9.2 dla obu luk, wg php.net z 20.10.2026
Naprawione wersjePHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, wydane 21.10.2026 o 14:00 UTC
Zagrożone wersjeod PHP 5.4, czyli praktycznie każda instalacja obsługująca żądania HTTP
Kto zgłosiłWiz Research, Calif i OpenAI niezależnie; pierwsze ślady problemu z audytu Quarkslab z 2024
Aplikacje dowodoweWordPress, Drupal, Joomla, a u Calif także MediaWiki, phpMyAdmin, Nextcloud i inne
WAFCloudflare chroni wszystkie plany, także darmowe, od 21.10.2026 o 3:02 UTC
Obejścieczęściowe: session.upload_progress.enabled=0; pełna naprawa wymaga aktualizacji

Co to za luka i jak działa

Obie luki to błędy bezpieczeństwa pamięci, które ujawniają się w momencie, gdy przetwarzanie żądania kończy się błędem krytycznym, na przykład przez przekroczenie limitu memory_limit. PHP sprząta wtedy pamięć po przerwanej pracy, ale część wewnętrznego stanu może przetrwać i wskazywać na pamięć już zwolnioną. Kolejne żądanie obsłużone przez ten sam proces roboczy może ten zawieszony stan odczytać i użyć, co prowadzi do wglądu w cudzą pamięć albo jej uszkodzenia, a w konsekwencji do wykonania kodu atakującego. Wiz porównuje efekt do wycieku w stylu Heartbleed: z pamięci procesu wyciekają hasła, tokeny, klucze API i certyfikaty należące do innych żądań lub samego serwera, i to bez osiągania pełnego RCE.

Pierwsza luka, nazwana przez php.net „RCE via OOM corruption”, polega na tym, że wyczerpanie pamięci przerywa PHP w chwili, gdy dane wewnętrzne są tylko częściowo zainicjowane, a porządkowanie żądania traktuje je potem jak poprawne. Druga, „RCE via stale global state”, zostawia po błędzie krytycznym referencje do pamięci, która została zwolniona na końcu żądania. Wektor ataku bywa związany z mechanizmem session.upload_progress, czyli domyślnie włączoną funkcją śledzącą postęp wysyłania plików, dostępną od PHP 5.4; opcja session.upload_progress.enabled ma w dokumentacji wartość domyślną 1, więc wyłącza się ją dopiero ręcznie. Najważniejsze jest to, że błąd siedzi w samym runtime, poniżej warstwy aplikacji: nie pomaga ani aktualna wersja WordPressa, ani porządny kod, ani brak wtyczek, bo atak uruchamia się, zanim jakikolwiek kod aplikacji zdąży wystartować. php.net ocenia ryzyko jako największe przy Apache z mod_php, gdzie żądanie bez uwierzytelnienia wyzwala atak przed startem aplikacji, ale zagrożone są wszystkie instalacje serwujące ruch: PHP-FPM, php-cgi, FrankenPHP i LiteSpeed.

Jak AI znalazło lukę w PHP

Tu historia robi się nieprzyjemna dla każdego, kto wierzył, że stary, dobrze przejrzany kod jest bezpieczny. Zespół Wiz opisuje, że wadliwe wzorce siedziały w PHP ponad dekadę, ale samodzielne zbudowanie działającego exploita wymagało łańcuchowania kilku błędów i dopasowania do układu pamięci konkretnej wersji, co było na granicy ludzkich możliwości. Modele frontier zniosły tę barierę: Wiz przyznaje, że jeden badacz zrobił w tydzień to, co dawniej zajęłoby światowej klasy zespołowi miesiące, a Gemini 4 Argon odegrał główną rolę w znalezieniu luki, budowie exploita i weryfikacji łatki. Exploit o nazwie php2shell uruchamiał kod bez logowania na czystych kontenerach wordpress:latest, drupal:latest i joomla:latest, więc o podatności decydowała sama obecność PHP, a nie wada konkretnej aplikacji.

Nie było to przy tym samotne odkrycie. PHP Foundation opisuje, że pierwsze ślady problemu z wyczerpaniem pamięci znalazł w 2024 roku programista PHP podczas poprawek po pierwszym od lat zewnętrznym audycie bezpieczeństwa (Quarkslab, finansowanym przez Sovereign Tech Agency w ramach OSTIF), ale wtedy nie znano drogi do RCE i prace nad poprawką wielokrotnie zamierały. W sierpniu 2026 temat wrócił z trzech stron naraz: 11 sierpnia badacz Ryan A z firmy Calif, audytującej PHP w programie Patch the Planet, zgłosił bezwarunkowe RCE o tej samej przyczynie źródłowej, tego samego dnia to samo zgłosił OpenAI, a 24 sierpnia dołączył raport Wiz. Ta sama technologia, która budzi obawy w kontekście bezpieczeństwa agentów AI, po stronie obrońców po prostu działa, a AI przeglądające kod zaliczyło tu najgłośniejszy przypadek w historii języka. PHP Foundation liczy od 1 lipca 15 opublikowanych CVE i ponad 100 raportów błędnych, zduplikowanych albo niereprodukowalnych, więc skala badań wspomaganych modelami rośnie.

Kto jest zagrożony

Krótko: każdy, kto serwuje ruch na PHP. Dla statycznych stron, generatorów typu Hugo i czystych frontendów w JavaScript ta luka nie istnieje. WordPress, Joomla, Drupal, MediaWiki, phpMyAdmin, Nextcloud, Magento czy Laravel to natomiast dokładnie ten świat, a Calif potwierdziło RCE bez logowania na jedenastu aplikacjach, od WordPressa 7.1.2 po WHMCS. Najbardziej narażeni są administratorzy własnych VPS-ów i serwerów z mod_php, bo to tam php.net wskazuje udowodniony wektor bez autoryzacji. Użytkownik hostingu współdzielonego jest w pozycji zależnej od operatora: na większych platformach aktualizacja PHP dochodzi z opóźnieniem liczonym w godzinach albo dniach, więc pytanie do obsługi „kiedy 8.4.27” jest w pełni uzasadnione. Ten blog sam chodzi na PHP 8.4 i na wieczór 21 października dalej czeka na 8.4.27 u swojego operatora, więc piszę o tym bez distansu.

Co robić: aktualizacja i obejścia

Aktualizacja do 8.5.12, 8.4.27, 8.3.36 albo 8.2.35 to jedyne pełne rozwiązanie, i tak brzmi stanowisko php.net: nie ma kompletnych mitygacji, aktualizacja jest jedynym bezpiecznym wyborem. Dystrybucje Linuksa i dostawcy LTS dostali łatki z wyprzedzeniem, więc na własnych serwerach szukaj paczek u swojego vendora. Dla PHP 7.4, 8.0 i 8.1, które nie otrzymują już oficjalnych aktualizacji, zespół bezpieczeństwa PHP przygotował minimalne backporty do samodzielnej kompilacji, a repozytorium remirepo w dniu wydania nie miało jeszcze paczek. Jeśli aktualizacja jest niemożliwa od ręki, php.net podaje obejścia redukujące ekspozycję:

  • dla ścieżki CVE-2026-109619 ustawić session.upload_progress.enabled=0 i zrestartować procesy robocze, co blokuje potwierdzone ścieżki sesyjne, ale nie wszystkie warianty,
  • dla CVE-2026-109618 ustawić memory_limit=-1 w konfiguracji, której aplikacja nie nadpisze (php_admin_value w puli FPM), i obniżyć post_max_size, na przykład do 8M, gdy strona nie przyjmuje plików,
  • na PHP 8.5 dodatkowo fatal_error_backtraces=0 z restartem workerów.

Zastrzeżenie jest takie samo u php.net, Wiz i Cloudflare: to środki redukujące ryzyko konkretnej ścieżki, nie zamiennik łatki. Klientów Cloudflare WAF chroni dodatkowo automatycznie na wszystkich planach, w tym darmowym, od 21 października 3:02 UTC, przy czym firma wdrożyła reguły około 9 godzin przed publikacją szczegółów i uruchomiła nową zdolność „full transaction detection”, która analizuje także odpowiedź serwera, by odróżnić udany exploit od zwykłego ruchu.

Wyciek, NCSC i reakcje

Koordynowane ujawnienie pękło na dwa dni przed premierą łat. 20 października około 15:00 UTC po sieci poszły numery obu CVE z błędną godziną wydania i CVSS 10.0, podczas gdy oficjalna ocena php.net to CVSS v4.0 9.2 dla obu luk; dziesiątka pochodziła z plotki, którą użytkownik petecooper wkleił na Hacker News o 15:20 UTC razem z zastrzeżeniem o źródle rzędu „trust me, bro”. PHP opublikowało zapowiedź wcześniej, o 19:30 UTC, i przesunęło wydanie z 22 na 21 października, a około 20:00 UTC firma Calif przez pomyłkę wypuściła film z działającym proof-of-concept, którego kopie rozeszły się po mediach społecznościowych i przyspieszyły powstawanie kolejnych PoC. W komentarzach dało się słyszeć i takie głosy: samueloph pisał, że sama zapowiedź to „zaproszenie dla wszystkich, żeby nasadzić swoje agenty na szukanie tej podatności i jej exploitowanie, dopóki nikt nie może łatkać”, a JonKF podsumował, że odpowiedzialne ujawnianie w 2026 jest zepsute, bo wystarczy mglista sugestia, że luka istnieje, a „jest dość ludzi z dość tokenów AI, żeby szybko ją znaleźć”.

Reakcje instytucji były równie dosadne. Holenderskie centrum bezpieczeństwa NCSC wyłączyło całą swoją stronę, zostawiając komunikat „Vanwege de kwetsbaarheden in PHP hebben wij uit voorzorg onze website (NCSC.NL) tijdelijk offline gehaald”, czyli z powodu luk w PHP profilaktycznie ściągnęli serwis do ziemi; po szczegóły odsyłają do advisory na osobnej domenie i do strony na GitHubie, gdzie prowadzą inwentaryzację oprogramowania zależnego od PHP. Również Finlandia tymczasowo wyłączyła strony rządowe z tych samych powodów, jak relacjonuje Yle. Weteran Hacker News jacquesm, który zgłosił temat NCSC, ocenił to surowo: w czasach takich zagrożeń spodziewałby się, że w 99% statyczna strona informacyjna po prostu działa, a tu jest to „a complete mission fail, both in terms of using PHP and in terms of not having a fall-back plan in place”. Osobnym rozdziałem jest Chainguard, który 21 października o 7:41 UTC, ponad sześć godzin przed umową, jednostronnie opublikował obrazy z gotową łatką, dając atakującym możliwość badania poprawki, zanim świat zdążył się załatać.

Co dalej

W najbliższych dniach liczy się szybkość wdrożeń. PHP Foundation otwarcie pisze, że po wycieku monitorowało pojawiające się PoC i w chwili wydania łat nie zidentyfikowało w sieci żadnego działającego exploita, ale Cloudflare obserwowało już ruch atakowy i próby omijania jego reguł. Sygnały, na które warto zerknąć w logach według Wiz, to nietypowe żądania multipart kończące się błędami limitu pamięci lub seriami HTTP 500, dziwnie duże lub zniekształcone ciasteczka PHPSESSID oraz niewyjaśnione restarty procesów roboczych PHP. Z perspektywy tej strony czekam na aktualizację PHP u operatora hostingu i trzymam WAF przed originem. Z perspektywy branży najciekawszy jest wniosek Wiz o ekonomii: skoro koszt zamiany starej luki w działający exploit spadł o rzędy wielkości, złożoność przestaje być barierą także dla tych, którzy łatać nie zamierzają.

Źródła

Powiązane artykuły