Luka w PHP (PHP2Shell): co zrobić na hostingu, starym PHP i serwerze

Artykuł z 23 października 2026 roku, zaktualizowany 26 października (oś czasu i pierwsze potwierdzone ataki).

W środę 21 października 2026 roku, kilka minut po 15:30 czasu polskiego, zespół PHP opublikował poprawki dwóch krytycznych luk w samym silniku języka (CVE-2026-109618 i CVE-2026-109619). Badacze, którzy je znaleźli, nazwali je PHP2Shell, a polskie media szybko ochrzciły całą sytuację „PHPokalipsą”. Trochę na wyrost, ale tylko trochę: luki pozwalają przejąć serwer bez logowania, a na PHP działają WordPress, WooCommerce, PrestaShop, a nawet Wikipedia.

W ciągu doby Wykop wyłączył serwis i odesłał użytkowników na Facebooka, Fundacja Wikimedia zgłosiła zakłócenia na swoich wiki i celowo wyłączyła część usług zaplecza, a Centralny Ośrodek Informatyki wyłączył strony BIP działające w centralnym systemie. Firmy hostingowe łatały serwery przez całą noc. Poniżej porządkujemy, co się stało, i podpowiadamy, co zrobić w trzech typowych sytuacjach: na hostingu współdzielonym, na starej wersji PHP (np. 7.3) i na własnym serwerze dedykowanym lub VPS.

Co się stało, w skrócie

Obie luki dotyczą tego, jak PHP obsługuje pamięć podczas przetwarzania żądań. Pierwsza (CVE-2026-109618) wiąże się z sytuacją, w której brakuje pamięci w trakcie przygotowywania danych żądania. Druga (CVE-2026-109619) dotyczy danych, które po zakończeniu jednego żądania mogą zostać użyte przez kolejne. W efekcie atakujący może zdalnie uruchomić własny kod na serwerze, bez konta i bez hasła. Zagrożone są typowe konfiguracje serwerów WWW: PHP-FPM, Apache z mod_php (według zespołu PHP najbardziej narażony), php-cgi, FrankenPHP i LiteSpeed.

Poprawione wersje to 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Dla wersji 7.4, 8.0 i 8.1, które nie mają już wsparcia, zespół PHP udostępnił poprawki w kodzie źródłowym, z których korzystają dystrybucje i firmy hostingowe. Zespół PHP podkreśla, że nie ma pełnego obejścia: aktualizacja to jedyne bezpieczne rozwiązanie.

Jest w tej historii wątek, który dobrze pokazuje, gdzie dziś jesteśmy. Luki znalazły niezależnie od siebie firmy Calif i Wiz oraz OpenAI, a w poszukiwaniach pomagały modele AI. Atakujący nie czekali na komplet informacji: honeypoty Amazona zarejestrowały pierwszą próbę ataku 17 października, cztery dni przed publikacją poprawek. Okno na spokojną aktualizację „w przyszłym tygodniu” praktycznie zniknęło. O tym, co AI zmienia w bezpieczeństwie sklepów, piszemy też w artykule Czy AI zrobi sklep internetowy?.

Oś czasu

Godziny podajemy w czasie polskim.

