Przejdź do treści
EN Wyceń projekt

Co się właściwie stało?

Każda strona na WordPressie składa się z dwóch warstw. To, co widzisz w panelu (treści, motyw, wtyczki), to WordPress. Pod spodem działa PHP: oprogramowanie na serwerze, które przy każdej wizycie składa stronę z kawałków i wysyła ją do przeglądarki. Można o nim myśleć jak o recepcji w hotelu: przyjmuje każdą prośbę gościa, przygotowuje odpowiedź i bierze kolejnego.

Latem 2026 roku badacze z firm Calif i Wiz, niezależnie od siebie i z pomocą narzędzi AI, znaleźli w tej recepcji dwa błędy. Pierwszy ujawniał się, gdy PHP brakowało pamięci i musiał przerwać pracę w połowie: zostawiał po sobie niedokończone „papiery”, które potem traktował jak ważne. Drugi pozwalał, żeby resztki po jednym zapytaniu przetrwały do następnego. Odpowiednio przygotowane zapytanie z internetu mogło to wykorzystać i zmusić serwer do wykonania obcego polecenia, bez logowania i bez hasła.

W żargonie nazywa się to zdalnym wykonaniem kodu (RCE) i to najpoważniejszy rodzaj luki, jaki może mieć strona. Badacze pokazali działający atak na WordPressa i Drupala. Animacja poniżej pokazuje, jak to działało, w uproszczeniu. Przełącz na „Po poprawce”, żeby zobaczyć różnicę.

Oś czasu: od odkrycia do poprawki

Luka nie wyskoczyła znikąd. Od pierwszego tropu do poprawki minęły ponad dwa lata, a od zgłoszenia badaczy ponad dwa miesiące. Przez ten czas informacja była trzymana w tajemnicy, żeby twórcy PHP i dostawcy serwerów zdążyli przygotować łatki, zanim dowiedzą się o niej przestępcy.

  1. audyt PHP

    Pierwszy trop

    Podczas zewnętrznego audytu bezpieczeństwa PHP programista zauważył problem z obsługą braku pamięci. Nie znalazł wtedy sposobu, żeby go wykorzystać.

  2. Calif

    Odkrycie i zgłoszenie

    Ryan Austin z firmy Calif, z pomocą modelu AI, znajduje sposób na przejęcie serwera i 11 sierpnia po cichu zgłasza go zespołowi PHP. Trzy dni później przekazuje działający dowód.

  3. Wiz

    Drugi zespół, ten sam problem

    Badacze firmy Wiz niezależnie trafiają na te same błędy, pokazują przejęcie WordPressa i Drupala, a 24 sierpnia zgłaszają kolejne sposoby ataku.

  4. OpenAI

    Kolejne drogi ataku

    OpenAI zgłasza następne warianty. Twórcy PHP pracują nad łatką i przekazują ją wcześniej dystrybucjom systemów i dostawcom długiego wsparcia.

  5. Amazon

    Pierwsze próby ataku

    Pułapki Amazona (serwery udające ofiary) rejestrują pierwsze próby wykorzystania luki, jeszcze przed publikacją. Nie wiadomo, czy były skuteczne.

  6. przeciek

    Numery wyciekają do sieci

    Numery CVE zaczynają krążyć po forach. Szczegóły techniczne nie wyciekają, ale zespół PHP publikuje zapowiedź i przyspiesza wydanie poprawki o dobę.

  7. PHP

    Poprawki i ostrzeżenia

    Wychodzą wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Tego samego dnia ostrzegają CERT Polska, brytyjskie NCSC i amerykańska CISA. Cloudflare od rana blokuje znane wzorce ataku.

  8. gov.pl

    Rekomendacja rządu, łatanie serwerów

    Pełnomocnik Rządu do spraw Cyberbezpieczeństwa zaleca natychmiastową aktualizację. Firmy hostingowe kończą instalować poprawki na swoich serwerach.

Ciekawostka, która dużo mówi o 2026 roku: oba zespoły badaczy znalazły luki z pomocą sztucznej inteligencji. Te same narzędzia mają też przestępcy. Dlatego czas od publikacji luki do pierwszych ataków liczy się dziś w godzinach, nie w tygodniach.

