Środa, 21 października, 8:47 rano. Dowiadujemy się o dwóch krytycznych podatnościach w PHP — języku, na którym oparte jest wiele systemów CMS, w tym WordPress. Problem dotyczy większości stron internetowych na całym świecie.

Jak to się zaczęło

Dziś znamy przebieg wydarzeń dokładniej niż tamtego ranka. W sierpniu luki odkryli badacze z firm Calif, Wiz i OpenAI. Zgłosili je twórcom PHP, a ujawnienie zaplanowano na 22 października — kiedy poprawka miała być gotowa. Plan nie wytrzymał. 20 października późnym popołudniem ktoś na forum Hacker News napisał, że w PHP są dwie krytyczne luki i że szczegóły zostaną ujawnione za dwa dni. Wpis został szybko usunięty, ale screenshoty już krążyły po sieci. Kilka godzin później zespół PHP potwierdził: dziury faktycznie są, a poprawka, która je załata, wyjdzie w środę o 16:00.

To oznaczało jedno: przez kilkanaście godzin o luce mógł wiedzieć każdy, a załatać jej nie mógł nikt.

W środę rano — wtedy, kiedy dowiedzieliśmy się i my — Cloudflare zgłosił pierwsze ataki. Po południu rządy prewencyjnie wyłączały swoje strony: w Australii, w Europie. Niemieckie gminy odłączały serwisy od sieci.

Podatności nazwano Php2Shell i oznaczono jako CVE-2026-109618 oraz CVE-2026-109619. Pozwalają atakującemu zrobić na serwerze wszystko — bez logowania. Podatne są wszystkie wersje PHP od 5.4 w górę. Szczegóły techniczne opisał CERT Polska.

W praktyce: ktoś z zewnątrz, bez hasła, mógł przejąć serwer, na którym stoi strona. Razem z tym, co na nim jest — danymi z formularzy, kontami użytkowników, bazą danych. Wiz, jedna z firm, które odkryły luki, uznał je za jedne z najpoważniejszych podatności w historii PHP, a być może w historii oprogramowania w ogóle.

Ryzyko nie było równe

Opiekujemy się stronami z najróżniejszych sektorów. Różnica między włamaniem na firmowy blog a włamaniem do serwisu, który przetwarza dane osobowe setek osób, jest olbrzymia.

Dlatego do klientów z branży prawnej i farmaceutycznej zadzwoniliśmy jeszcze tego samego ranka, zaczynając od tych, u których ryzyko było największe. Rekomendowaliśmy tymczasowe wyłączenie serwerów do czasu instalacji poprawki. Jednak po kontakcie z firmami hostingowymi okazało się, że nie ma takiej możliwości. Postanowiliśmy więc zabezpieczyć wszystkie strony w dostępny dla nas sposób.

Ponad sto kopii zapasowych

Zanim wyszła poprawka, zrobiliśmy ponad sto kopii zapasowych stron naszych klientów. Zapisaliśmy je poza serwerami. Kopia trzymana na tym samym serwerze co strona nie pomoże, jeśli ktoś ten serwer przejmie.

Klientów, których strony były narażone na mniejsze ryzyko, poinformowaliśmy mailowo, kiedy było już po wszystkim — najpierw zajęliśmy się ich stronami.

Poprawka

PHP wydało poprawkę tego samego dnia, 21 października o 16:00, zgodnie z zapowiedzią. Wszystkie strony, którymi się opiekujemy, działały na aktualnych wersjach PHP, więc łatka była dla nich dostępna od razu.

Koordynowaliśmy prace z ośmioma firmami hostingowymi. Najpóźniej o 8:30 następnego dnia poprawka działała na każdym serwerze.

Potem sprawdziliśmy to samodzielnie. Ręcznie, strona po stronie — każdą, którą aktualizujemy. Zleciliśmy też hostingom skanowanie serwerów w trakcie instalacji poprawki i po niej, pod kątem backdoorów: ukrytych furtek, które atakujący zostawia, żeby wrócić, nawet gdy luka jest już załatana.

22 października, 8:47. Dokładnie dobę po pierwszej wiadomości wszystko było sprawdzone. Mogliśmy w spokoju pić herbatę.

O 11:41 przyszedł mail od CERT Polska z oficjalnym powiadomieniem o podatności.

Wynik

Zagrożenie nie było teoretyczne. Kilka dni później firmy zajmujące się bezpieczeństwem potwierdziły, że luki są wykorzystywane w realnych atakach.

Na stronach, którymi się opiekujemy:

  • 0 wykrytych backdoorów
  • 0 śladów udanego ataku
  • 100+ kopii zapasowych zapisanych poza serwerami
  • 8 firm hostingowych, z którymi koordynowaliśmy prace

Jeśli Twoja strona działa na PHP, sprawdź trzy rzeczy:

  1. Jaką masz wersję PHP? Im nowsza tym lepiej, na dzień 28 października 2026 rekomendujemy wersję z gałęzi 8.5.x
  2. Czy dla Twojej wersji PHP jest juz na serwerze zainstaowana łatka? To kluczowe – pomoże podjąć dalsze decyzje o aktualizacjach lub przesiadce na nowszą wersję.
  3. Skan serwera. Poproś hosting o sprawdzenie serwera pod kątem backdoorów. Większość ma to w cenie.

Nasi Klienci ze stałą opieką nie musieli sprawdzać niczego z tej listy.