• Sierpień 2026. Firmy Calif i Wiz niezależnie zgłaszają zespołowi PHP błędy pozwalające zdalnie wykonać kod. We wrześniu tę samą przyczynę zgłasza OpenAI. Trwa poufne przygotowanie poprawek.
• 17 października (sobota). Honeypoty Amazona rejestrują pierwszą próbę wykorzystania luki.
• 20 października (wtorek), wieczór. Do sieci wyciekają numery CVE. Zespół PHP zapowiada krytyczne wydanie i przyspiesza je z czwartku na środę. Sekurak ostrzega jeszcze tego wieczoru.
• 21 października (środa), przed południem. CERT Polska publikuje ostrzeżenie i radzi, jeśli to możliwe, czasowo wyłączyć publicznie dostępne usługi oparte na PHP. Cloudflare włącza reguły ochronne w swojej zaporze aplikacyjnej (WAF) i informuje o pierwszych atakach.
• 21 października, ok. 15:30. Zespół PHP publikuje wersje 8.2.35, 8.3.36, 8.4.27 i 8.5.12 oraz poprawki źródłowe dla 7.4, 8.0 i 8.1.
• 21 października, popołudnie i wieczór. Wykop wyłącza serwis i przekierowuje użytkowników na swój profil na Facebooku. Powrót, planowany na 17:00, przesuwa się na około 20:00. Po powrocie serwis informuje, że wyłączenie było zapobiegawcze, a wszystkie środowiska działają już na poprawionym PHP. Wikimedia ostrzega przed zakłóceniami na swoich wiki i celowo wyłącza część usług zaplecza, m.in. Toolforge i Cloud VPS. W Holandii prewencyjnie znikają z sieci m.in. serwis Tweakers i strona parlamentu.
• Noc z 21 na 22 października. Hostingi łatają serwery, także dla starych wersji PHP. CloudLinux, z którego korzysta wielu dostawców, udostępnia poprawione PHP od 5.2 do 8.5. Zenbox i dhosting kończą prace nad ranem, a Hostinger raportuje zakończenie aktualizacji o 8:44.
• 22 października (czwartek). home.pl i SEOHOST potwierdzają załatanie wszystkich wersji PHP, także starych. Ministerstwo Cyfryzacji informuje, że Centralny Ośrodek Informatyki czasowo wyłączył strony BIP działające w systemie SSDIP. Przeglądanie tych stron wraca jeszcze tego samego dnia po południu. Firma Sansec ocenia, że publiczne exploity nie działają na domyślnych instalacjach PHP, więc masowy atak jest mniej prawdopodobny, niż się obawiano.
• 23 października (piątek). Zespół PHP publikuje dodatkowy komunikat o problemie związanym z postępem przesyłania plików w sesji (CVE-2026-115560) i zaleca wyłączenie session.upload_progress do najbliższego wydania poprawek. Pojawiają się doniesienia o botnetach dołączających do prób ataku. OVHcloud kończy łatanie najstarszych wersji PHP (5.3-7.3).
• 24-26 października. Aktualizacja z 26 października. Pojawia się pierwsze wiarygodne potwierdzenie udanego ataku w realnym środowisku: honeypot z Apache, mod_php i PHP 8.4.26, w konfiguracji sprzyjającej atakującemu. CrowdSec naliczył między 21 a 25 października 1187 adresów IP próbujących wykorzystać lukę, bez potwierdzonych włamań w swoich danych.

Jak sprawdzić, którą wersję PHP ma Twoja strona

• WordPress: Narzędzia > Zdrowie witryny > zakładka Informacje > sekcja Serwer.
• PrestaShop: Zaawansowane > Informacje (w angielskim panelu Advanced Parameters > Information).
• Panel hostingu: ustawienia PHP dla domeny. Część hostingów pokazuje też datę kompilacji PHP, np. Hostinger w PHP Info.

Liczy się pełny numer wersji, a nie samo „8.3”. Uwaga: dystrybucje Linuksa i część hostingów łata starsze wersje bez zmiany numeru (uprzedzają o tym np. Hostinger i SEOHOST). Wtedy o tym, czy poprawka jest na miejscu, mówi data kompilacji albo komunikat dostawcy, a nie sam numer.

Hosting współdzielony: czy trzeba się martwić?

Mniej niż właściciele własnych serwerów, ale nie zero. Na hostingu współdzielonym PHP aktualizuje dostawca i tym razem większość dużych firm zrobiła to szybko: w ciągu doby, często w nocy, i także dla starych wersji, których zespół PHP już nie wspiera. Kilka przykładów z oficjalnych komunikatów:

• home.pl jeszcze przed publikacją poprawek wdrożył reguły zapory i specjalną konfigurację PHP, a 22 października zakończył aktualizację wszystkich wersji, w tym 8.1 i starszych.
• Hostinger do 22 października wdrożył poprawione wersje od 5.2 do 8.5, dodał reguły zapory i wyłączył session.upload_progress.
• cyber_Folks wdrożył oficjalne poprawki dla 8.2-8.5 i własne łatki dla 5.x, 7.x, 8.0 i 8.1.
• Zenbox i dhosting załatali wszystkie wersje w nocy z 21 na 22 października, a SEOHOST potwierdził zabezpieczenie wszystkich wersji, także starych.
• OVHcloud zaktualizował wersje 7.4-8.5 jeszcze 21 października, a najstarsze (5.3-7.3) do 23 października.

Nie każdy dostawca opublikował komunikat, co nie musi oznaczać, że nic nie zrobił. Jeśli Twojego hostingu nie ma na liście, sprawdź jego stronę statusu albo zapytaj support.

