Dziś o 16:00 czasu polskiego twórcy PHP wydają poprawkę na dwie krytyczne dziury, które pozwalają obcej osobie uruchomić własny kod na serwerze z twoją stroną. Obie dostały ocenę 9,2 na 10. Problem dotyczy każdej wersji PHP wydanej od 2012 roku, ale oficjalną łatkę dostaną tylko wersje nadal wspierane, czyli 8.2 i nowsze. Jeśli twoja strona stoi na czymś starszym, poprawka nie przyjdzie do niej nigdy.

Jeśli twoja strona stoi na Siteorze, ten problem cię nie dotyczy. Nasz CMS nie działa na PHP, tylko na innym silniku, więc nie ma u ciebie czego łatać i nie musisz dziś nic robić. Czytaj dalej, jeśli masz jeszcze gdzieś stronę na WordPressie, Joomli albo u innego dostawcy.

Jeżeli nie wiesz, czy twoja strona w ogóle używa PHP, to prawdopodobnie używa. Na PHP działają WordPress, Joomla, Drupal, PrestaShop i WooCommerce, czyli zdecydowana większość stron firm, szkół, parafii, klubów i stowarzyszeń w Polsce.

Ten tekst nie jest analizą techniczną. To lista rzeczy, które możesz sprawdzić sam w kilkanaście minut, nawet jeśli twoją stronę stawiał ktoś, kto od trzech lat nie odbiera telefonu.

Co dokładnie się stało

Dwa błędy w rdzeniu PHP, oznaczone jako CVE-2026-109618 i CVE-2026-109619, pozwalają na zdalne wykonanie kodu. W praktyce znaczy to tyle, że atakujący może wgrać na serwer własny plik i robić na stronie to samo, co administrator: podmienić treść, dopisać konto, wysyłać spam, przekierować odwiedzających do oszustwa.

Informacje o dziurach miały zostać opublikowane dopiero razem z poprawką, ale wyciekły dzień wcześniej, 20 października, razem z gotowym narzędziem do ataku. Dlatego firmy zajmujące się bezpieczeństwem spodziewają się masowego skanowania internetu w ciągu kilkunastu minut od publikacji łatki. To nie jest przesada ani straszenie. We wrześniu, przy dziurze w WordPressie, pierwsze próby włamań ruszyły kilka godzin po wydaniu poprawki, bo atakującym wystarczy porównać stary kod z nowym.

Najważniejsza liczba w tej historii jest jednak inna. Z publikowanych zestawień wynika, że około jedna trzecia stron na WordPressie działa dziś na wersji PHP starszej niż wspierana. Te strony nie dostaną poprawki od twórców PHP. Co najwyżej od hostingodawcy, jeśli ten sam z siebie przygotuje własną.

Krok 1. Sprawdź, na jakiej wersji PHP stoisz

Zajmuje to dwie minuty i nie wymaga żadnego programu poza przeglądarką.

1. Zaloguj się do panelu swojego hostingu. To ta strona, na której opłacasz serwer i domenę, zwykle o adresie w rodzaju panel.nazwahostingu.pl.
2. Znajdź sekcję z nazwą swojej domeny. W zależności od firmy nazywa się Hosting, Serwer WWW, Domeny albo Konta FTP.
3. Poszukaj pozycji Wersja PHP albo Ustawienia PHP. Czasem jest schowana pod Konfiguracja albo Zaawansowane.
4. Zapisz sobie numer, który tam widzisz.

Co oznacza to, co zobaczyłeś:

Jeśli w panelu nie ma nic o PHP, to znaczy, że hosting zarządza wersją za ciebie. Wtedy od razu przejdź do kroku drugiego.

Krok 2. Wyślij jeden mail do hostingu

Nie pytaj ogólnie, czy jest bezpiecznie, bo dostaniesz ogólną odpowiedź. Zapytaj o konkret. Skopiuj poniższy tekst, podmień nazwę domeny i wyślij na adres pomocy technicznej.

Dzień dobry,

w związku z poprawką bezpieczeństwa PHP
wydaną 21 października 2026 (CVE-2026-109618
i CVE-2026-109619) proszę o informację
dla mojej domeny NAZWA-DOMENY.PL:

1. Na jakiej wersji PHP pracuje obecnie
   moje konto?
2. Czy poprawka z 21 października została
   już wgrana na serwer, na którym stoi
   moje konto? Jeśli nie, kiedy to nastąpi?
3. Jeśli moje konto pracuje na wersji
   starszej niż 8.2, czy przygotowali
   Państwo dla niej własną poprawkę, czy
   powinienem zaplanować przejście
   na nowszą wersję?

