Twórcy PHP wydali 21 października poprawki dwóch krytycznych luk. Wydanie zapowiedzieli na 14:00 UTC, czyli 16:00 w Polsce. Luki pozwalały obcemu uruchomić kod na serwerze bez logowania, a pierwsze próby ataku widziano jeszcze przed wydaniem.
Ile masz czasu na aktualizację po takiej wiadomości? Zebrane niżej dane mówią: godziny.
Co wydano 21 października
Zespół PHP zapowiedział wydanie dzień wcześniej. Badacze nazwali tę parę luk PHP2Shell, a zespół PHP ocenił każdą na 9,2 w skali do 10 (CVSS v4.0). Wyszły wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Pierwotnie wydanie planowano na 22 października, ale 20 października około 15:00 UTC numery obu błędów zaczęły krążyć na forach, i to z błędną oceną 10,0. Zespół przyspieszył więc o dzień.
Obie luki opisuje PHP Foundation tak:
- CVE-2026-109618. Jeśli żądanie dojdzie do limitu pamięci (
memory_limit) w najgorszym możliwym momencie, PHP zostawia niedokończone dane wewnętrzne i potem uznaje je za poprawne. Pamięć się psuje. - CVE-2026-109619. Błąd krytyczny w złym miejscu zostawia stan wskazujący na pamięć po poprzednim żądaniu. Następne żądanie obsługiwane przez ten sam proces może z niej skorzystać.
Obie siedzą w silniku, a nie w aplikacji, więc dotyczą każdej strony w PHP. Zespół PHP wylicza PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najgorzej jest w mod_php: tam pokazano atak jednym żądaniem bez logowania, zanim wykona się jakikolwiek kod aplikacji. Zdalne wykonanie kodu potwierdzono też na PHP-FPM, przez kod aplikacji. Brytyjskie NCSC pisze, że narażeni są użytkownicy każdej wersji PHP.
Dla właściciela WordPressa albo sklepu ważne jest to, że luki leżą pod aplikacją. Według Wiz, jednej z firm, które je znalazły, tkwią w samym PHP, a nie w aplikacji na wierzchu. Wykonanie kodu bez logowania pokazała na WordPressie i Drupalu. Aktualne wtyczki nie chroniły więc przed tym błędem. Zespół PHP pisze wprost, że pełnym rozwiązaniem jest tylko aktualizacja PHP, a obejścia zmniejszają ryzyko, ale nie robią z instalacji bezpiecznej.
PHP 8.1 i starsze nie dostają już poprawek od zespołu PHP. Dla 7.4, 8.0 i 8.1 przygotował on okrojone poprawki źródeł dla osób, które budują PHP samodzielnie albo nie mają dostawcy z wsparciem długoterminowym. Jak wygląda stare PHP na hostingu, opisaliśmy we wpisie o starym sklepie na PHP 7.4 i nowej stronie na 8.4.
Ile było czasu na aktualizację
| Data (UTC) | Co się stało | Kto to zapisał |
|---|---|---|
| 17 października | pierwsza próba ataku na honeypot (atrapę serwera, która ma przyciągać ataki), cztery dni przed ogłoszeniem | Amazon |
| 20 października, ok. 15:00 | numery CVE krążą po forach, z błędnym czasem wydania i oceną | PHP Foundation |
| 20 października, 19:30 | zespół PHP przyspiesza zapowiedź, wydanie przesunięte z 22 na 21 października | PHP Foundation |
| 20 października, ok. 20:00 | firma, która zgłosiła luki, przez pomyłkę publikuje film z działającym atakiem i go kasuje, kopie krążą dalej | PHP Foundation |
| 21 października, ok. 02:00 | pierwszy przykład ataku w obiegu, do 08:00 kolejne próby na honeypotach | Amazon |
| 21 października, 08:37 | pierwsze żądanie przypominające atak na sensorze laboratorium w Delft, ponad pięć godzin przed wydaniem | Politechnika w Delft |
| 21 października, 14:00 | wydanie poprawek | zespół PHP |
| 26 października | amerykańska agencja CISA wpisuje oba błędy na listę podatności wykorzystywanych w atakach | NVD, CISA |
Co z tego wynika? Dzień wydania poprawki nie był dniem, w którym zaczęły się ataki. Skąd napastnik miał wiedzę już 17 października, Amazon nie wie.
Skala i skuteczność tych prób są niejasne. Arctic Wolf pisze o szerokim skanowaniu i o małej liczbie dowodów na niezawodne wykorzystanie luk na dużą skalę, a Amazon przyznaje, że nie wiadomo, czy jego próby by się powiodły. Laboratorium z Politechniki w Delft zapisało na swoich atrapach i sensorach do 3 listopada 84 213 żądań związanych z PHP2Shell z 795 adresów IP. Zdecydowana większość to sondowanie, ale w 10 597 żądaniach była już próba wykonania kodu. Paniki nie trzeba. Rachunek jest za to prosty: czas na reakcję mierzy się tu w godzinach, nie w dniach.
Dlaczego „zrobię to w weekend” przestaje działać
Tempo, w jakim łatka zamienia się w atak, zależy od tego, ile pracy trzeba, żeby ją zrozumieć. Amazon ocenia w tym samym wpisie o PHP2Shell, że analiza wspomagana przez AI obniża koszt zamiany łatki albo biuletynu w działający atak, więc więcej grup może działać w ciągu godzin, a nawet minut od ujawnienia szczegółów. Radzi administratorom (tłumaczenie nasze): „Przy krytycznych lukach w systemach dostępnych z internetu czas łatania i wdrażania środków zaradczych liczcie w godzinach. Termin 7 albo 30 dni zakłada opóźnienie, którego już nie ma”.
Po stronie znajdujących luki widać to samo. Wiz opisuje, że pierwszą z luk znalazł 19 sierpnia przy pomocy modeli AI, a 21 sierpnia miał potwierdzone wykonanie kodu bez logowania na WordPressie. Według Wiz jeden badacz zrobił w tydzień to, co wcześniej zajęłoby zespołowi światowej klasy miesiące. To deklaracja firmy, która sprzedaje takie narzędzia, więc traktuj ją jak deklarację, a nie pomiar. PHP Foundation pisze podobnie, choć ostrożniej: narzędzia znajdują błędy szybciej niż kiedykolwiek, dla obrońców i dla napastników, a zgłoszeń będzie przybywać. Sam zespół bezpieczeństwa PHP od 1 lipca opublikował 15 numerów CVE i przejrzał ponad sto zgłoszeń, które okazały się błędne, zdublowane albo niemożliwe do odtworzenia.
Czy napastnicy użyli AI przy PHP2Shell? Źródła, które czytaliśmy, tego nie twierdzą. Wiadomo tyle, że po wycieku z 20 października przykłady ataku zaczęły krążyć w niecałą dobę, a udział AI jest udokumentowany po stronie tych, którzy luki znaleźli. Z tego wynika wniosek praktyczny: jeśli łatka bezpieczeństwa leży u Ciebie dłużej niż dzień, zakładaj, że ktoś ją już przeczytał.
Co zrobiliśmy 21 października
Poprawki PHP 8.2, 8.3, 8.4 i 8.5 trafiły na wszystkie działające konta klientów jeszcze tego samego dnia, w niecałe pięć godzin od wydania. Krytyczne poprawki, takie jak PHP2Shell, zawsze mają u nas najwyższy priorytet i wgrywamy je natychmiast po ich pojawieniu się.
Nie wchodzimy na konta po kolei. Uruchamiamy osobny skrypt aktualizacji PHP. Najpierw aktualizuje on konto testowe, potem resztę po jednym. Na każdym sprawdza, czy PHP i jego moduły, także ionCube, wstają po aktualizacji i czy strony odpowiadają bez błędów serwera. Na pierwszym błędzie staje. Monitoring porównuje wersję PHP na każdym koncie z najnowszym wydaniem i zgłasza zaległość.
Sama aktualizacja pakietu nie wystarcza. Proces PHP-FPM trzyma w pamięci stary kod, dopóki go nie przeładujesz, i dlatego Arctic Wolf zaleca zaktualizować PHP i zrestartować właściwe procesy robocze. U nas po aktualizacji pule PHP są przeładowane łagodnie: trwające żądania mają do 10 sekund na dokończenie, a nowe czekają chwilę w kolejce zamiast dostać błąd. Od 1 listopada robi to też automat na koncie po każdej serii łatek, a monitoring zgłasza pulę, która po dwóch godzinach nadal działa na starym kodzie.
Silnik PHP aktualizujemy my. Resztę, czyli WordPressa, wtyczki, motywy, PrestaShop i jego moduły, aktualizujesz Ty albo ustawiasz, żeby aktualizowały się same.
WordPress i sklepy: ustaw raz
WordPress. Wydania poprawkowe rdzenia, czyli bezpieczeństwa i konserwacyjne, domyślnie instalują się same od wersji 3.7. Od 5.6 nowe instalacje biorą też wydania główne. Z wtyczkami i motywami jest inaczej: domyślnie nie aktualizują się same, poza krytycznymi łatkami, które może wypchnąć zespół bezpieczeństwa WordPress.org. Od wersji 5.5 przy każdej wtyczce i każdym motywie jest przełącznik automatycznych aktualizacji, domyślnie wyłączony. Włącz go tam, gdzie wtyczka ma żywego autora i nie rządzi Twoją sprzedażą. Wtyczki od płatności i wysyłki aktualizuj ręcznie, ale w dniu wydania i po zrobieniu kopii.
Tempo liczy się tu najbardziej. W 2025 roku we wtyczkach i motywach WordPressa znaleziono 11 334 nowych luk, a 91 procent z nich siedziało we wtyczkach. Patchstack, firma sprzedająca ochronę dla WordPressa, policzył, że około połowa luk o dużym wpływie jest atakowana w ciągu doby, a dla najczęściej atakowanych mediana czasu do pierwszej próby wynosi 5 godzin. Przy takiej medianie tydzień zwłoki oznacza, że ataki trwają od wielu dni.
PrestaShop. W obrębie jednej wersji głównej aktualizację rdzenia uruchamiasz modułem Update Assistant, z przeglądarki albo z wiersza poleceń. Producent zapewnia, że przy przejściu na przykład z 8.0 na 8.1 motyw i moduły dalej działają, choć w rzadkich przypadkach poprawka bezpieczeństwa może wymagać dostosowania. Skok na nową wersję główną to już migracja i tam producent radzi uznać moduły za niezgodne, dopóki ich autor nie potwierdzi inaczej. Opis wymagań sklepu na naszym hostingu jest na stronie hosting dla PrestaShop.
Sklep jest dziś u innego dostawcy? Przeniesienie stron w PHP robimy bezpłatnie. Zakres opisuje strona migracji.
Co sprawdzić dziś
- Wejdź na ekran „Strony” w panelu i sprawdź wersję PHP każdej strony. Wersje 8.1 i starsze nie dostają już poprawek od zespołu PHP, więc jeśli sklep wymaga starej wersji, miej plan przejścia.
- W WordPressie przejrzyj listę wtyczek i włącz automatyczne aktualizacje tam, gdzie to bezpieczne.
- W PrestaShop sprawdź, na której wersji stoi sklep i czy wiesz, jak uruchomić Update Assistant.
- Ustal, kto aktualizuje sklep, kiedy Ciebie nie ma. PHP2Shell wyszedł w środę o 16:00 czasu polskiego, a CISA dopisała go do listy w poniedziałek. Ataki nie czekają na koniec urlopu.
Źródła
Strony odczytane 3 listopada 2026 (mogą się zmienić, dane Delft odświeżają się co pięć minut):
- PHP, zapowiedź i ogłoszenia z 20, 21 i 23 października 2026:
www.php.net/archive/2026.php - PHP Foundation, wpis o wydaniu z 21 października 2026:
thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ - Amazon, wpis CJ Mosesa z 21 października 2026:
aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ - Delft Threat Intelligence Lab, dane na żywo:
php2shell.delftintellab.com - Arctic Wolf:
arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/ - Wiz:
www.wiz.io/blog/php2shell-php-rce - NCSC:
www.ncsc.gov.uk/news/critical-security-issue-affecting-php - NVD, CVE-2026-109618:
nvd.nist.gov/vuln/detail/CVE-2026-109618 - NVD, CVE-2026-109619:
nvd.nist.gov/vuln/detail/CVE-2026-109619 - WordPress, automatyczne aktualizacje:
developer.wordpress.org/advanced-administration/upgrade/upgrading/ - WordPress 5.5, automatyczne aktualizacje wtyczek i motywów:
make.wordpress.org/core/2020/07/15/controlling-plugin-and-theme-auto-updates-ui-in-wordpress-5-5/ - Patchstack, „State of WordPress Security in 2026”:
www.patchstack.com/whitepaper/state-of-wordpress-security-in-2026/ - PrestaShop, aktualizacje:
devdocs.prestashop-project.org/9/basics/keeping-up-to-date/