PHP2Shell: Krytyczne luki w PHP wywołują globalną falę poprawek i zamykania witryn

21 października 2026 roku projekt PHP wydał awaryjne aktualizacje — wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 — aby naprawić dwie krytyczne luki bezpieczeństwa, które badacze bezpieczeństwa i dostawcy nazwali "PHP2Shell", zgodnie z Help Net Security i Kanadyjskim Centrum Cyberbezpieczeństwa. Luki te są śledzone jako CVE-2026-109618 i CVE-2026-109619, obie opisane jako krytyczne pod względem ważności; źródła przeanalizowane do tego artykułu nie podały oficjalnego numerycznego wyniku CVSS.

Co robi luka

Obie luki są błędami bezpieczeństwa pamięci w sposobie, w jaki PHP obsługuje żądania w anomalnych warunkach, zgodnie z Bleeping Computer i Help Net Security. CVE-2026-109618 występuje, gdy błąd braku pamięci przerywa PHP, gdy dane wewnętrznego żądania są tylko częściowo skonfigurowane, więc procedury czyszczące później traktują te niekompletne dane jako ważne. CVE-2026-109619 to luka w stanie przeterminowanym: pamięć związana z jednym żądaniem może zostać zwolniona, a następnie ponownie użyta przez późniejsze żądanie na tym samym procesorze roboczym, zanim zostanie prawidłowo zresetowana, co może ujawnić dane lub umożliwić wykonanie kodu.

Kanadyjskie Centrum Cyberbezpieczeństwa zaklasyfikowało obie jako luki Use-After-Free (CWE-416) i stwierdziło, że pomyślny atak pozwala nieuwierzytelnionemu atakującemu uruchomić dowolny kod na serwerze bez konieczności hasła lub żadnego działania ze strony użytkownika. Agencja stwierdziła, że wdrożenia mod_php stoją w obliczu najwyższego ryzyka, ponieważ udowodniony exploit może wyzwolić błąd zanim jakikolwiek kod aplikacji będzie miał szansę na uruchomienie — opis również używany przez zespół bezpieczeństwa PHP, zgodnie z raportami Bleeping Computer.

Błąd dotyczy każdej instalacji PHP, która obsługuje żądania internetowe, w tym PHP-FPM, Apache'a mod_php, php-cgi, FrankenPHP i LiteSpeed, zgodnie z Bleeping Computer i poradnikiem kanadyjskim. Bazowy kod istniał w PHP przez ponad dziesięć lat, podaje Fortune, chociaż oficjalne poprawki zostały wydane dla aktywnie wspieranych gałęzi 8.2–8.5, z poprawkami na poziomie źródła dostępnymi dla 7.4–8.1, które wyszły poza daty wsparcia na koniec życia.

Jak to zostało odkryte i dlaczego AI jest tu ważne

Zgodnie z Fortune, błędny kod istniał w PHP przez ponad dziesięć lat, ale trzy niezależne strony zbiegły się nad nim w sierpniu 2026 roku: firma bezpieczeństwa Wiz, firma Calif i OpenAI, pracując z PHP Foundation nad poprawką i skoordynowanym ujawnieniem. Fortune podaje, że Wiz wykorzystała modele AI, w tym GPT-5.6 Sol OpenAI i Gemini 4 Argon Google, aby pomóc zrozumieć słabość i zamienić ją na działający exploit. Wiz powiedziała Fortune, że ten przypadek reprezentuje zmianę napędzaną AI, mówiąc, że chociaż podatny kod istniał przez ponad dziesięć lat, to, co się zmieniło, to zdolność naukowców do używania AI do zrozumienia słabości i zamiany ich w działający exploit.

Fortune również podaje, że OpenAI, w swoim własnym oświadczeniu, stwierdziła, że ten epizod pokazał, jak AI może pomóc w odkryciu luk bezpieczeństwa z wpływem na skalę Internetu, podczas gdy jednocześnie przyznając, że te same możliwości AI mogą również pomóc atakującym w szybszym opracowywaniu narzędzi ofensywnych i exploitów.

Próby wykorzystania i wczesna odpowiedź Cloudflare

Cloudflare stwierdziła na swoim blogu, że aktywowała reguły Web Application Firewall o 03:02 UTC 21 października, co opisała jako około dziewięć godzin przed publicznym ujawnieniem luk. Firma wdrożyła siedem "Generic Rules – Anomalous Execution" dla klientów na bezpłatnym planie i osobny zestaw siedmiu równoważnych reguł dla planów płatnych, plus jedną dodatkową regułę, która sprawdza zarówno żądanie, jak i odpowiedź w ramach tej samej transakcji, zgodnie z postem Cloudflare, jak podsumowano przez ppc.land. Ten sam post stwierdzał, że Cloudflare obserwowała atakujących modyfikujących swoje ładunki exploitów w późniejszym czasie w widocznej próbie uniknięcia nowych reguł, chociaż nie opublikowała dokładnych liczb wolumenu ataków.