Co zrobić na hostingu współdzielonym:

1. Sprawdź komunikat dostawcy albo zapytaj support wprost, czy wersja PHP na Twoim koncie ma poprawki CVE-2026-109618 i CVE-2026-109619.
2. Jeśli strona działa na PHP starszym niż 8.2, zaplanuj zmianę wersji. Łatka hostingu dla starej wersji to wyjątek na czas kryzysu, a nie powrót do pełnego wsparcia.
3. Zaktualizuj WordPress albo PrestaShop, wtyczki i motyw. Luka w PHP przyciągnęła uwagę, ale nieaktualne wtyczki wciąż są najczęstszą drogą ataku.
4. Upewnij się, że masz aktualną kopię zapasową przechowywaną poza serwerem.

Zostaje jeszcze jedna rzecz, na którą nie masz wpływu: na hostingu współdzielonym jeden serwer obsługuje wiele kont. Są od siebie odizolowane, ale tempo reakcji dostawcy w takim tygodniu jak ten to dobry test, czy jesteś we właściwym miejscu.

Strona na starym PHP, np. 7.3: co teraz?

PHP 7.3 nie dostaje poprawek od 6 grudnia 2021 roku, 7.4 od 28 listopada 2022, 8.0 od 26 listopada 2023, a 8.1 od końca 2025 roku. Tym razem wiele hostingów załatało także te wersje, ale to wyjątek, nie reguła. Dla 7.3 zespół PHP nie przygotował nawet poprawek źródłowych, a strona na takiej wersji jest narażona na wszystkie luki z ostatnich lat, nie tylko na PHP2Shell. Na własnym serwerze jest jeszcze trudniej, bo nie wszystkie panele i repozytoria wydały poprawki dla najstarszych wersji.

Dlaczego strony zostają na starym PHP? Zwykle z trzech powodów: stary motyw albo wtyczka przestaje działać na PHP 8, sklep działa na PrestaShop 1.6 lub 1.7, albo ktoś kiedyś dopisał własny kod, którego nikt nie chce ruszać. To zrozumiałe, ale każdy miesiąc zwłoki zwiększa ryzyko. Plan przejścia:

1. Kopia zapasowa plików i bazy, przechowywana poza serwerem.
2. Kopia testowa strony na PHP 8.3 lub 8.4 (8.2 ma wsparcie bezpieczeństwa tylko do końca 2026 roku).
3. Aktualizacja CMS-a, wtyczek i motywu oraz poprawki niezgodnego kodu. PHP 8 usunął część przestarzałych funkcji (np. create_function czy each), a niektóre błędy, które PHP 7 zgłaszał tylko jako ostrzeżenia, w PHP 8 zatrzymują działanie strony.
4. Testy formularzy, koszyka, płatności, panelu i integracji.
5. Przełączenie wersji na produkcji i obserwacja logów przez kilka dni.

Jeśli sklep działa na PrestaShop 1.7, sama zmiana PHP nie wystarczy, bo ta wersja oficjalnie nie obsługuje PHP 8. Opisujemy to w artykule Migracja PrestaShop 1.7 do wersji 8 i 9.

Jeśli nie możesz zaktualizować od razu, zespół PHP opisał tymczasowe ustawienia, które zmniejszają ryzyko (m.in. wyłączenie session.upload_progress i ograniczenie rozmiaru przesyłanych danych). Sam jednak zaznacza, że nie czynią one instalacji bezpieczną. To most na kilka dni, a nie rozwiązanie.

Serwer dedykowany lub VPS: aktualizacja jest po Twojej stronie

Na własnym serwerze nikt nie zrobi tego za Ciebie. Hostingi piszą wprost, że klienci VPS i serwerów dedykowanych muszą zaktualizować PHP samodzielnie. Lista kontrolna:

