PHP2Shell: dwie krytyczne luki w rdzeniu PHP, które AI pomogło znaleźć w tydzień

PHP2Shell to dwie luki w samym rdzeniu PHP, CVE-2026-109618 i CVE-2026-109619. Obie mają 9,2 w skali CVSS v4.0 i pozwalają bez logowania uruchomić kod na serwerze, zanim zadziała jakakolwiek aplikacja. Poprawki wyszły 21 października 2026 w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.

Liczba luk bywa podawana różnie. Oficjalnie są dwie CVE (i dwa zgłoszenia GHSA), a Wiz opisuje pod nimi cztery konkretne błędy. Trzeciej CVE w tej sprawie nie znalazłem w żadnym ze źródeł pierwotnych.

Teza tego wpisu: AI skróciło znalezienie błędu i zbudowanie exploita do kilku dni, ale naprawa i wdrożenie poprawek zajęły dalej tygodnie i miesiące. Ta asymetria jest ważniejsza niż same numery CVE. Dane zebrałem 22 października 2026. Co potwierdzone, a co jest relacją firm zainteresowanych w sprawie, oznaczam w tekście.

W skrócie:

Dotknięte są wersje PHP od 5.4 do 8.5.11 uruchamiane do obsługi żądań WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najgroźniej jest przy mod_php.
Poprawiona aplikacja (WordPress, Drupal) nie wystarczy. Trzeba zaktualizować sam PHP.
Pierwszą próbę ataku zarejestrował Amazon 17 października, cztery dni przed publikacją poprawek. Czy ataki są masowe, to w źródłach spór.
Modele AI (Gemini 4 Argon, GPT-5.6 Sol) pomogły w znalezieniu błędów, ale te informacje pochodzą od firm, które z tego korzystają.

Co dokładnie jest zepsute

Obie luki to błędy bezpieczeństwa pamięci, wywoływane zwykłym żądaniem HTTP.

	CVE-2026-109618	CVE-2026-109619
Zgłoszenie GHSA	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp
Mechanizm (według Google Cloud i Talos)	Brak pamięci przerywa PHP w chwili, gdy dane żądania są ledwie zainicjowane, a sprzątanie traktuje je jak poprawne.	Stan należący do żądania przeżywa zwolnienie pamięci, a kolejne żądanie na tym samym workerze używa go, zanim zostanie wyzerowany.
CVSS v4.0	9,2	9,2

Wiz rozbija to na cztery błędy: użycie po zwolnieniu (use-after-free) przy odczycie postępu uploadu, wyciek pamięci procesu przez ciasteczko PHPSESSID, use-after-free w śladzie wywołań błędu krytycznego oraz pomyłkę typów w OPcache. Tabela w ich wpisie jest zniekształcona, więc nie przypisuję poszczególnych błędów do numerów CVE. Wspólny mianownik jest jasny: wszystkie zaczynają się od sytuacji, w której PHP kończy się pamięć w złym momencie.

W Wiz zademonstrowano zdalne wykonanie kodu bez uwierzytelnienia na aktualnych obrazach kontenerów WordPressa, Drupala i Joomli oraz niezależny od aplikacji wyciek pamięci. To pokaz producenta, nie niezależny test.

Co załatać i jak

Poprawione wersje: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Dla gałęzi 7.4, 8.0 i 8.1 zespół PHP opublikował tylko minimalne łaty źródłowe, bez wydań, bo te wersje nie są już wspierane. CISA zaleca, żeby systemy z PHP 8.1 lub starszym wyłączyć z sieci, dopóki nie zostaną zaktualizowane. Z Wikipedii nie wynika, czy poprawiono wersje od 5.4 do 7.3. Wsparcie bezpieczeństwa dla PHP 8.2 kończy się 31 grudnia 2026 (Talos), więc tam też planuj dalszą migrację.

Aktualizacja jest jedynym pełnym rozwiązaniem. Jeśli nie możesz zrobić jej od razu, Talos i zespół PHP opisują obejścia, które nie dają pełnej ochrony:

