PHP2Shell. Krytyczne luki w PHP wykryte z pomocą AI

Czym jest PHP2Shell i dlaczego to poważna sprawa

PHP2Shell to wspólna nazwa dwóch luk w zarządzaniu pamięcią interpretera PHP. Pierwsza (CVE-2026-109618) dotyczy obsługi braku pamięci, gdy PHP zostaje przerwane w trakcie przygotowywania danych żądania. Druga (CVE-2026-109619) polega na tym, że stan jednego żądania może przetrwać zwolnienie pamięci i zostać użyty przez kolejne żądanie obsługiwane przez ten sam proces.

Według zespołu PHP zagrożone są wszystkie instalacje obsługujące ruch WWW, czyli PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Największe ryzyko dotyczy mod_php, gdzie atak może się zacząć, zanim wykona się jakikolwiek kod aplikacji. Wiz w testach uzyskał zdalne wykonanie kodu bez uwierzytelnienia na aktualnych obrazach WordPressa, Drupala i Joomli.

Skala jest duża, bo PHP według zestawień W3Techs, na które powołuje się Cloudflare, obsługuje blisko 70 proc. stron internetowych. Krytyczne błędy w samym rdzeniu PHP zdarzają się rzadko. Heise online przypomina, że poprzedni porównywalny przypadek pochodził z 2017 roku.

Jak modele AI pomogły znaleźć luki

Wiz Research podaje, że w całym projekcie korzystał z własnego narzędzia Wiz Atlas oraz modeli Gemini 4 Argon i GPT-5.6 Sol. Modele pomagały w wieloetapowej analizie kodu, dostosowaniu ataku do różnych wersji i konfiguracji PHP oraz w weryfikacji poprawki. Największy wkład firma przypisuje Gemini 4 Argon.

Równolegle luki badała firma Calif w ramach audytu sponsorowanego przez OpenAI w programie Patch the Planet, w którym specjaliści z pomocą modeli OpenAI szukają błędów w otwartym oprogramowaniu. OpenAI opisało całą akcję jako koordynację odpowiedzi na luki wykryte przez agentów AI. Lista podziękowań obejmuje też badacza zespołu OpenAI Codex Security, zespół Gemini w Google i zespół bezpieczeństwa PHP.

• 19 sierpnia 2026 roku - Wiz znajduje pierwszą lukę.
• 20-21 sierpnia - zdalne wykonanie kodu potwierdzone w testach na Drupalu i WordPressie.
• 24 sierpnia - zgłoszenie do zespołu bezpieczeństwa PHP.
• 17 października - Amazon rejestruje w swojej sieci pułapek pierwszą próbę ataku z wykorzystaniem luk.
• 20 października - zespół PHP zapowiada krytyczne wydanie, a informacje o lukach wyciekają przed terminem.
• 21 października - publikacja poprawek i pełne ujawnienie luk.

Które wersje PHP trzeba zainstalować

Poprawki trafiły do wszystkich wspieranych gałęzi. Dystrybucje Linuksa i dostawcy płatnego wsparcia dostali je wcześniej, więc pakiety powinny być dostępne w ich repozytoriach. Zespół PHP zastrzega, że wolontariackie repozytorium remirepo nie miało aktualizacji w dniu premiery.

• PHP 8.5 - wersja 8.5.12.
• PHP 8.4 - wersja 8.4.27.
• PHP 8.3 - wersja 8.3.36.
• PHP 8.2 - wersja 8.2.35. Ta gałąź traci wsparcie 31 grudnia 2026 roku.
• PHP 7.4, 8.0 i 8.1 - brak oficjalnych wydań, tylko minimalne poprawki w kodzie źródłowym i łatki od dostawców wsparcia.

Co zrobić, jeśli aktualizacja nie jest możliwa od razu

Zespół PHP opisał zmiany konfiguracji, które ograniczają część ścieżek ataku, ale wprost zaznacza, że nie zabezpieczają serwera. Należą do nich m.in. wyłączenie śledzenia postępu wysyłania plików w sesji, niższy limit rozmiaru żądań POST i ustawienia limitu pamięci, których aplikacja nie może nadpisać. Heise online cytuje zespół PHP, który nazywa te środki tymczasową protezą.

