W sobotę 17 października 2026 roku honeypot firmy Amazon zarejestrował próbę ataku na lukę, o której publicznie nie wiedział jeszcze nikt. Oficjalne poprawki wyszły cztery dni później, 21 października o 14:00. Tego samego dnia rozpoczęły się masowe ataki na strony na całym świecie.
Chodziło o dwa błędy w samym silniku PHP, oznaczone jako CVE-2026-109618 i CVE-2026-109619, obydwa ocenione na 9,2 punktu w dziesięciostopniowej skali. Pozwalały uruchomić własny kod na serwerze bez logowania się do czegokolwiek i bez jakiegokolwiek błędu w kodzie samej strony. Podatna była każda strona, stojąca na nieaktualnej wersji PHP, łącznie z takim, który wyświetla jedno zdanie.
Skala reakcji mówi sama za siebie. NSA i brytyjskie NCSC zaleciły organizacjom zdjęcie stron z sieci do czasu aktualizacji. Offline poszły serwisy rządowe w Holandii, Francji, Niemczech, Belgii i Finlandii, w tym holenderski krajowy system tożsamości cyfrowej i strona izby niższej parlamentu. W Wielkiej Brytanii wyłączono strony władz Edynburga, Bristolu i Oksfordu. W Polsce Centralny Ośrodek Informatyki odciął na czas prac system BIP. Według szacunków opartych na danych NASK i W3Techs problem mógł dotyczyć od 200 do 400 tysięcy stron polskich firm i instytucji.
Jeżeli strona Twojego ośrodka stoi na WordPressie, a tak jest w przypadku zdecydowanej większości placówek, to była w tej puli.
Co zrobiliśmy 20 października
Dzień przed wydaniem poprawek szczegóły luki wyciekły do mediów społecznościowych, wyprzedzając planowane ujawnienie. Oficjalnej łatki jeszcze nie było, a termin wydania awaryjnego wyznaczono na następne popołudnie.
Uznałem, że nie będziemy czekać. Materiały o tej luce pojawiały się wtedy w tempie kilku na godzinę, więc przy ich przerabianiu posiłkowałem się AI. Z opisanego mechanizmu ataku złożyłem własną blokadę: kombinację zabezpieczeń na kilku ścieżkach, którymi mógł wejść. Wdrożyliśmy ją tego samego dnia na wszystkich serwerach, które mamy pod opieką.
Powiem wprost, czego wtedy nie wiedziałem: czy to wystarczy. Opis luki był świeży, nie istniało żadne publiczne narzędzie, którym dałoby się sprawdzić skuteczność własnego obejścia, a blokada miała swoją cenę. Przez dobę na stronach naszych klientów nie dało się wgrać zdjęcia do WordPressa. Zdecydowałem, że to akceptowalny koszt.
Żadna z serwisowanych przez nas stron nie była w tym czasie wyłączona. Po wydaniu oficjalnych poprawek zaktualizowaliśmy PHP i zdjąłem własne obejście. Upload zdjęć wrócił, ale już na zaostrzonej konfiguracji, która została u nas na stałe.
Opisuję to nie dlatego, że uważam to za wyczyn, bo nie uważam. Opisuję, bo to jest ta różnica, o której najtrudniej rozmawia się przy podpisywaniu umowy na serwis. Nie polega ona na tym, że ktoś klika „aktualizuj” dwa razy w miesiącu, tylko na tym, że ktoś w ogóle śledzi takie sprawy, potrafi ocenić ryzyko w ciągu kilku godzin i jest gotów podjąć decyzję, która coś kosztuje, zanim pojawi się gotowe rozwiązanie.
Porozmawiajmy o nowej stronie
20 minut przez telefon, bez zobowiązań.
„Kto by się włamywał na stronę ośrodka terapii?”
To pytanie ma sens, dopóki zakłada się, że po drugiej stronie siedzi człowiek, który wybiera cel. Od lat nie siedzi. Skanowaniem zajmują się automaty, które przeczesują sieć pod kątem jednej konkretnej podatności i uderzają wszędzie tam, gdzie ją znajdą. Branża, wielkość placówki i to, czy strona komukolwiek się podoba, nie mają w tym procesie żadnego znaczenia.
Ważne jest też to, czego aktualizacja WordPressa nie załatwia. Październikowe luki siedziały w samym PHP, czyli w warstwie, do której panel WordPressa w ogóle nie sięga. Można było mieć wszystkie wtyczki w najnowszych wersjach i nadal być podatnym. Decydowało to, kto i jak szybko zaktualizował środowisko na serwerze.
I tu zaczyna się właściwy temat. Bo większość właścicieli ośrodków dowiaduje się o awarii strony z telefonu od znajomego. Rzadziej z własnego monitoringu, bo go nie ma. Jeszcze rzadziej od pacjenta, bo pacjent nie dzwoni z informacją, że formularz nie działa: po prostu wybiera następny ośrodek z listy.
Moim zdaniem najgorzej wychodzą na tym ośrodki, które zrobiły stronę dobrze. Nowoczesna, szybka, z działającą rezerwacją: i zostawiona sama sobie na dwa lata, bo przecież działa.
Trzy koszty, które płaci ośrodek, a nie wykonawca
Awaria rzadko kończy się na godzinie przestoju. W placówce zdrowia psychicznego lub ośrodka terapii uzależnień rozkłada się na trzy osobne rachunki.
Pierwszy to zaufanie. Rodzina ocenia ośrodek na podstawie strony, zanim ktokolwiek przekroczy próg budynku. Ostrzeżenie przeglądarki o niebezpiecznej witrynie albo doklejone reklamy kasyn i leków z niepewnego źródła mówią odwiedzającemu dokładnie jedno: tym miejscem nikt się nie zajmuje. Odbudowa reputacji i pozycji w wyszukiwarce po takim incydencie liczy się w miesiącach.
Drugi to dane. Wrócę do niego za chwilę, bo zasługuje na własną sekcję.
Trzeci to zgłoszenia, które nie dotarły. I to jest ten rachunek, którego nikt nie wystawia, bo nie widać go w żadnym zestawieniu.
Dlaczego formularz w ośrodku to szczególny przypadek?
Słyszę czasem, że ośrodek nie przetwarza danych o zdrowiu, bo formularz pyta wyłącznie o imię i numer telefonu. Tyle, że pod spodem jest pole „wiadomość”, a w nim ludzie opisują uzależnienie bliskiej osoby, przebieg interwencji i przyjmowane leki. Nikt ich o to nie pytał, a mimo to te informacje są już na Twoim serwerze.
RODO traktuje dane o zdrowiu jako szczególną kategorię (art. 9) niezależnie od tego, czy zostały zebrane celowo. Przy naruszeniu ochrony takich danych obowiązuje zgłoszenie do organu nadzorczego w ciągu 72 godzin (art. 33), a przy wysokim ryzyku także zawiadomienie osób, których dane wyciekły (art. 34).
Zastrzeżenie: to nie jest porada prawna i nie jestem prawnikiem. Trzy rzeczy, które warto przegadać z inspektorem ochrony danych albo prawnikiem, to treść informacji przy formularzu, czas przechowywania wiadomości i to, kto faktycznie ma do nich dostęp.
Najdroższa awaria to ta, której nie widać
Włamanie z czerwonym ekranem ma jedną zaletę: widać je od razu. Znacznie gorszy jest scenariusz, w którym strona wygląda bez zarzutu, a przestaje działać formularz oddzwonienia, przycisk z numerem telefonu albo rezerwacja terminu.
Wtedy wszystko toczy się dalej. Reklamy się wyświetlają i pochłaniają budżet, pozycje w Google stoją, strona ładuje się szybko. Tylko telefon milczy, a Ty orientujesz się po tygodniu albo dwóch, kiedy zestawisz liczbę zgłoszeń z poprzednim miesiącem.
Osoba, która wysłała formularz i nie dostała odpowiedzi, w zdecydowanej większości przypadków nie próbuje drugi raz.
Co robi serwisant, czego nie widać z zewnątrz?
Serwis jest usługą niewdzięczną, bo gdy działa, nie dzieje się nic. Cztery rzeczy składają się na większość pracy.
Aktualizacje z kontrolą zgodności. Nowa wersja wtyczki potrafi zablokować coś zupełnie innego: najczęściej formularz albo rezerwację. Dlatego aktualizację poprzedza sprawdzenie zgodności, a po wdrożeniu uruchamia się test, który otwiera stronę i wysyła zgłoszenie przez formularz. Jeżeli coś nie przejdzie, system wraca do poprzedniej wersji, zanim ktokolwiek to zobaczy.
Kopie poza serwerem. Kopia zapasowa trzymana na tym samym dysku co strona jest jak zapasowy klucz zostawiony pod wycieraczką: działa do pierwszego poważnego problemu, a potem znika razem z całą resztą. Kopia powinna leżeć na niezależnej infrastrukturze. I to nie wystarczy, bo kopia, z której nigdy nie próbowano odtworzyć strony, jest tylko plikiem o uspokajającej nazwie. Próbę generalną trzeba robić regularnie.
Zabezpieczenie panelu. Większość włamań do stron opartych na WordPressie to nie wyrafinowany atak, tylko robot próbujący haseł po kolei, tysiącami. Blokada konta po kilku nieudanych próbach, ukryty adres logowania i logowanie dwuetapowe zamykają tę drogę niemal całkowicie. Zaporę aplikacyjną potraktuj jak bramkarza: odsiewa podejrzany ruch, zanim ten w ogóle dotrze do drzwi.
Monitoring. Czujnik dymu nie gasi pożaru, tylko skraca czas reakcji, i o to samo chodzi tutaj. System co kilka minut sprawdza, czy strona odpowiada, czy certyfikat nie wygasa i czy w plikach nie pojawiło się coś, czego nikt tam nie wgrywał. Osobno, cyklicznie, wysyła testowe zgłoszenie przez formularz. To jedyny sposób, żeby cichą awarię wykryła maszyna, a nie rodzina pacjenta.
Czy szybkość strony naprawdę przekłada się na zgłoszenia?
Tak. Najczęściej przywoływana liczba pochodzi z badania Google „The Need for Mobile Speed” z 2016 roku, przeprowadzonego na danych z ponad dziesięciu tysięcy domen mobilnych: 53% wizyt kończy się porzuceniem strony, jeżeli ładuje się dłużej niż trzy sekundy.
Dodam od razu zastrzeżenie, bo ta liczba krąży po branży od dekady i bywa cytowana jako prawo natury. Badanie ma dziesięć lat i dotyczyło głównie handlu. Rząd wielkości jest wiarygodny, sama liczba to punkt odniesienia, a nie obietnica.
Z mojego doświadczenia ważniejsze od samej liczby jest to, kto czeka. Osoba, która wchodzi na stronę ośrodka, zwykle robi to w nienajlepszym momencie i bez cierpliwości do czegokolwiek. Wolna strona nie irytuje jej tak, jak irytuje kupującego buty: ona po prostu domyka kartę i odkłada decyzję, czasem na długo.
Po stronie technicznej składa się na to porządek w bazie danych, kompresja zdjęć i poprawnie ustawiony cache. Nudne i skuteczne.
Dlaczego „aktualizacje dwa razy w miesiącu” to za mało?
Bo luka nie zna Twojego harmonogramu. Jeżeli poważna podatność zostanie ujawniona w czwartek, a najbliższy termin prac wypada za dwanaście dni, strona przez te dwanaście dni jest podatna i nic tego nie zmienia.
Odwrotna skrajność jest równie kosztowna. Wgranie każdej aktualizacji natychmiast po premierze kończy się czasem zepsutym formularzem w piątek po południu, czyli dokładnie wtedy, gdy nikogo nie ma przy komputerze.
Prawdziwa robota polega na rozróżnieniu: tę łatkę wdrażamy natychmiast, tę odkładamy do poniedziałku, a tej nie wdrażamy wcale, bo dotyczy funkcji, której ta strona nie używa. Tego nie da się zapisać w pakiecie ani w częstotliwości.
Dlatego pytanie do wykonawcy brzmi nie „jak często aktualizujecie?”, ale „kto u was decyduje o terminie i na jakiej podstawie?”.
Jak to wygląda w praktyce
| Sytuacja | Strona bez opieki | Strona pod stałym serwisem |
|---|---|---|
| Ujawniono poważną lukę | Infekcja w weekend, problem widoczny w poniedziałek | Łatka wdrożona tego samego dnia |
| Aktualizacja psuje formularz | Wykrywa to rodzina pacjenta albo nikt | Automatyczny test wykrywa i cofa zmianę |
| Kopia zapasowa | Na tym samym serwerze co strona | Na niezależnej infrastrukturze, z testem odtworzenia |
| Robot zgaduje hasła | Próbuje do skutku | Blokada po kilku próbach i logowanie dwuetapowe |
| Koszt | Nieregularne, drogie naprawy awaryjne | Stała, przewidywalna opłata |
O co zapytać wykonawcę, zanim podpiszesz umowę na serwis?
Sześć pytań, które w ciągu kilku minut pokazują, czy po drugiej stronie jest proces, czy deklaracja:
- Gdzie leży kopia zapasowa i kiedy ostatnio sprawdzaliście, że da się z niej odtworzyć stronę?
- Co się dzieje, kiedy aktualizacja zepsuje stronę i ile trwa powrót do poprzedniej wersji?
- Czy formularz jest testowany po każdej zmianie i cyklicznie w tle?
- W jakim czasie reagujecie na awarię zgłoszoną w sobotę?
- Kto ma dostęp do panelu i co dzieje się z kontem, gdy ktoś odchodzi z zespołu?
- Czy dostanę co miesiąc krótki raport z tego, co zostało zrobione?
Od czego zacząć w tym tygodniu
Cztery rzeczy do sprawdzenia, każda zajmuje kilkanaście minut. Czy kopia zapasowa leży poza serwerem strony i czy ktoś kiedykolwiek ją odtworzył. Czy wejście do panelu jest chronione logowaniem dwuetapowym. Kiedy wygasa certyfikat SSL i kto dostanie o tym przypomnienie. I najważniejsze: wyślij zgłoszenie przez własny formularz i sprawdź, czy doszło tam, gdzie powinno.
Jeżeli przy którymkolwiek punkcie nie znalazłaś albo nie znalazłeś odpowiedzi, to nie znaczy jeszcze, że coś jest nie tak. Znaczy, że nikt tego nie sprawdzał, a to w praktyce ta sama sytuacja.
Jeśli chcesz, żeby ktoś przeszedł przez te cztery punkty razem z Tobą i powiedział wprost, co wymaga reakcji, a co może poczekać: porozmawiajmy. Dwadzieścia minut przez telefon, bez zobowiązań.