Jakie było ryzyko dla zwykłej strony firmowej?

Zdalne wykonanie kodu oznacza, że napastnik może zrobić na serwerze mniej więcej to samo, co sama strona: czytać jej pliki i bazę danych, zmieniać je i dodawać nowe. Badacze pokazali też, że da się odczytać pamięć serwera, w której bywają hasła i klucze do usług. Oto, co to mogło oznaczać w praktyce.

  • Kradzież danych

    Dane klientów z formularzy i zamówień, hasło do bazy danych, klucze do płatności i poczty zapisane na serwerze.

    Dla Ciebie: wyciek danych osobowych, który trzeba zgłosić do UODO w ciągu 72 godzin.

  • Podsłuch płatności w sklepie

    Ukryty skrypt w formularzu zamówienia, który po cichu kopiuje dane kart wpisywane przez klientów.

    Dla Ciebie: klienci tracą pieniądze, a Ty ich zaufanie.

  • Przekierowania do oszustów

    Część gości, często tylko ci z Google albo z telefonów, trafia na fałszywy sklep lub stronę z wirusem.

    Dla Ciebie: czerwone ostrzeżenie w przeglądarce zamiast Twojej strony.

  • Spam w Google

    Tysiące ukrytych podstron z reklamami leków, kasyn albo podróbek, podpiętych pod Twoją domenę.

    Dla Ciebie: spadek w wynikach, zwykle zauważony dopiero po tygodniach.

  • Wysyłka spamu

    Serwer zaczyna rozsyłać spam i fałszywe wiadomości podszywające się pod banki czy kurierów.

    Dla Ciebie: Twoje zwykłe maile zaczynają lądować u klientów w spamie.

  • Zaszyfrowanie plików

    Atak typu ransomware: pliki strony zostają zaszyfrowane albo usunięte, a przestępca żąda okupu.

    Dla Ciebie: strona nie działa, dopóki nie przywrócisz kopii zapasowej.

To scenariusze możliwe, a nie opis tego, co się na pewno wydarzyło. Na dzień 22 października 2026 Amazon, Cloudflare i VulnCheck potwierdzają próby ataków, część z nich nieudanych. Nikt nie podał wiarygodnej liczby przejętych stron. Uczciwie: jeśli hosting załatał serwer w ciągu doby, Twoja strona najpewniej nie ucierpiała. Jeśli nie wiesz, czy to zrobił, warto to sprawdzić.

Kogo to dotyczyło?

Krótko: prawie wszystkich, którzy mają stronę na PHP. Nie miało znaczenia, czy to WordPress, Joomla, PrestaShop, czy własny sklep, ani jaki konkretnie serwer stoi pod spodem. Podatna była każda instalacja PHP, która odpowiada na zapytania z internetu. Według twórców PHP luka sięga co najmniej wersji 5.4 sprzed ponad dekady, a CERT Polska ostrzegał przed wszystkimi wersjami od 5.0.

69,3%stron z rozpoznaną technologią serwera działa na PHP (W3Techs, 22.10.2026)
39,6%wszystkich stron w internecie to WordPress, który bez PHP nie działa

Co musisz zrobić sam, zależy od rodzaju serwera. Jeśli masz zwykły hosting (współdzielony, z panelem), PHP aktualizuje firma hostingowa i większość zrobiła to do 22 października. Jeśli masz własny serwer VPS albo dedykowany, aktualizacja należy do Ciebie lub do osoby, która go dla Ciebie prowadzi. Strony zbudowane w kreatorach typu Wix czy Shopify nie działają na Twoim PHP, więc tu nic nie robisz.

Jak sprawdzić, czy Twoja strona jest bezpieczna

Wystarczy jedna liczba: pełna wersja PHP, na której działa Twoja strona, na przykład 8.3.36. Każda gałąź PHP (8.2, 8.3, 8.4, 8.5) dostała własną poprawkę, więc liczy się ostatnia część numeru. Wpisz swoją wersję, a powiem Ci, co oznacza. Gdzie ją znaleźć, pokazuję zaraz pod spodem.

Gdzie znaleźć wersję PHP (bez wiedzy technicznej)

Masz trzy drogi. Pierwsza zajmuje 30 sekund i wystarczy do niej login do WordPressa. Jeśli go nie masz albo strona nie jest na WordPressie, skorzystaj z drugiej lub trzeciej.

