Grzegorz Adamczyk21 października 2026 zespół PHP wydał łatki na dwie luki, które mogą umożliwić wykonanie kodu na serwerze bez logowania. Nazwano je PHP2Shell. Znaleźli je badacze, część z pomocą AI, a numery luk wyciekły przed planowaną publikacją, więc PHP przyspieszyło wydanie o dzień. Pierwszą próbę ataku Amazon zarejestrował już 17 października, cztery dni przed łatką. To jedna z tych luk, przy których liczą się godziny, a nie tygodnie.
Z tego artykułu dowiesz się:
- Co to jest PHP2Shell i dlaczego mówi się o nim jako o jednej z największych luk od lat
- Jak to odkryto: AI szukało dziury w jednym systemie, a znalazło w całym PHP
- Kogo to dotyczy i co sprawdzić u siebie
- Jak sprawdzić swoją stronę i dlaczego numer wersji potrafi zmylić
- Jak zawodowcy pilnują, żeby takiej luki nie przegapić
Co to jest PHP2Shell
PHP2Shell to wspólna nazwa dwóch luk w samym silniku PHP: CVE-2026-109618 i CVE-2026-109619. Obie mogą dać zdalne wykonanie kodu bez logowania, czyli napastnik może uruchomić na serwerze własne polecenia z uprawnieniami procesu, który obsługuje PHP, nie znając żadnego hasła. Czy to się uda, zależy od konfiguracji serwera. Zespół PHP ocenił każdą na 9,2 w skali 10.
Pierwsza luka dotyczy sytuacji, w której PHP kończy się pamięć. Przerwane żądanie zostawia niedokończone dane, a sprzątanie po nim traktuje je jak poprawne. Druga to stan, który przeżywa jedno żądanie i trafia do następnego, obsłużonego przez ten sam proces.
Najważniejsze zdanie z ogłoszenia na php.net brzmi tak: „There are no complete mitigations, updating is the only safe choice”. Nie ma obejścia, które w pełni chroni. Jedyna bezpieczna droga to aktualizacja do PHP 8.5.12, 8.4.27, 8.3.36 albo 8.2.35.
To nie jest błąd WordPressa, Drupala czy konkretnej wtyczki. To błąd w fundamencie, na którym one stoją. Dlatego zagrożona jest praktycznie każda strona na PHP, także taka, która ma tylko formularz kontaktowy. Zespół PHP wymienia wprost PHP-FPM, Apache z modułem PHP, php-cgi, FrankenPHP i LiteSpeed.
Jak to odkryto: AI szukało dziury w Drupalu
Badacze z Wiz nie szukali błędu w PHP. Szukali luki w systemie do budowy stron i zaprzęgli do tego modele AI. Jeden z nich opowiada w wywiadzie, że wycelowali narzędzie w Drupala i po kilku godzinach model znalazł błąd pamięci w PHP, który da się wywołać przez Drupala. Poproszony o przeniesienie go na WordPressa pracował jeszcze około ośmiu godzin i wrócił z odpowiedzią, że się nie da. Za to znalazł błąd ogólniejszy, który działa na WordPressie, Drupalu i pewnie każdej innej aplikacji w PHP. Tak do PHP2Shell doszedł Wiz.
Na nagraniu pada: „I could not port this bug to WordPress. However, I did find a more generic bug that can be exploited on both WordPress, Drupal, and probably any other PHP application”. Po polsku: nie udało mi się przenieść tego błędu na WordPressa, ale znalazłem ogólniejszy, który działa na WordPressie, Drupalu i pewnie każdej innej aplikacji w PHP.
Wiz napisał na blogu, że w pracy używał modeli Gemini 4 Argon i GPT-5.6 Sol. O pierwszym pisałem przy premierze Gemini 4 Argon. Wiz nie był pierwszy. Według PHP Foundation zespół PHP znał źródło problemu z brakiem pamięci już z audytu w 2024 roku. 11 sierpnia 2026 zdalne wykonanie kodu z tej samej przyczyny zgłosił badacz z firmy Calif, tego samego dnia niezależnie OpenAI, a kolejne drogi ataku Wiz 24 sierpnia i OpenAI 18 września. Dopiero te zgłoszenia pokazały pełną skalę problemu.
Ciekawostka: sama klasa błędu nie jest nowa. Badacz z Wiz mówi w tym samym wywiadzie, że pierwszy raz opisano ją w 2004 roku.
Wyciek przed łatką i próba ataku przed ujawnieniem
Pierwotnie łatki miały wyjść 22 października. 20 października w sieci zaczęły krążyć numery luk, z błędną godziną wydania i zawyżoną oceną 10/10, ale bez szczegółów technicznych. Zespół PHP przyspieszył zapowiedź i przesunął wydanie na 21 października. Wieczorem jedna z firm, które zgłosiły luki, omyłkowo opublikowała film z demonstracją ataku, który ujawnił kilka dodatkowych, choć ograniczonych szczegółów.
- 17.10
Pierwsza próba ataku
Amazon rejestruje w swoich pułapkach próbę wykorzystania PHP2Shell, cztery dni przed ujawnieniem. - 20.10
Wyciek numerów i zapowiedź
W sieci krążą numery luk, bez szczegółów technicznych. PHP przesuwa wydanie z 22 na 21 października. Firma watchTowr potwierdza, że luki są prawdziwe, a Calif omyłkowo publikuje film z demonstracją. - 21.10, rano
Cloudflare włącza ochronę
Reguły zapory dla wszystkich klientów, także darmowych. Szef technologii Cloudflare pisze o pierwszych atakach. - 21.10, 15:30
Łatki
PHP wydaje wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 (czas polski, według CERT-EU). - 22.10, 3:00
Obrazy Dockera
Oficjalne obrazy PHP w wersji alpine z łatką pojawiają się na Docker Hub (czas polski).
Wpis watchTowr z wieczoru 20 października mówi wszystko o nastroju: „We were all supposed to wait until Thursday at 11am ET”. Wszyscy mieli czekać do czwartku.
We were all supposed to wait until Thursday at 11am ET. Information has leaked wrt zero-day embargoed RCE vulns in PHP. We can confirm that they're real. CVE-2926-109618/619 We cannot share further information right now. Take this seriously and apply patches when available.
Rano 21 października Dane Knecht, szef technologii Cloudflare, napisał, że firma widzi pierwsze ataki i że reguły zapory to tylko rozwiązanie na chwilę.
PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show Show more
The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence.
Amazon napisał wprost: „With PHP2Shell, compromise may predate the advisory”. Włamanie mogło nastąpić, zanim ktokolwiek ogłosił lukę. Radzi przeglądać logi co najmniej od 17 października. Inne firmy są ostrożniejsze. Huntress pisze, że nie potwierdziła udanego włamania na systemach klientów. Pewne jest jedno: sondowanie i próby ataku trwały, zanim większość serwerów dostała łatkę.
Niektórzy nie czekali. CERT Polska zalecał tymczasowe wyłączenie usług na PHP dostępnych z internetu, jeśli nie zakłóci to pracy firmy. Firma Sansec wymienia serwisy w Holandii, które wyłączono na czas łatania, w tym stronę parlamentu. Na Reddicie jeden z administratorów napisał krótko: „We had to emergency shut down all servers”.
Kogo dotyczy PHP2Shell i co sprawdzić u siebie
Hosting współdzielony z panelem. Tu zwykle łata dostawca. W Polsce cyber_Folks i Zenbox ogłosili 21 i 22 października, że łatki są wgrane, także na starszych wersjach PHP 5 i 7. OVH podał na stronie statusu, że załatał wersje od 7.4 do 8.5. Jeśli Twój hosting nic nie ogłosił, zapytaj go na piśmie. Rano 22 października kilku dużych dostawców nie miało jeszcze żadnego komunikatu.
Własny serwer (VPS) albo Docker. Tu nikt nie załata za Ciebie. Łatki dostały dystrybucje Linuksa i oficjalne obrazy Dockera, ale serwer pobierze je dopiero, kiedy ktoś je zainstaluje albo przebuduje obraz. Warto wiedzieć, że oficjalny obraz WordPressa z Docker Hub działa na Apache z modułem PHP. To wariant, który zespół PHP uznaje za najgroźniejszy, bo atak działa, zanim ruszy jakikolwiek kod strony. Właśnie na takich obrazach Wiz pokazał atak.
PHP 8.1 i starsze. Te wersje nie dostały standardowych wydań naprawczych, a zespół PHP udostępnił dla 7.4, 8.0 i 8.1 tylko minimalne poprawki źródeł. Według danych W3Techs z 22 października to około 48% stron działających na PHP. Według statystyk WordPress.org to około 36% instalacji WordPressa (moje wyliczenie z ich danych, to dwie różne populacje stron). To nie są odsetki stron niezałatanych: same numery wersji nie pokazują poprawek, które wgrał dostawca. Dla nich zostają łatki dystrybucji (Ubuntu załatało nawet stare wersje w płatnym wsparciu), hostingi, które łatały same, albo przejście na nowsze PHP. Uwaga: PHP 8.2 też traci wsparcie 31 grudnia 2026, więc rozsądnym celem jest 8.3 lub wyżej.
Strona za Cloudflare. Reguły zapory pomagają, ale Cloudflare sam pisze, że nie zastępują łatki. Ruch, który trafia prosto na adres serwera, omija je całkowicie.
Jak sprawdzić swoją stronę
Najtrudniejsze jest to, że numer wersji potrafi zmylić. Ubuntu i Debian łatają PHP, nie zmieniając numeru wersji. Na Ubuntu 24.04 załatane PHP nadal pokazuje 8.3.6. Z kolei obraz Dockera pokazuje 8.3.36 dopiero po przebudowie. Na Reddicie ktoś zapytał wprost, czy jego serwer jest bezpieczny, bo php -v po aktualizacji pokazuje datę sprzed łatki. Pytanie jest uczciwe, a odpowiedź zależy od tego, skąd pochodzi PHP.
Hosting z panelem: sprawdź komunikat dostawcy
Poszukaj na blogu albo stronie statusu swojego hostingu wpisu o PHP2Shell. Brak wpisu oznacza, że warto zapytać mailem, a odpowiedź zachować.
WordPress: zobacz, jaką wersję raportuje PHP
W panelu WordPressa w menu Narzędzia znajdziesz informacje o witrynie, a w nich sekcję Serwer z wersją PHP. To dobre pierwsze sprawdzenie, ale przy PHP z pakietów dystrybucji numer nie powie, czy łatka jest.
Własny serwer: sprawdź pakiet, nie tylko numer
Na Debianie i Ubuntu sprawdź wersję pakietu i jego historię zmian, szukając numerów CVE-2026-109618 i CVE-2026-109619. Polecenie
php -vw konsoli może pokazywać inną binarkę niż ta, która obsługuje stronę.Docker: sprawdź działający kontener
Odczytaj wersję PHP w kontenerze, który obsługuje ruch. Obraz na dysku i działający kontener to dwie różne rzeczy. Po aktualizacji przebuduj obraz z pobraniem nowej bazy i odtwórz kontenery.
Po łatce: restart i logi
Uruchom ponownie wszystkie procesy PHP, bo stary proces dalej serwuje stary kod. Zanim cokolwiek podmienisz, zachowaj logi. Potem przejrzyj je od 17 października. Pamiętaj, że łatka nie usuwa skutków wcześniejszego włamania: jeśli w logach są ślady ataku, potrzebna jest pełna obsługa incydentu, nie tylko aktualizacja i nowe hasła.
PHP 8.1 i starsze nie dostały standardowych wydań naprawczych. Sprawdź, czy hosting albo dostawca pakietów udostępnił poprawkę dla Twojej wersji. Docelowo zaplanuj przejście na wspieraną gałąź PHP, co zwykle oznacza sprawdzenie motywu i wtyczek. Do tego czasu zespół PHP opisuje w advisory na GitHubie ustawienia, które utrudniają atak, i zaznacza, że nie robią one instalacji bezpieczną.
Jak zawodowcy nie przegapiają takich luk
O takiej luce łatwo dowiedzieć się za późno, z przypadkowej wiadomości. Firmy, które zajmują się tym zawodowo, nie polegają na przypadku. Amerykański instytut NIST w wytycznych SP 800-40 opisuje zarządzanie łatkami jako stały proces: wykryć, ocenić, zainstalować i sprawdzić, czy łatka naprawdę działa. W praktyce to trzy nawyki.
1. Nasłuch źródeł, a nie czytanie wiadomości. Komunikaty producentów (php.net, Node.js, WordPress), komunikaty CERT Polska i katalog luk aktywnie wykorzystywanych przez napastników, który prowadzi amerykańska agencja CISA. Większość tych źródeł ma kanał RSS albo dane do pobrania, więc można je czytać automatem, a nie oczami.
2. Filtr pod własne narzędzia. Dziennie wychodzą setki komunikatów. Liczy się tylko to, co dotyczy technologii, na których stoi Twoja firma, i to, co jest poważne. Bez filtra po tygodniu nikt nie czyta alertów.
3. Sprawdzanie tego, co naprawdę działa. Spis technologii w dokumentacji to za mało. Skanery obrazów i serwerów porównują zainstalowane wersje z bazami podatności, a sama aktualizacja liczy się dopiero wtedy, gdy nowa wersja faktycznie obsługuje ruch.
U siebie te trzy rzeczy połączyłem w jeden automat. Dwa razy dziennie czyta komunikaty producentów, CERT Polska i katalog CISA, przepuszcza tylko to, co dotyczy narzędzi, których używam, i wysyła mi krótką wiadomość. Jeśli źródło przestanie odpowiadać, też się o tym dowiem, bo cisza nie może znaczyć „wszystko w porządku”.
Tego samego dnia łatały też Node.js i Java
PHP nie było jedynym pilnym tematem 21 października. Tego samego dnia Node.js wydał łatki na dziesięć luk. Najpoważniejsza, CVE-2026-111497, to błąd w dekoderze kompresji Brotli, który pozwala zdalnie wykonać kod. Poprawione wersje to 22.23.4, 24.22.1 i 26.12.1. Oracle wydał z kolei nadzwyczajny komunikat dla Javy: CVE-2026-91403 w obsłudze szyfrowanych połączeń, z oceną 9,1 na 10, bez wymogu logowania.
Jeśli Twoja firma ma coś na Node.js albo na Javie, warto sprawdzić te wersje w tym samym przebiegu co PHP. Gotowe obrazy aplikacji niosą w środku własną wersję Node, która nie zmienia się sama.
Czego uczy PHP2Shell
Czas między łatką a atakiem się skurczył. Amazon pisze, że reguła „łatamy w ciągu 7 albo 30 dni” zakłada opóźnienie, którego już nie ma. AI pomogło tę lukę znaleźć, a badacz z Wiz mówi w wywiadzie, że dziś z samej łatki da się szybko zbudować atak.
Druga lekcja jest mniej widowiskowa. Konfiguracja, która wygląda na „zawsze najnowsze”, nie znaczy, że najnowsze naprawdę działa. Obraz Dockera albo pakiet dostaje wersję z dnia instalacji i trzyma ją, dopóki ktoś go nie odświeży. Na Reddicie ktoś trafnie wypisał, gdzie podatna wersja lubi się chować: w obrazie bazowym, w konfiguracji narzędzi i w ustawieniach automatycznych testów. Sprawdza się to odczytem z działającego serwera, nie z pliku.
Sprawdzenie wersji PHP na własnej stronie to kilka minut. Więcej o tym, kiedy własny serwer się opłaca, pisałem przy porównaniu n8n na własnym serwerze i w chmurze, a o samym WordPressie w tekście o blokowym budowaniu stron w WordPressie.
Czy mój hosting jest już załatany?
Hostingi współdzielone zwykle łatają same. W Polsce cyber_Folks, Zenbox i OVH ogłosiły, że łatki są wgrane. Jeśli Twój dostawca nic nie napisał, zapytaj go mailem.
Jak sprawdzić wersję PHP mojej strony?
W panelu hostingu, w WordPressie w informacjach o witrynie albo poleceniem php -v na serwerze. Pamiętaj, że Ubuntu i Debian łatają bez zmiany numeru, więc na własnym serwerze sprawdź historię zmian pakietu.
Czy po łatce muszę zmienić hasła?
Oficjalnej rady nie ma. Wiz pokazał jednak, że jedną z dróg ataku da się odczytać pamięć serwera, a w niej bywają hasła i klucze API. Jeśli strona była podatna przez kilka dni, wymiana kluczy do płatności i API jest rozsądną ostrożnością. A jeśli w logach są ślady ataku, sama zmiana haseł nie wystarczy, potrzebna jest obsługa incydentu.
Co z PHP 7.4?
Standardowego wydania naprawczego nie będzie. Zespół PHP udostępnił tylko minimalne poprawki źródeł dla 7.4, 8.0 i 8.1, dla osób, które same kompilują PHP. Część hostingów i dystrybucji załatała starsze wersje we własnym zakresie. Długoterminowo jedyną drogą jest przejście na PHP 8.3 lub nowsze.