Z góry dziękuję za odpowiedź.

Odpowiedź warto zachować. Jeśli coś się później wydarzy, to jedyny dokument, który pokazuje, że zapytałeś w dniu wydania poprawki.

Krok 3. Jeśli stoisz na starym PHP

Przejście z PHP 7.4 na 8.x zwykle da się zrobić jednym przełącznikiem w panelu hostingu, ale nie rób tego w ciemno. Stare wtyczki i stare motywy potrafią po takiej zmianie przestać działać i strona pokazuje białą stronę zamiast treści. Kolejność, która ratuje przed paniką:

1. Zrób kopię zapasową strony i bazy danych. Większość hostingów ma do tego przycisk Kopia zapasowa albo Backup.
2. Zaktualizuj WordPressa, motyw i wtyczki do najnowszych wersji. To i tak trzeba zrobić, bo sam WordPress miał w ostatnim miesiącu kilka wydań bezpieczeństwa.
3. Dopiero potem przełącz wersję PHP.
4. Przejrzyj stronę: stronę główną, podstrony, formularz kontaktowy i koszyk, jeśli masz sklep.

Jeśli którykolwiek z tych kroków jest poza twoim zasięgiem, to jest właśnie moment na telefon do osoby, która stronę stawiała, albo do kogoś, kto ją przejmie. Dziś, nie w przyszłym tygodniu.

Krok 4. Zanim hosting zdąży, ogranicz straty

Jeżeli masz własny serwer i wiesz, co robisz, firmy zajmujące się bezpieczeństwem wskazują dwa ustawienia w php.ini, które utrudniają atak: wyłączenie śledzenia postępu wysyłania plików oraz tryb ścisłych sesji. To tylko utrudnienie, nie zabezpieczenie, i nie zastępuje aktualizacji. Na hostingu współdzielonym nie masz do tych ustawień dostępu i nie powinieneś się nimi przejmować, tylko dopilnować, żeby hosting wgrał łatkę.

Jak poznać, że ktoś już wszedł

Włamanie na stronę rzadko wygląda jak w filmie. Zwykle wszystko działa normalnie, a strona po cichu pracuje dla kogoś innego. Sygnały, które warto sprawdzić:

• w panelu WordPressa jest konto administratora, którego nie zakładałeś,
• w katalogu z plikami pojawiły się pliki z końcówką .php w miejscach, gdzie powinny być tylko zdjęcia,
• Google pokazuje twoją stronę z opisem, którego nigdy nie napisałeś, często po angielsku albo o lekach,
• strona otwiera się normalnie, kiedy wpisujesz adres ręcznie, ale przekierowuje w inne miejsce, gdy wchodzisz z wyników wyszukiwania,
• poczta z twojej domeny zaczyna trafiać do spamu, bo z serwera wychodzi masowa wysyłka.

Dobrym darmowym sprawdzianem jest raport w Google Search Console w sekcji Bezpieczeństwo i działania ręczne. Jeśli Google zauważył podmianę treści, napisze o tym tam.

Czego ten wpis nie zawiera

Nie publikujemy tu szczegółów technicznych ani sposobu sprawdzenia, czy konkretny serwer jest podatny. Narzędzie do ataku krąży po sieci od wczoraj i nie ma powodu, żeby ułatwiać komukolwiek robotę. Jeśli potrzebujesz szczegółów, znajdziesz je u firm zajmujących się bezpieczeństwem, które opisały sprawę pierwsze.

Gdzie w tym wszystkim jest kreator stron

Jeśli twoja strona stoi w kreatorze, nie masz własnego PHP do łatania. Silnik jest jeden, wspólny dla wszystkich stron, i aktualizuje go dostawca, zwykle zanim właściciel strony dowie się, że coś się wydarzyło. Nie ma wtedy pytania, czy ktoś pamiętał o twoim koncie, bo nie ma czegoś takiego jak twoje osobne konto na starej wersji.

Tak działa Siteor i tak samo działa większość kreatorów. To nie czyni żadnej strony nietykalną, bo bezpieczeństwo to znacznie więcej niż jedna poprawka. Znaczy tyle, że akurat ta robota, ta z dzisiaj, nie jest twoja.

Jeśli dzisiejszy dzień uświadomił ci, że nie wiesz, kto odpowiada za twoją stronę, i nie masz ochoty dowiadywać się tego przy następnej takiej poprawce, napisz do nas. Przeniesienie istniejącej strony to zwykle kwestia kilku dni, bez zmiany adresu i bez utraty pozycji w Google.

Źródła: Sansec, watchTowr, Huntress, Sekurak.