PHP2Shell: krytyczna luka w PHP wyłączyła część internetu. Co z Twoją stroną i SEO

Spis treści7 części

Co się stało

Zespół bezpieczeństwa PHP ogłosił 21 października 2026 r. krytyczną lukę w samym rdzeniu PHP. Opisuje ją tak: PHP przechowuje globalny stan, który chwilowo wskazuje na pamięć bieżącego żądania. W niektórych sytuacjach ten stan nie jest poprawnie czyszczony, więc kolejne żądanie obsługiwane przez ten sam proces może odczytać zwolnioną pamięć. To błąd typu use-after-free, który pozwala zdalnie uruchomić dowolny kod na serwerze.

Luki mają numery CVE-2026-109618 i CVE-2026-109619, a każda dostała 9,2 na 10 w skali CVSS 4.0. Zespół PHP pisze, że atak bez logowania pokazano na Apache z modułem mod_php i na PHP-FPM. Według Fibona najgroźniejszy jest wariant z mod_php, bo atak działa, zanim uruchomi się kod strony.

Poprawione wersje to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Zespół PHP podkreśla, że aktualizacja to jedyna pewna ochrona, bo nie ma ustawienia konfiguracji, które w pełni blokuje atak.

Luki zgłosili badacze z firm Calif i Wiz oraz OpenAI. Według Wiz przy szukaniu błędu i przygotowaniu ataku pomogła sztuczna inteligencja. Według Fibona numery luk krążyły w sieci już 20 października, a Calif omyłkowo opublikował film z demonstracją ataku. Pierwszą próbę wykorzystania luki Amazon zarejestrował 17 października, cztery dni przed publikacją poprawek.

Dlaczego strony znikały z sieci

Na PHP działają WordPress, Drupal, Joomla i Magento, a firma Censys naliczyła ok. 54,9 mln serwisów internetowych na PHP. Wielu administratorów uznało, że bezpieczniej wyłączyć stronę na czas aktualizacji, niż ryzykować przejęcie serwera. CERT Polska zalecał tymczasowe wyłączenie dostępnych z internetu usług PHP tam, gdzie nie zakłóci to pracy.

Według TechRadara swoje usługi wyłączyły m.in.:

• Wikimedia: część usług pomocniczych Wikipedii, np. Toolforge i Cloud VPS,
• Orange: część stron i aplikacji w kilkudziesięciu krajach,
• brytyjska administracja: według ministra 32 usługi rządowe,
• instytucje w Europie: m.in. holenderskie Narodowe Centrum Cyberbezpieczeństwa, port w Rotterdamie, belgijskie MSZ i czeska strona rządowa.

Przerwa w działaniu strony nie oznacza, że ktoś ją zaatakował. W większości przypadków chodziło o ostrożność.

Co zrobili hostingodawcy

Na hostingu współdzielonym PHP aktualizuje dostawca, nie właściciel strony.

• Hostinger zakończył wdrażanie poprawionych wersji 22 października o 06:44 UTC. Poprawki dostały wszystkie wersje od 5.2 do 8.5 na hostingu Web, Cloud i cPanel. Klienci VPS muszą zaktualizować PHP sami.
• cyber_Folks i Zenbox ogłosiły 21 i 22 października, że poprawki są wgrane, także dla PHP 5 i 7 (według Fibona).
• OVH podało na stronie statusu, że załatało wersje od 7.4 do 8.5 (według Fibona).
• Cloudflare 21 października o 03:02 UTC włączył reguły zapory blokujące znane ataki, także na darmowym planie. To dodatkowa ochrona, nie zamiennik aktualizacji.

Rano 22 października kilku dużych dostawców nie miało jeszcze żadnego komunikatu. Ceny, szybkość i opinie o polskich dostawcach porównuje nasz ranking hostingów.

Co zrobić ze swoją stroną

1. Hosting współdzielony. Znajdź komunikat dostawcy. Jeśli go nie ma, zapytaj na piśmie, czy PHP na Twoim koncie ma poprawkę z 21 października.
2. Własny serwer albo VPS. Zaktualizuj PHP do jednej z poprawionych wersji i zrestartuj procesy PHP. Na Ubuntu i Debianie poprawka może przyjść bez zmiany numeru wersji, więc sprawdź w historii zmian pakietu, czy wymienia oba numery CVE.
3. PHP 8.1 lub starsze. Projekt PHP nie wydał dla tych wersji normalnych aktualizacji. Dla 7.4, 8.0 i 8.1 są tylko poprawki źródeł dla osób, które same kompilują PHP. Przejdź na PHP 8.3 lub nowsze, bo 8.2 traci wsparcie 31 grudnia 2026 r. Wcześniej sprawdź na kopii strony, czy motyw i wtyczki działają.
4. Logi. Przejrzyj logi serwera od 17 października. Jeśli widzisz ślady ataku, samo zmienienie haseł nie wystarczy: przywróć czystą kopię zapasową i wymień hasła oraz klucze API.

