Twórcy PHP opublikowali 21 października 2026 roku poprawki dla dwóch krytycznych podatności (CVE-2026-109618 i CVE-2026-109619, CVSS 9.2), które pozwalają na zdalne wykonanie kodu bez uwierzytelnienia na praktycznie każdym serwerze obsługującym ten język. Luki, nazwane przez badaczy PHP2Shell, odkryły niezależnie od siebie firmy Calif i Wiz przy użyciu modeli GPT-5.6 Sol i Gemini 4 Argon, a błędny kod tkwił w silniku PHP od ponad dekady.
- 21 października 2026 roku opublikowano poprawki dla dwóch krytycznych luk (CVE-2026-109618 i CVE-2026-109619, CVSS 9.2) w silniku PHP, nazwanych PHP2Shell, które umożliwiają zdalne wykonanie kodu bez uwierzytelnienia i dotyczą szacunkowo około 70 proc. stron internetowych, w tym WordPressa, Drupala i Joomli.
- Luki, których błędny kod tkwił w PHP od ponad dekady, odkryły niezależnie od siebie firmy Calif i Wiz przy użyciu modeli GPT-5.6 Sol i Gemini 4 Argon – według Wiz jeden badacz z pomocą modeli AI zbudował działający exploit w tydzień, co wcześniej zajęłoby światowej klasy zespołowi miesiące.
- W Polsce CERT Polska wydał ostrzeżenia (komunikaty 195/2026 i 196/2026) i zalecił aktualizację PHP do wersji 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, a Centralny Ośrodek Informatyki czasowo wyłączył strony BIP działające w systemie SSDIP (ssdip.bip.gov.pl), aby umożliwić wdrożenie zabezpieczeń.
PHP, według szacunków przytaczanych przez Wiz i The Wall Street Journal, obsługuje około 70 proc. stron internetowych, w tym WordPressa, Drupala, Joomlę i MediaWiki (silnik Wikipedii). W reakcji na ujawnienie luk urzędy i instytucje w kilkunastu krajach, w tym w Polsce, czasowo wyłączyły swoje serwisy. CERT Polska opublikował ostrzeżenie we wtorek: https://twitter.com/CERT_Polska/status/2112831868055810558
🚨 Krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu 🚨
Luki oznaczone identyfikatorami CVE-2026-109618 oraz CVE-2026-109619 pozwalają atakującemu na zdalne wykonanie dowolnych poleceń systemowych.
‼️ Podatne są wszystkie wersje PHP od 5.0 w górę. Systemy…
— CERT Polska (@CERT_Polska) October 21, 2026
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Błąd w obsłudze pamięci, a nie w aplikacjach: wystarczy strona „Hello World”
Obie podatności siedzą w samym silniku PHP, w mechanizmach zarządzania pamięcią i obsługi błędów krytycznych. Oznacza to, że bezpieczny kod aplikacji nie chroni przed atakiem. Wiz pisze wprost, że podatna może być nawet prosta aplikacja „Hello World” uruchomiona na niezałatanej wersji PHP.
Mechanizm, w uproszczeniu, wygląda tak: jeśli żądanie HTTP wyczerpie limit pamięci (memory_limit) w niewłaściwym momencie, PHP może pozostawić po sobie częściowo zainicjowane lub zwolnione struktury danych. Kolejne żądanie obsługiwane przez ten sam proces roboczy traktuje te „śmieci” jako poprawne dane. Z tego wynikają dwa skutki:
- CVE-2026-109618 (RCE przez uszkodzenie pamięci przy braku pamięci): PHP Foundation potwierdza pełne zdalne wykonanie kodu na Apache z mod_php przy domyślnych ustawieniach, zanim uruchomi się jakikolwiek kod aplikacji. RCE potwierdzono też na PHP-FPM przez ścieżki aplikacyjne.
- CVE-2026-109619 (RCE przez przestarzały stan globalny): błąd krytyczny pozostawia wskaźniki do pamięci poprzedniego żądania, a następne żądanie z nich korzysta.
Wiz zademonstrował w swoim raporcie zdalne wykonanie kodu bez logowania na najnowszych (w chwili testów) obrazach kontenerowych WordPressa, Drupala i Joomli. Osobno pokazał, że atakujący może odczytać fragmenty pamięci procesu PHP, w której mogą znajdować się hasła, tokeny sesji, klucze API i certyfikaty innych użytkowników. Firma porównuje ten wariant do Heartbleeda z 2014 roku.
Według Wiz podatna jest każda wersja PHP wydana w ostatniej dekadzie, począwszy od 5.4. CERT Polska w swoim komunikacie mówi o wszystkich wersjach od 5.0 w górę. Zespół PHP uznaje konfigurację Apache z mod_php za najbardziej narażoną, ale zagrożone są też PHP-FPM, php-cgi, FrankenPHP i LiteSpeed.
Dwie firmy, trzy modele AI i luka starsza niż ChatGPT
Pierwsze zgłoszenie przyszło 11 sierpnia 2026 roku od badacza o pseudonimie Ryan A z firmy Calif, która audytowała PHP w ramach programu OpenAI Patch the Planet. Do znalezienia błędu użyto modelu GPT-5.6 Sol. Tego samego dnia OpenAI niezależnie zgłosiło tę samą przyczynę źródłową, a 18 września dosłało kolejne wektory ataku.
Wiz, należący do Alphabetu, trafił na te same problemy osobno. Według harmonogramu z raportu firmy:
- 19 sierpnia 2026: odkrycie pierwszej luki przy użyciu Wiz Atlas (autonomicznego narzędzia do badania podatności), Gemini 4 Argon i GPT-5.6 Sol,
- 20 sierpnia: potwierdzone RCE na Drupalu,
- 21 sierpnia: potwierdzone RCE na WordPressie,
- 24 sierpnia: zgłoszenie do zespołu bezpieczeństwa PHP,
- 21 października: publikacja poprawek i ujawnienie.
Wiz podkreśla, że sam błędny kod był w PHP od ponad dziesięciu lat. To, co zmieniło AI, to możliwość zrozumienia tych słabości i przekucia ich w działający exploit. Zbudowanie go wymagało połączenia kilku błędów i dostosowania do układu pamięci każdego celu, co według firmy wcześniej zajęłoby światowej klasy zespołowi miesiące. Z pomocą modeli jeden badacz zrobił to w tydzień. Firma ocenia, że są to prawdopodobnie najpoważniejsze podatności w historii PHP i jedne z najpoważniejszych w historii oprogramowania w ogóle.
Raluca Ada Popa, szefowa bezpieczeństwa Gemini w Google DeepMind, w komentarzu cytowanym przez Wiz, powiedziała:
„Zespół Wiz pokazał, dlaczego AI nowej generacji zmienia zasady gry w cyberobronie” / „frontier AI is a game-changer for cyber defense”
Greg Brockman, współzałożyciel i prezydent OpenAI, napisał we wpisie przytoczonym przez Fortune, że PHP był jego pierwszym językiem programowania, a błąd był obecny w kodzie od 14 lat.
Wypełnij formularz, a my skontaktujemy się z Tobą, aby upewnić się czego potrzebujesz.
PHP Foundation przyznaje: pierwsze ślady widzieliśmy już w 2024 roku
Fundacja PHP opublikowała wyjątkowo szczery wpis, w którym opisuje nie tylko poprawki, ale też własne zaniedbania. Pierwsze oznaki problemu z obsługą braku pamięci zauważył już w 2024 roku programista PHP podczas naprawiania innego błędu zgłoszonego przez Quarkslab, firmę, która przeprowadziła pierwszy od lat zewnętrzny audyt bezpieczeństwa PHP (sfinansowany przez niemiecką Sovereign Tech Agency za pośrednictwem OSTIF).
Teoretyczny exploit został wtedy rozważony, ale nie znaleziono konkretnych wektorów ataku. Zespół bezpieczeństwa PHP, działający na zasadzie konsensusu, opracował kilka konkurencyjnych rozwiązań, każde z wadami: złamanie kompatybilności wstecznej, ryzyko nowych ataków DoS albo konieczność zmian w setkach rozszerzeń. Prace zatrzymywały się i ruszały od nowa przez wiele miesięcy. Fundacja pisze o tym bez owijania:
„Opóźnienie było porażką strukturalną” / „the delay was a structural failure”
Dopiero zgłoszenia od Calif, OpenAI i Wiz w sierpniu 2026 roku pokazały pełną skalę zagrożenia. Od 11 sierpnia naprawa stała się priorytetem numer jeden dla wszystkich osób finansowanych przez fundację, które według jej relacji pracowały również w weekendy.
Fundacja podaje też dane pokazujące skalę zmiany, jaką wprowadziło AI po stronie zgłaszających: od 1 lipca 2026 roku zespół opublikował 15 CVE i przerobił ponad 100 zgłoszeń, które okazały się nieprawidłowe, zduplikowane lub niemożliwe do odtworzenia. Wcześniej w tym roku fundacja skanowała PHP modelem Claude Mythos (we współpracy z Alpha-Omega), a później dołożyła OpenAI Daybreak Red do walidacji raportów. Obecnie PHP audytuje też Trail of Bits.
Ta historia ma dwie warstwy i obie są ważne. Pierwsza jest optymistyczna: modele AI znalazły lukę, której ludzie nie potrafili domknąć przez dwa lata, i zrobiły to zanim trafili na nią przestępcy. Druga jest mniej wygodna. Fundacja PHP sama przyznaje, że problem był znany od 2024 roku, a prace stanęły, bo garstka wolontariuszy i kontraktorów nie miała ani zasobów, ani procesu decyzyjnego, żeby wybrać mniejsze zło. Język obsługujący 70 proc. stron internetowych, w tym banki, sklepy i urzędy, utrzymuje kilkuosobowy zespół, który prosi o sponsoring. Mam wrażenie, że AI tego problemu nie rozwiąże, tylko go wyostrzy. Narzędzia będą znajdować błędy szybciej niż ludzie zdążą je naprawiać, bo ten sam model, który pomaga obrońcom, pomaga też atakującym przerobić łatkę na exploit. Pytanie, które powinny sobie zadać firmy budujące biznes na WordPressie czy Laravelu, brzmi: ile w ostatnim roku zapłaciliśmy za utrzymanie fundamentu, na którym stoimy? W większości przypadków odpowiedź brzmi zero.
Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl
Wyciek, przypadkowe wideo i złamane embargo przyspieszyły publikację
Skoordynowane ujawnienie działało do dwóch dni przed planowaną datą. We wtorek 20 października około 15:00 UTC numery CVE zaczęły krążyć na forach i w mediach społecznościowych, razem z błędną datą publikacji i zawyżoną oceną CVSS 10.0 (faktyczna to 9.2). Szczegóły techniczne nie wyciekły, ale projekt PHP przesunął publikację z 22 na 21 października.
Potem zrobiło się gorzej. Firma Calif przez pomyłkę opublikowała wideo pokazujące swój exploit w działaniu na kilku celach. Nagranie usunięto, ale kopie rozeszły się po sieci i, według fundacji PHP, przyspieszyły powstawanie publicznych prób exploitów. Rankiem 21 października, ponad sześć godzin przed uzgodnioną godziną, firma Chainguard jednostronnie złamała embargo i opublikowała obrazy kontenerowe z poprawką. Fundacja pisze, że każdy atakujący mógł od tego momentu analizować łatkę w postaci binarnej, podczas gdy reszta użytkowników PHP wciąż czekała na wydanie. Zespół PHP monitorował pojawiające się próby exploitów i w momencie publikacji nie zidentyfikował żadnego działającego.
Urzędy w Europie wyłączyły strony, NSA i japońska premier ostrzegają
Po ujawnieniu luk agencje cyberbezpieczeństwa w Europie, Wielkiej Brytanii, Australii, Japonii i USA wezwały do natychmiastowej aktualizacji albo wyłączenia stron do czasu załatania. Amerykańska NSA w mediach społecznościowych zaleciła wyłączenie systemów, których nie da się zaktualizować. Brytyjskie NCSC opublikowało osobny komunikat. O zagrożeniu napisała też premier Japonii Sanae Takaichi.
Według relacji ITwiz i RTE w Holandii wyłączono wybrane serwisy administracji, parlamentu i krajowego centrum cyberbezpieczeństwa, w Danii firma Kombit odłączyła m.in. platformę komunikacji szkolnej, fiński Valtori prewencyjnie wyłączył publiczne usługi sieciowe, a w Wielkiej Brytanii niedostępne były strony władz Edynburga, Bristolu i Oksfordu. Fundacja Wikimedia i Internet Archive również ograniczyły na krótko dostęp do części systemów.
Po stronie infrastruktury Cloudflare, Akamai, AWS, Google Cloud, Microsoft, Fastly, Imperva, Vercel i Automattic (właściciel WordPress.com) przygotowały reguły WAF i inne zabezpieczenia przed publikacją. OpenAI podało, że w ramach koordynacji angażowało m.in. amerykańską CISA, Biuro Krajowego Dyrektora ds. Cyberbezpieczeństwa i partnerów międzynarodowych, i zobowiązało się przeznaczyć 1 mld dolarów na subsydiowany dostęp do narzędzi Daybreak dla organizacji z ograniczonymi zasobami bezpieczeństwa. Firma udostępniła też na GitHubie skrypt php2shell-checker do sprawdzania wersji PHP. OpenAI określa tę sprawę jako jeden z najpoważniejszych incydentów bezpieczeństwa ostatnich lat i zapowiada, że podobnych znalezisk będzie w najbliższych miesiącach wyraźnie więcej.
Za każdą polską firmą AI stoi konkretny człowiek z imieniem i nazwiskiem, często ten sam w kilku miejscach naraz, i to właśnie ludzie, nie tabelki finansowania, są prawdziwym bohaterem tego artykułu.
Jak wygląda sytuacja w Polsce? CERT Polska ostrzega, część BIP wyłączona
CERT Polska wydał 21 października dwa komunikaty (195/2026 i 196/2026), w których zaleca pilną aktualizację do wersji 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, a tam, gdzie nie zakłóci to działania organizacji, tymczasowe wyłączenie usług PHP dostępnych z internetu. Zespół przypomina, że luka dotyczy też popularnych w polskich firmach i urzędach rozwiązań, takich jak WordPress, Joomla czy phpMyAdmin.
Centralny Ośrodek Informatyki czasowo wyłączył strony Biuletynu Informacji Publicznej działające w Scentralizowanym Systemie Dostępu do Informacji Publicznej (ssdip.bip.gov.pl). Jak podaje ITwiz, powołując się na Ministerstwo Cyfryzacji, ma to umożliwić wdrożenie zabezpieczeń. Ograniczenie nie obejmuje wszystkich stron BIP w kraju, tylko te udostępniane przez SSDIP.
Dla administratorów, którzy nie mogą zaktualizować PHP od razu, CERT Polska podaje tymczasowe ustawienia konfiguracyjne:
- memory_limit na -1 (jeśli pozwalają na to zasoby) lub co najmniej 128M,
- post_max_size na 8M lub mniej,
- max_input_vars na 1000 lub mniej,
- session.upload_progress.enabled na Off.
Zespół zaznacza, że nawet komplet tych ustawień nie wyklucza wykorzystania podatności i jedyną pełną ochroną jest aktualizacja. Oddzielny problem mają właściciele stron na starszych liniach PHP (5.6, 7.x, 8.0, 8.1), dla których projekt PHP nie wydaje już poprawek. Tu trzeba liczyć na dostawców dystrybucji Linuksa, hostingów lub producentów oprogramowania. Ślady włamania należy zgłaszać przez incydent.cert.pl.
Dla polskich firm sprawa jest o tyle praktyczna, że znaczna część małych sklepów na WooCommerce, stron firmowych i serwisów na współdzielonym hostingu działa na PHP, którego wersji właściciel nigdy nie sprawdzał. W tej sytuacji sensowny pierwszy krok to zapytanie dostawcy hostingu, czy serwery zostały zaktualizowane, zanim zrobią to za nas boty szukające niezałatanych instalacji.
Źródła i metodologia
Artykuł powstał na podstawie analizy redakcji AIPORT.pl oraz dodatkowych źródeł, w tym raportu technicznego Wiz Research „PHP2Shell” z dnia 21.10.2026, komunikatu PHP Foundation z dnia 21.10.2026, wpisu OpenAI „Patch the Planet” z dnia 21.10.2026 oraz ostrzeżenia CERT Polska z dnia 21.10.2026. Do weryfikacji wykorzystano również artykuł The Wall Street Journal (Robert McMillan, 21.10.2026), komunikat brytyjskiego NCSC, advisory CERT-EU 2026-018, relacje Fortune, RTE, Al Jazeera i CNN oraz polski kontekst z ITwiz z dnia 22.10.2026.
Cytaty Raluki Ady Popy (Google DeepMind) i PHP Foundation zostały zweryfikowane z oryginalnym anglojęzycznym materiałem źródłowym.
Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl.
Artykuł będzie aktualizowany w miarę pojawiania się nowych informacji w temacie podatności PHP2Shell i ich wykorzystania w atakach.