Dodatkową warstwą są zapory aplikacyjne. Cloudflare włączył reguły blokujące 21 października o 3:02 czasu UTC, kilka godzin przed publikacją luk, także w darmowym planie. Firma informuje, że widzi już ruch atakujący klientów i próby obejścia reguł, ale i tak zaleca aktualizację PHP. Wiz radzi obserwować serwery pod kątem powtarzających się błędów HTTP 500 i nietypowego restartowania procesów PHP.

Jak zareagowały Korea Południowa i Japonia

Korea Południowa 22 października 2026 roku w południe podniosła poziom alarmu cybernetycznego dla sektora prywatnego z pierwszego na drugi z czterech stopni. Jak relacjonuje Seoul Economic Daily, decyzję ogłosił wicepremier i minister nauki i ICT Bae Kyung-hoon. Agencja KISA uruchomiła tryb reagowania kryzysowego, a ministerstwo rozesłało ostrzeżenia do ok. 28 tys. organizacji, w tym firm hostingowych i operatorów centrów danych.

Koreański resort zalecił sprawdzenie wersji PHP we wszystkich serwisach, natychmiastową aktualizację i restart usług, a także przejrzenie starych lub zleconych na zewnątrz stron. Nawet po aktualizacji administratorzy mają szukać śladów włamania w logach. Ministerstwo ostrzega też, że krążący w sieci kod demonstracyjny ataku może zawierać złośliwe oprogramowanie, więc nie należy go uruchamiać.

W Japonii premier Sanae Takaichi wieczorem 21 października zaapelowała na X do operatorów stron o jak najszybszą instalację poprawki, a gdy to niemożliwe, o czasowe wyłączenie serwisu. Według Bloomberga i The Japan Times 22 października strony i usługi online wstrzymały banki, linie lotnicze, firmy i ministerstwa. Koreański Digital Today wymienia wśród firm, które zawiesiły usługi, m.in. platformę sklepów BASE, studio gier Cygames i serwis Pixiv. Firmy podkreślają, że na razie nie stwierdziły włamań, a wyłączenia mają charakter zapobiegawczy.

• Korea Południowa - alarm podniesiony do stopnia ostrzegawczego, ok. 28 tys. organizacji powiadomionych.
• Japonia - apel premier, zapobiegawcze wyłączenia stron banków, przewoźników, firm internetowych i urzędów.
• USA - NSA zaleca czasowe odłączenie serwisu od internetu, jeśli nie da się go od razu zaktualizować.
• Europa - ostrzeżenia wydały m.in. CERT-EU, niemiecki BSI, brytyjskie NCSC i holenderskie NCSC-NL.

Ataki zaczęły się przed publikacją poprawek

Amazon Threat Intelligence podał 21 października 2026 roku, że pierwszą próbę wykorzystania PHP2Shell zarejestrował 17 października w MadPot, czyli sieci serwerów-pułapek udających podatne systemy. Ruch przyszedł przez sieć anonimizującą. Według Amazona była to najpewniej aktywność przestępców, choć firma nie wie, skąd atakujący znali szczegóły luk objętych jeszcze embargiem.

Kolejne sygnały pojawiły się w dniu publikacji. Embargo miało się skończyć 21 października o 14:00 czasu UTC, ale już ok. 2:00 w sieci krążyły pierwsze kody demonstracyjne ataku, a do 8:00 Amazon odnotował kolejne próby z innej anonimizowanej infrastruktury. Różnorodność prób wskazuje według firmy na kilka niezależnych grup. Nie wiadomo, czy którakolwiek z nich zakończyłaby się powodzeniem na prawdziwym serwerze.

Po wydaniu poprawek w ciągu kilku godzin pojawiły się następne kody ataku, użyte niemal natychmiast przeciwko czujnikom Amazona. Firma ocenia, że PHP2Shell jest teraz szeroko wykorzystywany. Amazon nie twierdzi, że w tej kampanii atakujący korzystali z AI, ale zwraca uwagę, że analiza wspomagana przez modele obniża koszt zamiany opisu poprawki w działający atak.

• Zaktualizuj PHP do poprawionej wersji. To jedyne pełne zabezpieczenie.
• Przeglądaj logi serwera i szukaj śladów włamania od co najmniej 17 października, a nie od dnia ujawnienia luk.
• Sprawdź serwery pod kątem nieoczekiwanie uruchomionych procesów i zmienionych plików.
• Czas wdrażania krytycznych poprawek na serwerach dostępnych z internetu mierz w godzinach, a nie w dniach.

Jak OpenAI chce ujawniać luki wykryte przez AI