W WordPressie wersję PHP sprawdzisz w zakładce Narzędzia → Zdrowie witryny → Informacje, w sekcji Serwer. Nie powie Ci to jednak, czy wersja ma poprawkę.

Co z SEO, jeśli strona leżała

Krótka przerwa nie powinna zaszkodzić pozycjom, jeśli serwer zwracał właściwy kod. Google przy pilnym wyłączeniu strony na 1-2 dni zaleca kod 503. Googlebot po błędach 5xx zwalnia z crawlowaniem, ignoruje treść takich odpowiedzi i zostawia zaindeksowane adresy w indeksie. Gdy strona wraca z kodem 200, tempo crawlowania rośnie stopniowo.

Dwie rzeczy, które mogą narobić szkody:

• 503 na robots.txt. Google pisze wprost, że nie wolno zwracać 503 dla pliku robots.txt, bo to blokuje crawlowanie całej strony.
• Długa przerwa. Jeśli błędy serwera trwają dłużej niż kilka dni, Google w końcu usuwa takie adresy z indeksu. Przy dłuższym wyłączeniu Google zaleca stronę zastępczą z kodem 200.

Po powrocie strony zajrzyj do Search Console: raport Statystyki indeksowania pokaże, kiedy Googlebot dostawał błędy, a raport Problemy z bezpieczeństwem, czy Google nie wykrył przejęcia strony. Przejęte strony często służą do wstawiania ukrytych linków i spamowych podstron, a to już realnie szkodzi widoczności.

Najczęstsze pytania

Czy moja strona na WordPressie jest zagrożona przez PHP2Shell?

Jeśli działa na PHP bez poprawki z 21 października 2026, tak. Luka siedzi w samym PHP, nie w WordPressie, więc dotyczy też Drupala, Joomli, Magento i każdej innej aplikacji w PHP. Według zespołu PHP atak bez logowania pokazano na Apache z mod_php i na PHP-FPM.

Czy wystarczy zaktualizować WordPressa i wtyczki?

Nie. Aktualizacja WordPressa ani wtyczek nie zmienia wersji PHP na serwerze. PHP aktualizuje hostingodawca albo administrator serwera.

Jak sprawdzić, czy hosting załatał PHP?

Najpewniej w komunikacie hostingodawcy. Sam numer wersji może mylić, bo część firm (np. Hostinger, a na serwerach także Ubuntu i Debian) wgrywa poprawkę bez zmiany numeru. W Hostingerze widać to po dacie kompilacji w PHP Info: 21 października 2026 lub późniejsza oznacza poprawkę. Jeśli Twój hosting nic nie napisał, zapytaj go na piśmie.

Czy wyłączenie strony na dzień lub dwa zaszkodzi pozycjom w Google?

Google pisze, że przy pilnym wyłączeniu strony na 1-2 dni należy zwracać kod 503. Googlebot wtedy zwalnia z crawlowaniem, a zaindeksowane adresy zostają w indeksie. Problem zaczyna się, gdy błędy serwera trwają dłużej, bo Google w końcu usuwa takie adresy z indeksu.

Źródła

1. Zespół bezpieczeństwa PHP: CVE-2026-109619 (oss-security) (openwall.com)
2. Krebs on Security: Widespread PHP Flaw May Cause Many Site Outages Today (krebsonsecurity.com)
3. Malwarebytes: PHP2Shell, dlaczego strony znikają z sieci (malwarebytes.com)
4. TechRadar: które duże serwisy wyłączył kryzys PHP (techradar.com)
5. Fibon: PHP2Shell, luka w PHP wyciekła przed łatką (fibon.pl)
6. Hostinger: ochrona przed PHP2Shell (hostinger.com)
7. Google Search Central: błędy HTTP i sieci (developers.google.com)
8. Google Search Central: tymczasowe wyłączenie strony (developers.google.com)