Krytyczne luki w PHP (php2shell). Co powinna zrobić placówka medyczna

Stan na 22 października 2026. Będziemy aktualizować ten tekst, jeśli zmienią się zalecenia.

Co się stało

20 października do sieci wyciekły informacje o dwóch krytycznych podatnościach w PHP, zanim twórcy zdążyli opublikować poprawki. Dzień później, 21 października, ukazały się wersje naprawione. Luki oznaczono jako CVE-2026-109618 i CVE-2026-109619, obie z oceną 9,2 w dziesięciostopniowej skali CVSS. Pozwalają uruchomić kod na serwerze bez logowania i bez znajomości jakiegokolwiek hasła.

Wersje z poprawką to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. CERT Polska w komunikatach 195/2026 i 196/2026 podkreśla, że jedyną skuteczną ochroną jest instalacja poprawionej wersji, a zmiany ustawień w php.ini możliwości ataku nie wykluczają. Przed wydaniem poprawki zespół zalecał inwentaryzację wszystkich usług korzystających z PHP, a tam, gdzie nie zakłóci to pracy organizacji, tymczasowe wyłączenie tych dostępnych z internetu. W Polsce część stron BIP wyłączono wtedy prewencyjnie.

Dlaczego placówka medyczna jest w trudniejszej sytuacji niż przeciętna firma

Widzimy to na stronach, które prowadzimy. Próby przychodzą bez przerwy. Rzadko jest to coś celowanego, przeważnie stały szum automatycznych logowań i skanów szukających starych wersji. To tło, które dotyczy niemal każdej strony w internecie.

Różnica w ochronie zdrowia leży w tym, co jest za logowaniem. Rezerwacje wizyt, dane kontaktowe, formularze, w których ktoś opisał swoją dolegliwość, czasem załączniki i korespondencja z pacjentami. To dane dotyczące zdrowia, czyli szczególna kategoria danych osobowych w rozumieniu RODO. Stara wersja PHP jest tu więc czymś więcej niż długiem technicznym.

Skutki włamania nie kończą się na odtworzeniu strony z kopii zapasowej. Placówka musi dodatkowo odpowiedzieć na pytanie, czy ktoś miał dostęp do danych pacjentów, a od tej odpowiedzi zależą jej dalsze obowiązki.

Jak sprawdzić, na jakiej wersji PHP działa Wasza strona

Najprostsza droga prowadzi przez panel WordPressa.

1. Narzędzia
2. Stan witryny
3. Informacje
4. Serwer

Wersja PHP jest tam podana wprost. Jeśli strona nie działa na WordPressie, tę samą informację znajdziecie w panelu hostingu. Każdy dostawca nazywa to inaczej, zwykle jest to sekcja z ustawieniami PHP przy danej domenie.

Sam numer nie zawsze rozstrzyga sprawę. Dystrybucje Linuksa często wgrywają poprawki bez zmiany numeru wersji, więc PHP 8.2.21 u jednego dostawcy może być już załatane. Działa to też w drugą stronę. Właściwa wersja wgrana bez restartu usług PHP nadal nie chroni, bo serwer wciąż pracuje na starym kodzie. Numer z panelu jest więc punktem wyjścia do rozmowy z hostingiem.

Mail do hostingu

To konkretna rzecz, którą można zrobić dzisiaj. Wyślijcie pytanie na piśmie i zachowajcie odpowiedź.

Dzień dobry,

w związku z podatnościami CVE-2026-109618 i CVE-2026-109619 w PHP (php2shell) proszę o potwierdzenie:

1. Na jakiej wersji PHP działa obecnie strona [adres].
2. Czy poprawka została wgrana i czy usługi PHP zostały po niej zrestartowane.
3. Czy w logach z ostatnich dni widoczne są ślady nieautoryzowanego dostępu do naszego konta.

Prosimy o odpowiedź na piśmie, ponieważ przetwarzamy dane dotyczące zdrowia i dokumentujemy takie zdarzenia.

Pozdrawiam

Ostatnie zdanie w mailu ma znaczenie. Zwykle podnosi priorytet zgłoszenia u dostawcy, a Wam zostawia dokument z datą, do którego można wrócić.