Na podstawie dwóch miesięcy pracy nad PHP2Shell OpenAI opisało pięcioetapowy schemat koordynowania ujawniania krytycznych luk w powszechnie używanym oprogramowaniu. Dotyczy on błędów obejmujących wiele produktów naraz, przy których dystrybucje systemów, firmy hostingowe i dostawcy zabezpieczeń potrzebują czasu na przygotowanie. Schemat streścił 22 października 2026 roku serwis Help Net Security.

OpenAI zakłada, że wczesną informację dostają organizacje wybrane według trzech kryteriów: roli w ochronie innych, czasu potrzebnego na reakcję i zdolności do zachowania poufności. Ostateczną decyzję podejmują opiekunowie projektu, a każdy uczestnik dostaje tylko to, czego potrzebuje do swojej pracy. Harmonogram ma być skracany, gdy luka zaczyna być wykorzystywana, przecieka albo zdradza ją publiczna poprawka. Przy PHP2Shell próby ataków pojawiły się jeszcze przed końcem embarga.

Firma przyznaje, że wiele kwestii pozostaje nierozstrzygniętych. Chodzi m.in. o długość embarga, wybór między szerokim ostrzeżeniem a ryzykiem przecieku oraz łatanie starych wersji pakietów bez wsparcia. OpenAI spodziewa się, że takich znalezisk w najbliższych miesiącach gwałtownie przybędzie. W naszej ocenie dla polskich administratorów oznacza to częstsze krytyczne poprawki i coraz krótszy czas między ujawnieniem luki a pierwszymi atakami.

1. Potwierdzenie i poprawka. Opiekunowie projektu, badacze i partnerzy weryfikują błąd i testują łatkę, także z pomocą modeli AI szukających sposobów jej obejścia.
2. Wczesne ostrzeżenie. Dystrybucje, firmy hostingowe i dostawcy zapór aplikacyjnych przygotowują aktualizacje i reguły ochronne.
3. Udział administracji. Przy PHP2Shell OpenAI i partnerzy poinformowali m.in. amerykańskie Biuro Krajowego Dyrektora ds. Cyberbezpieczeństwa (ONCD), agencję CISA i partnerów zagranicznych.
4. Poszerzenie kręgu. Po ustaleniu poprawki i planu ujawnienia informacja trafia do kolejnych dystrybutorów, dostawców i operatorów.
5. Publikacja wskazówek. Po wydaniu poprawki zespoły publikują zalecenia i pomagają we wdrażaniu.

Ograniczenia i niewiadome

Próby ataków potwierdzają Amazon, Cloudflare i firma watchTowr, ale w chwili sprawdzenia żadna z nich nie opisała publicznie skutecznego włamania na produkcyjny serwer. Nie wiadomo też, jak atakujący zdobyli informacje o lukach przed końcem embarga. Zespół PHP w dniu publikacji pisał, że nie znalazł działającego kodu ataku, a Tenable nie zweryfikował krążących w sieci kodów. Luki nie trafiły jeszcze do katalogu aktywnie wykorzystywanych podatności amerykańskiej agencji CISA.

Opisy udziału AI pochodzą od firm, które tę technologię sprzedają lub rozwijają. Wiz nie wyjaśnia, jaką część pracy wykonały modele, a jaką ludzie, a OpenAI i Wiz przedstawiają podział zasług nieco inaczej. Hasło o 70 proc. internetu dotyczy udziału PHP wśród stron, a nie liczby serwerów faktycznie podatnych na atak.

Co oznacza to dla polskich stron i firm

W Polsce PHP napędza większość stron małych firm, sklepów i instytucji, zwykle przez WordPressa, PrestaShop czy Joomlę na hostingu współdzielonym. W takim modelu wersję interpretera aktualizuje dostawca hostingu, a nie właściciel strony. Warto sprawdzić w panelu hostingu, którą wersję PHP używa strona, i zapytać dostawcę o termin instalacji poprawek.

Firmy z własnymi serwerami, kontenerami Docker i urządzeniami sieciowymi z wbudowanym PHP powinny przejrzeć całą infrastrukturę, nie tylko strony WWW. Do chwili sprawdzenia CERT Polska nie opublikował osobnego komunikatu, ale incydenty można zgłaszać przez incydent.cert.pl. W naszej ocenie PHP2Shell to kolejny po Chrome 155 przypadek, w którym modele AI realnie przyspieszyły wykrywanie poważnych luk, co oznacza też krótszy czas na reakcję po stronie administratorów.