Pytanie o restart nie jest przesadą. PHP działa w procesach, które potrafią pracować tygodniami. Dopóki ich nie uruchomi się ponownie, część z nich może nadal używać starej, dziurawej wersji.

Po czym poznać, że ktoś mógł się włamać

Sama aktualizacja zamyka drzwi, ale nie mówi, czy ktoś nie wszedł wcześniej. Przejdź tę krótką listę. Żaden z punktów nie wymaga umiejętności technicznych, a całość zajmie kwadrans. Odhaczaj to, co sprawdziłeś i jest w porządku.

Coś się nie zgadza? Nie usuwaj niczego na własną rękę, bo zatrzesz ślady. Napisz do hostingu albo do osoby, która opiekuje się stroną. Potem: zmiana wszystkich haseł (WordPress, hosting, baza danych, poczta), przywrócenie czystej kopii, aktualizacja i prośba do Google o ponowne sprawdzenie strony. Jeśli mogły wyciec dane klientów, masz 72 godziny na zgłoszenie do UODO. Próby włamania możesz też zgłosić do CERT Polska.

Darmowe narzędzia, które pomogą

Żadne z nich nie powie Ci, czy PHP jest załatany, bo tego nie widać z zewnątrz. Pokażą za to, czy strona nie została już zainfekowana. Wszystkie są darmowe.

Stan witryny Google

Sprawdza, czy Google nie oznaczył Twojej strony jako niebezpiecznej. To ta sama baza, z której korzystają Chrome i Firefox.

Koszt
0 zł
Sprawdza
czarna lista Google
Sprawdź w Google

Sucuri SiteCheck

Skanuje publiczne strony w poszukiwaniu złośliwego kodu, spamu i przekierowań. Nie widzi plików na serwerze.

Koszt
0 zł
Sprawdza
kod widoczny z zewnątrz
Uruchom skan

Wordfence

Wtyczka do WordPressa, która porównuje pliki strony z oryginałami i wyłapuje podejrzane zmiany.

Koszt
0 zł (wersja darmowa)
Sprawdza
pliki WordPressa
Jak działa skan

Google Search Console

Panel od Google dla właścicieli stron. Wyśle Ci maila, gdy wykryje włamanie lub spam na Twojej domenie.

Koszt
0 zł
Sprawdza
problemy z bezpieczeństwem
Otwórz Search Console

Chcesz też sprawdzić szybkość, błędy i widoczność w Google? Opisałem to w checkliście audytu SEO.

Co zrobiłem na serwerze moich klientów

Strony moich klientów działają na serwerze, którym się opiekuję. 21 października, jeszcze tego samego dnia, zabezpieczyliśmy go regułami, które blokują znane próby ataku, a 22 października zainstalowaliśmy oficjalną poprawkę PHP. Klienci dostali krótką wiadomość, że wszystko jest w porządku i nie muszą nic robić.

Nie piszę tego, żeby się chwalić. Tak po prostu powinno wyglądać utrzymanie strony: Ty prowadzisz firmę, a o takie rzeczy dba ktoś inny. Z oczywistych powodów nie opisuję tu szczegółów konfiguracji serwera. Jeśli Twój hosting do tej pory nic nie napisał, to dobry moment, żeby zapytać.

Źródła

  1. Komunikat bezpieczeństwa PHP (21.10.2026) oficjalne poprawki i zalecenia, po angielsku
  2. PHP Foundation: przebieg zgłoszenia i publikacji oś czasu, ocena 9,2
  3. CERT Polska: krytyczne podatności w PHP po polsku
  4. Rekomendacja Pełnomocnika Rządu ds. Cyberbezpieczeństwa po polsku
  5. Calif: opis odkrycia PHP2Shell badacze, którzy zgłosili lukę
  6. Wiz: PHP2Shell drugi zespół badaczy
  7. Amazon: próby ataku przed publikacją
  8. Cloudflare: ochrona przed atakami na PHP
  9. WordPress.org: krytyczna aktualizacja PHP porady dla właścicieli stron
  10. W3Techs: udział PHP w rynku dane z 22.10.2026

Pytania o lukę PHP2Shell