Jeśli stronę trzymacie na własnym VPS albo serwerze dedykowanym, nie ma kogo pytać. Aktualizacja systemu, PHP i restart usług leżą wtedy po Waszej stronie albo po stronie osoby, która ten serwer utrzymuje.

Kiedy to przestaje być sprawą IT

Jeśli ktoś uruchomił kod na serwerze, na którym działa strona z systemem rezerwacji albo formularzami pacjentów, może to oznaczać naruszenie ochrony danych osobowych. RODO przewiduje wtedy zgłoszenie do Prezesa UODO w ciągu 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by naruszenie powodowało ryzyko dla osób, których dane dotyczą.

Trzy rzeczy w tym obowiązku zaskakują najczęściej.

1. Termin liczy się od stwierdzenia naruszenia. Jeśli ktoś wszedł na stronę w październiku, a placówka dowie się o tym w listopadzie, 72 godziny zaczynają biec w listopadzie.
2. Hosting ma obowiązek Was powiadomić. Dostawca, który przetwarza dane w Waszym imieniu, musi zgłosić Wam naruszenie bez zbędnej zwłoki. Dlatego jego odpowiedź warto mieć na piśmie i z datą.
3. Każde naruszenie trzeba udokumentować. Także takie, którego ostatecznie nie zgłosicie do UODO. Dokumentacja pokazuje, na jakiej podstawie podjęliście decyzję.

To, czy konkretne zdarzenie trzeba zgłosić, ocenia placówka jako administrator danych, najlepiej razem ze swoim inspektorem ochrony danych, jeśli go ma. Naszą rolą jest ustalić, co faktycznie stało się na stronie, bo bez tego nie ma czego oceniać.

Ten fragment opisuje ogólne zasady z art. 33 RODO i nie zastępuje porady prawnej.

Aktualizacja nie odpowiada na pytanie, czy ktoś już nie wszedł

O tej części mówi się najrzadziej i nie ma jej w komunikatach CERT-u. To nasza obserwacja z pracy przy stronach.

Aktualizacja zamyka drzwi. Nie wyprowadza nikogo, kto zdążył wejść wcześniej, a szczegóły luk krążyły w sieci przed wydaniem poprawki. Pierwsze próby ich wykorzystania odnotowano już 17 października, cztery dni przed publikacją poprawek. Jeśli w tym czasie ktoś założył sobie konto administratora albo zostawił plik w katalogu wtyczek, po aktualizacji nadal tam będzie.

Pierwsze sprawdzenie nie wymaga informatyki śledczej. Przejrzyjcie cztery rzeczy.

• Konta z rolą administratoraKażde konto powinno należeć do kogoś, kogo znacie.
• Daty modyfikacji plików motywu i wtyczekSzczególnie zmiany z ostatnich dni, których nikt nie planował.
• Wtyczki, których nikt świadomie nie instalowałTakże te wyłączone, bo plik na serwerze zostaje.
• Zaplanowane zadaniaNieznane zadania potrafią przywracać usunięte pliki.

Skan wtyczką bezpieczeństwa wyłapie typowe przypadki.

Jeśli nie macie kogo o to poprosić

Napiszcie do nas przez formularz. Bezpłatnie sprawdzimy, na jakiej wersji PHP faktycznie działa Wasza strona i co powinno się zadziać dalej.

Samo wykonanie wyceniamy po takim rozeznaniu, bo zakres zależy od tego, jak stara jest strona. Obejmuje ono

• pełną kopię zapasową przed jakąkolwiek zmianą,
• przegląd pod kątem śladów nieautoryzowanego dostępu,
• przełączenie na załataną wersję PHP tam, gdzie hosting na to pozwala,
• doprowadzenie motywu i wtyczek do stanu, w którym strona na niej poprawnie działa.

Na koniec dostajecie informację, co zostało zrobione i o co dopytać dostawcę hostingu. Samej poprawki PHP nie wgramy za hosting. To leży po stronie tego, kto prowadzi serwer.

Autor

Artur Łyczkowski

Współzałożyciel Rmedic

Odpowiada w Rmedic za kampanie w wyszukiwarce Google, SEO i pomiar. Na co dzień pracuje przy stronach placówek medycznych, także przy ich utrzymaniu i konfiguracji formularzy.