Oddzielnie, zespół Threat Intelligence Amazon stwierdzył, że wykrył próby wykorzystania luk, począwszy od 17 października 2026 roku — cztery dni przed publiczną poprawką — zgodnie z Bleeping Computer, co sugeruje, że niektórzy aktorzy zagrożenia mieli dostęp do szczegółów exploitu przed ogólnym ujawnieniem. W przeciwieństwie do tego, poradnik Kanadyjskiego Centrum Cyberbezpieczeństwa stwierdził, że w momencie jego napisania nie zidentyfikowano aktywnego wykorzystania, przy jednoczesnym ostrzeżeniu, że sytuacja mogła szybko ulec zmianie. Te dwie oceny odzwierciedlają różne punkty obserwacji i czas, a nie faktyczne sprzeczności.

Japonia: rząd wzywa do poprawki lub zamknięcia

Luka przyciągnęła szczególnie intensywną uwagę w Japonii. Japońskie Krajowe Biuro Cyberbezpieczeństwa, organizacja następca NISC reorganizowana w lipcu 2025 roku, wydało poradnik wzywający operatorów do sprawdzenia, czy ich witryny działają w PHP i do szybkiego działania, zgodnie z raportem BigGo Finance dotyczącym oświadczenia agencji. Premier Sanae Takaichi opublikowała na X wiadomość określającą to jako "pilną prośbę dla wszystkich, aby odpowiedzieć dzisiaj wieczorem", i stwierdziła, że tymczasowe zawieszenie witryny mogło być skutecznym sposobem na zmniejszenie ryzyka, jeśli natychmiastowego zastosowania poprawki nie było możliwe, podaje BigGo Finance.

Zgodnie z tymi wytycznymi, kilka japońskich usług online przeszło w tryb konserwacji awaryjnej w nocy z 21 października, w tym platformę zarządzania opieką nad dziećmi CoDMON, grę karciankową Shadowverse: Worlds Beyond, konstruktor sklepu internetowego BASE i dostawcę hostingu Sakura Internet, zgodnie z raportem BigGo Finance. Oficjalne poprawki PHP zostały wydane około 22:40 czasu japońskiego, przed pierwotnie zaplanowanym celem o 23:00, podaje ten sam raport.

Oddzielnie, Internet Watch (Impress) podał, że japoński dostawca komunikacji Baltec zawieszył około 23 usług — obejmujące chmurę, rezerwacje, kasy fiskalne i narzędzia do zarządzania wydatkami — po wykryciu nieautoryzowanego dostępu z możliwością ujawnienia danych osobowych. Baltec początkowo przypisywał incydent cyberatakowi mającemu na celu lukę w PHP, ale firma wydała poprawkę w tym samym dniu, stwierdzając, że faktyczną przyczyną była luka we własnej usłudze, a nie w luce PHP, po tym, jak stwierdziła, że pomyliła te dwie kwestie podczas przeglądu swoich środków bezpieczeństwa PHP. Baltec celował na przywrócenie usług na 26 października, podaje Internet Watch.

Skala ekspozycji

PHP zasilę około 70% witryn internetowych na świecie, w tym witryny WordPress, Wikipedia, Microsoft.com i Archive.org, podaje Fortune, powołując się na fakt, że około 40% wszystkich witryn internetowych działa na WordPress, który sam zależy od PHP. Fortune również powołuje się na wstępne skanowanie zidentyfikujące 22,6 miliona potencjalnie podatnych instancji PHP narażonych na Internet.

Co jest wciąż nieznane

Zgodnie z dostępnymi raportami żaden z nich nie potwierdza pomyślnego naruszenia na dużą skalę bezpośrednio spowodowanego exploitem PHP2Shell, w przeciwieństwie do ostrożnych zamknięć. Liczby całkowitych prób wykorzystania różnią się w zależności od źródła i okna pomiaru: dyrektor generalny Cloudflare był cytowany w japońskiej relacji przez Yahoo! News jako opisujący liczbę prób rosnące z tysięcy przed ujawnieniem do dziesiątek tysięcy w ciągu 45 minut i osiągające setki tysięcy w ciągu dwóch godzin, z całkowitą wartością opisaną jako osiągającą miliony do czasu tego raportu; własny blog Cloudflare nie powtórzył te konkretne liczby. Czytelnicy powinni traktować dokładne liczby wolumenu ataków jako wstępne i podlegające weryfikacji przez organizacje je śledzące.