CVE-2026-109618: ustaw memory_limit=-1 w miejscu, którego aplikacje nie nadpiszą (paradoksalnie, bo chodzi o to, żeby błąd braku pamięci nie wystąpił w krytycznym miejscu), obniż post_max_size (8M, a z uploadami 32M) i ogranicz zasoby kontenerem lub cgroupą, która ubija tylko jeden worker.
CVE-2026-109619: ustaw session.upload_progress.enabled=0 w php.ini lub konfiguracji puli (nie przez ini_set() ani .user.ini) i zrestartuj wszystkie workery. W PHP 8.5 dodatkowo fatal_error_backtraces=0.
Reguły WAF (Cloudflare, Google Cloud Armor i inni) to według ich autorów rozwiązanie tymczasowe.

Łatwo przeoczyć PHP wbudowany w obraz kontenera albo w oprogramowanie, którym nie zarządzasz bezpośrednio. CISA każe zinwentaryzować cały PHP, także ten dołączony do innych produktów, i zacząć od systemów wystawionych do internetu.

Ataki: co wiadomo, a co jest sporne

Twierdzenie	Źródło	Status
Próba ataku 17 października, cztery dni przed ujawnieniem	Amazon Threat Intelligence	potwierdzone przez źródło. Amazon pisze, że nie wiadomo, czy ataki zadziałałyby na prawdziwych systemach
21 października od około 2:00 UTC pojawiły się publiczne PoC i próby z różnych adresów	Amazon	potwierdzone przez źródło
„PHP2Shell jest szeroko wykorzystywany”	Amazon, watchTowr	deklaracja dostawców
Brak zaobserwowanych ataków	CISA (21 października), Talos (do 14:00 UTC 21 października)	stan na moment publikacji tych źródeł
Większość publicznych PoC nie działa lub wywala cel	watchTowr	deklaracja dostawcy

To dobry przykład sprzeczności, której nie rozstrzygam. Amazon i watchTowr widzą próby, CISA do 21 października nie widziała ataków i nie dodała luk do katalogu KEV (stan z użytych źródeł). Rozsądny wniosek: próby były, skuteczność masowych ataków nie jest potwierdzona, a Amazon radzi zaczynać dochodzenie od 17 października, nie od daty ujawnienia.

Co sprawdzać w logach, według Wiz i CISA: nietypowe żądania multipart, po których pojawiają się błędy przekroczenia pamięci, powtarzające się odpowiedzi HTTP 500, nienaturalnie duże lub zniekształcone ciasteczka PHPSESSID, niewyjaśnione restarty workerów oraz procesy PHP uruchamiające powłokę lub pobierające narzędzia.

Liczbę „70% internetu” zostawiam bez przejmowania. PHP jest używane na około 69–70% stron, ale to nie to samo co strony podatne. VirusTotal szacuje (za BleepingComputer) ponad 5,1 miliona wystawionych hostów PHP, co jest oszacowaniem ekspozycji, nie liczbą udanych włamań.

Rola AI: co potwierdzone, a co jest narracją firm

Tu jest sedno tematu, ale też najwięcej ostrożności. Tabela z tym, co można i czego nie można powiedzieć:

Twierdzenie	Źródło	Status
Wiz użył Gemini 4 Argon, GPT-5.6 Sol i własnego narzędzia Wiz Atlas „przez cały czas badania”	Wiz	relacja producenta
Argon wniósł „nieoceniony wkład” w znalezienie luki, w pisanie exploita, wykrywanie ataków i weryfikację poprawek	Wiz, Google Cloud	relacja producenta, bez szczegółów
Praca jednej osoby trwała około tygodnia, a exploity dla wielu aplikacji powstawały w godziny	Wiz	relacja producenta
Calif znalazł jeden z błędów, używając GPT-5.6 Sol w programie OpenAI „Patch the Planet”	Wikipedia i streszczenia wpisu OpenAI	potwierdzone wtórnie, wpisu OpenAI nie otworzyłem (błąd 403)
AI „odegrało kluczową rolę” w odkryciu obu luk	Talos	relacja zewnętrznego dostawcy, bez szczegółów