1. Spis wersji. Sprawdź wszystkie zainstalowane wersje PHP. Na jednym serwerze często działa kilka naraz, np. osobne pule PHP-FPM dla różnych stron.
2. Aktualizacja z właściwego źródła. Pakiety aktualizujesz tam, skąd pochodzi PHP: z repozytorium dystrybucji (Debian i Ubuntu wydały poprawki), z repozytorium Ondřeja Surý'ego, z Remi albo z panelu: cPanel, Plesk, DirectAdmin. Przy starszych systemach sprawdź, czy Twoja wersja w ogóle dostała łatkę (np. dla Ubuntu 20.04 i 18.04 poprawki są dostępne w ramach Ubuntu Pro).
3. Restart. Zrestartuj PHP-FPM i serwer WWW. Menedżer pakietów zwykle robi to sam, ale nie zawsze, a działające procesy do czasu restartu używają starego kodu.
4. Weryfikacja tam, gdzie działa strona. Polecenie php -v w terminalu pokazuje wersję CLI, która może być inna niż ta, która obsługuje stronę. Sprawdź wersję w panelu CMS-a albo w phpinfo otwartym w przeglądarce, a potem usuń ten plik.
5. Kontenery. Przebuduj obrazy na poprawionym obrazie bazowym i wdróż je ponownie. Oficjalne obrazy Dockera dostały poprawki dla 8.2-8.5, dla starszych wersji nie.
6. Ślady włamania. Skoro pierwsze próby ataku pojawiły się przed publikacją poprawek, przejrzyj serwer pod kątem zmian od 17 października: nowe pliki PHP (zwłaszcza w katalogach na przesyłane pliki), nowe konta administratorów, nieznane zadania cron, nietypowy ruch wychodzący. Jeśli coś znajdziesz, potraktuj to jako incydent: przywróć czystą kopię, zmień hasła i klucze, zgłoś sprawę do CERT Polska.
7. Następny krok. PHP 8.2 ma wsparcie bezpieczeństwa tylko do końca 2026 roku, więc skoro i tak aktualizujesz, przejdź od razu na 8.3 lub 8.4.

Aktualizację PHP na serwerze możesz zlecić nam

Jeśli masz serwer dedykowany albo VPS, a nie masz pod ręką administratora, zrobimy to za Ciebie. Sprawdzimy, jakie wersje PHP działają na serwerze i skąd pochodzą pakiety, zaktualizujemy PHP, przetestujemy WordPress, WooCommerce albo PrestaShop na kopii i przełączymy bez przestoju. Przy okazji przejrzymy serwer pod kątem śladów włamania. Możemy też przejąć regularne aktualizacje, żeby przy następnej takiej luce nikt nie musiał działać w nocy.

Na hostingu współdzielonym pomożemy przenieść stronę lub sklep ze starego PHP na aktualną wersję. Opisz swój serwer albo stronę w formularzu bezpłatnej wyceny albo zacznij od audytu strony i sklepu, który obejmuje też bezpieczeństwo serwera.

Czego uczy ten tydzień

PHP bywa wyśmiewany jako język „starych stron”, a ten tydzień pokazał, ile internetu wciąż na nim stoi: od Wikipedii, przez Wykop, po urzędowe BIP-y i miliony sklepów. Pokazał też dwie rzeczy warte zapamiętania. Po pierwsze, czas od ujawnienia luki do pierwszych ataków liczy się dziś w godzinach, a bywa, że atakujący są szybsi niż poprawka. Po drugie, dobrze zorganizowana branża potrafi zareagować w ciągu jednej nocy, ale tylko tam, gdzie ktoś odpowiada za aktualizacje. Strona, o której wszyscy zapomnieli, na serwerze, którego nikt nie pilnuje, sama się nie załata.

Najczęstsze pytania

Czy aktualizacja WordPressa lub PrestaShop chroni przed tą luką?

Nie. To luka w samym PHP, więc trzeba zaktualizować PHP na serwerze. PrestaShop przypomniał o tym sklepom wprost.

Czy Cloudflare albo inna zapora (WAF) wystarczy?

Reguły zapory, takie jak te wdrożone przez Cloudflare czy hostingi, utrudniają atak, ale nie zastępują aktualizacji. Zespół PHP podkreśla, że nie ma pełnego obejścia.

Mam hosting współdzielony. Czy muszę coś robić?

Sprawdź komunikat dostawcy i wersję PHP. Jeśli używasz wersji starszej niż 8.2, zaplanuj jej zmianę, a wtyczki i motyw zaktualizuj tak czy inaczej.

Skąd mam wiedzieć, czy ktoś już się włamał?

Typowe ślady to nieznane pliki PHP, nowe konta administratorów, zmienione pliki motywu, nieznane zadania cron i nietypowy ruch wychodzący z serwera. Jeśli masz wątpliwości, zleć przegląd bezpieczeństwa.