Przy ocenie trzeba pamiętać o układzie interesów. Wiz należy do Alphabetu (według Wikipedii), tak jak Gemini, a firmy, które opisują tę historię, sprzedają detekcję i narzędzia. Niezależnej oceny wkładu AI nikt nie opublikował, a Wikipedia też zaznacza, że wkład AI relacjonują same zaangażowane firmy.

Co natomiast da się policzyć z chronologii Wiz:

Data	Zdarzenie
19 sierpnia 2026	Pierwszy błąd znaleziony
20–21 sierpnia	Potwierdzone RCE bez uwierzytelnienia na Drupalu, a dzień później na WordPressie
24 sierpnia	Zgłoszenie do zespołu bezpieczeństwa PHP
21 września	PHP potwierdza zgłoszenia i zaczyna skoordynowaną poprawkę
21 października	Poprawki i ujawnienie

Od pierwszego błędu do zgłoszenia minęło pięć dni. Od zgłoszenia do poprawek: 58 dni. OpenAI pisze o poprawce, która wymagała dużej zmiany w silniku PHP. Według Wikipedii jeden z błędów braku pamięci znalazł w 2024 roku deweloper PHP w audycie, ale nie został naprawiony, bo zespół nie mógł uzgodnić poprawki, a nikt nie pokazał działającego exploita. Ten element jest wtórny, ale pasuje do tezy: wąskim gardłem nie było znalezienie błędu, tylko decyzja i praca nad naprawą. Moja interpretacja: skoro działający exploit można dziś zbudować w kilka dni, argument „nikt tego nie pokazał” przestaje chronić nienaprawione błędy.

Szczegóły wyciekły też przed zaplanowanym ujawnieniem (piszą o tym Huntress i Wikipedia). To pokazuje, jak krótkie jest okno między „ktoś wie” a „wszyscy wiedzą”.

Co z tego wynika dla zespołu

Zinwentaryzuj PHP wszędzie, także w obrazach kontenerów i oprogramowaniu firm trzecich. Aktualizacja WordPressa nie pomoże: według serwisu Codeable WordPress.org potwierdził, że żadna jego aktualizacja nie jest potrzebna ani planowana.
Zacznij od systemów wystawionych do internetu i od mod_php.
Wersje bez wsparcia (8.1 i starsze) to teraz problem do rozwiązania, nie do odkładania. Poprawek upstream dla nich nie będzie.
Przejrzyj logi od 17 października, nie od 21.
Zaplanuj krótkie okna na łatanie. Skoro pełny cykl „znalezienie, exploit, zgłoszenie” może zająć tydzień, a nie kwartał, wolne wdrażanie poprawek to realne ryzyko. Pomaga automatyczne przebudowywanie obrazów.
Rozważ AI po stronie obrony, ale bez złudzeń. Jak działa skaner Codex Security i jak trudny jest dostęp, opisuję w wpisie o OpenAI Daybreak. Dane o skuteczności takich narzędzi pochodzą dziś głównie od ich producentów. Wybór modeli opisują wpisy o Gemini 4 Argon i GPT-5.6 Sol.

Czego nie wiemy

Czy ataki są masowe i skuteczne. Źródła się różnią, a CISA nie potwierdza.
Jak dokładnie podzielić zasługi w odkryciu między Calif, Wiz i innych. Wpis OpenAI nie był dla mnie dostępny, a w komentarzach pod nim pojawia się twierdzenie, że niezależny badacz był pierwszy. Tego nie zweryfikowałem.
Ile z pracy zrobiło AI, a ile specjalista. Nikt tego niezależnie nie zmierzył.
Czy wersje od 5.4 do 7.3 dostały poprawki.
Dokładnych oficjalnych dat wydań: changelog php.net podaje 22 października, a CISA i inne źródła 21 października.

Źródła

CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 października 2026)
Wiz: PHP2Shell
Google Cloud: Responding to core PHP vulnerabilities
Cisco Talos: Two critical RCEs in PHP core
Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure
BleepingComputer: PHP ships emergency patches (źródło wtórne)
Wikipedia: PHP2Shell (źródło wtórne, część twierdzeń oznaczona tam jako wymagająca cytowania)
PHP: dziennik zmian 8.x