PHP2Shell i rekomendacja Pełnomocnika nr 2026/33/6. Co zrobić w podmiocie, kiedy urzędy w Europie wyłączają strony?
Pełnomocnik Rządu zaleca natychmiastową aktualizację PHP i tymczasowe ustawienia php.ini. Co wynika z trybu art. 33 ustawy o KSC i czego uczą próby ataków.
- Autor
- Paweł Rosół
- Data
- Czytanie
- 9 min
- Kategoria
- Ustawa o KSC
Stan prawny sprawdzony:
Spis treści
22 października 2026 r. Pełnomocnik Rządu do Spraw Cyberbezpieczeństwa wydał rekomendację nr
2026/33/6 w sprawie dwóch podatnościPodatność Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV. w PHP, CVE-2026-109618 i CVE-2026-109619, nazywanych
PHP2Shell. Podmiotom krajowego systemu cyberbezpieczeństwa zaleca trzy rzeczy: natychmiastową
aktualizację do wersji z poprawką, czekanie na nowe wersje urządzeń i obrazów od producentów
oraz tymczasowe ustawienia php.ini. To rekomendacja z art. 33 ustawy o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych., nie z art. 67a,
więc jej nieuwzględnienie ma skutki, o których piszę niżej.
Sam przebieg wydania poprawek, wersje i polecenia do sprawdzenia serwera opisałem w aktualności o PHP. Tutaj zajmuję się trzema pytaniami, które słyszę od zarządów od środy: co dokładnie zaleca polski dokument, co zrobiły w tym czasie agencje w innych krajach i czy ktoś już te podatności wykorzystał.
Co dokładnie zaleca rekomendacja nr 2026/33/6?
Dokument ma trzy punkty. Pkt 1 to „natychmiastowe wdrożenie poprawki eliminującej powyższe podatności we wszystkich usługach wykorzystujących PHP” w wersjach 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Pkt 2 dotyczy gotowych urządzeń, appliance i aplikacji dystrybuowanych jako obrazy, na przykład Docker: na nowe wersje trzeba poczekać u producenta i wdrożyć je niezwłocznie po udostępnieniu.
Pkt 3 podaje ustawienia na czas do wdrożenia poprawki:
memory_limitna -1, jeżeli pozwalają na to zasoby, a w przeciwnym wypadku 128M lub więcej;post_max_size8M lub mniej (w PDF stoi literówka „ppost_max_size”);max_input_vars1000 lub mniej;session.upload_progress.enabledna Off.
Komunikat zespołu PHP na php.net wymienia podobny zestaw, ale różni się w szczegółach. Przy
memory_limit podaje tylko -1, a post_max_size 8M zaleca dla aplikacji bez przesyłania
plików i 32M dla tych, które pliki przyjmują. Ma też dwa zastrzeżenia, których rekomendacja nie
powtarza. Ustawienie
session.upload_progress.enabled ma działać przed parsowaniem żądania, więc ustawia się je w
php.ini, w puli FPM albo w konfiguracji serwera, nie przez ini_set() ani .user.ini, a po
zmianie trzeba zrestartować każdy proces roboczy. Zespół PHP pisze też wprost, że te środki
ograniczają tylko konkretne ścieżki ataku, nie czynią instalacji bezpieczną, a pełnym
rozwiązaniem jest wyłącznie aktualizacja.
Ustawienia z pkt 3 kupują czas do aktualizacji, a nie zastępują jej, i rekomendacja sama tak je opisuje.
Ministerstwo Cyfryzacji w komunikacie z tego samego dnia dodaje dwie informacje, których w rekomendacji nie ma. Podatne mają być wszystkie wersje PHP od 5.4, a wraz z nimi WordPress, Joomla czy WooCommerce, i jedyną skuteczną ochroną jest instalacja poprawionej wersji. Centralny Ośrodek Informatyki czasowo wyłączył strony BIP działające w Systemie Scentralizowanego Dostępu do Informacji Publicznej (SSDIP). Ślady wykorzystania podatności ministerstwo prosi zgłaszać do CERT PolskaCERT Polska Zespół reagowania na incydenty prowadzony przez NASK, źródło ostrzeżeń i analiz, które cytuję w aktualnościach. Ustawa tej nazwy nie zna; ustawowym zespołem jest CSIRT NASK. przez formularz na incydent.cert.pl.
Dlaczego tryb z art. 33 ma znaczenie dla podmiotu?
Rekomendacja nie wskazuje swojej podstawy wprost, ale numer 2026/33/6, odesłanie do art. 33 ust. 5 i opis konsultacji odpowiadają trybowi art. 33 ust. 4a ustawy o KSC. Pełnomocnik może w nim wydać rekomendację z urzędu, gdy informacja o cyberzagrożeniu uprawdopodobni możliwość wystąpienia incydentu krytycznegoIncydent krytyczny Incydent o znacznych skutkach dla bezpieczeństwa publicznego, gospodarki, instytucji publicznych albo życia i zdrowia ludzi. Klasyfikuje go właściwy CSIRT krajowy., a wcześniej konsultuje się z CSIRT MONCSIRT Zespół reagowania na incydenty bezpieczeństwa komputerowego. Na poziomie krajowym działają trzy: CSIRT GOV (Szef ABW), CSIRT MON (Minister Obrony Narodowej) i CSIRT NASK (NASK-PIB)., CSIRT NASK lub CSIRT GOV (art. 33 ust. 4b). Dokument podaje, że konsultował się ze wszystkimi trzema i że potwierdziły one możliwość wystąpienia incydentu krytycznego, a stosowanie oprogramowania z tymi podatnościami uznaje za mające negatywny wpływ na bezpieczeństwo publiczne i istotny interes bezpieczeństwa państwa.
Ustawa nie nazywa takiej rekomendacji dobrowolną, inaczej niż przy rekomendacjach z art. 67a (art. 67a ust. 5). Podmiot może w ciągu 14 dni od publikacji na stronie podmiotowej BIP Pełnomocnika wnieść zastrzeżenia z uwagi na negatywny wpływ na świadczoną usługę lub zadanie publiczne (art. 33 ust. 5). Na wniosek Pełnomocnika informuje go o sposobie i zakresie uwzględnienia rekomendacji (art. 33 ust. 7), a jej nieuwzględnienie jest podstawą do wystąpienia Pełnomocnika do organu, który nad podmiotem sprawuje nadzór (art. 33 ust. 8).
Z tego wynika praktyczna rada: zapisać, co i kiedy zrobiono. Jeśli Pełnomocnik zapyta, odpowiedź „zaktualizowaliśmy” bez listy serwerów, wersji i dat jest słabsza niż krótka tabela z działu IT. Podmiot ważnyPodmiot ważny Podmiot z sektorów ustawy o KSC, który spełnia jej kryteria, ale nie jest podmiotem kluczowym. Wdraża SZBI i zgłasza incydenty poważne tak jak podmiot kluczowy. będący podmiotem publicznymPodmiot publiczny Podmiot z sektora „podmioty publiczne” w załączniku nr 1 lub 2 do ustawy o KSC. Podmiot publiczny, który jest podmiotem ważnym, wdraża SZBI według załącznika nr 4 do ustawy. ma do tego obowiązek przeglądu SZBISystem zarządzania bezpieczeństwem informacji Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów. bezzwłocznie po wydaniu rekomendacji w zakresie, w jakim dotyczy ona jego systemów (załącznik nr 4 do ustawy o KSC, część III pkt 2).
Ten sam tryb Pełnomocnik zastosował wcześniej przy WordPressie (nr 2026/33/4) i MikroTiku (nr 2026/33/5). Pełną listę ostatnich rekomendacji zebrałem w omówieniu rekomendacji nr 2026-67a-9.
Jak zareagowały agencje i instytucje w innych krajach?
Niemiecki BSI opublikował 21 października ostrzeżenie z poziomem krytyczności 3, pomarańczowym, co w jego skali oznacza, że działania trzeba podjąć niezwłocznie, a regularna praca może być poważnie zakłócona. Według BR24 urząd zalecał operatorom, którzy nie mogą zapewnić ludzi do natychmiastowej instalacji poprawek, wyłączenie serwisów. W aktualizacji ostrzeżenia BSI pisze, że pełną ochronę daje według obecnej wiedzy tylko aktualizacja albo odłączenie od internetu.
Amerykańska CISA zaleciła tego samego dnia wyłączenie systemów opartych na PHP, których nie da się od razu zaktualizować albo które działają na PHP 8.1 lub starszym, do czasu aktualizacji. Brytyjskie NCSC radzi najpierw znaleźć wszystkie instalacje PHP, zaczynając od widocznych z internetu, i nie ograniczać poszukiwań do starych wersji. Kto nie może ani zaktualizować, ani zastosować środków tymczasowych, powinien rozważyć wyłączenie systemu i sprawdzić go pod kątem śladów włamania i pozostawionych tylnych furtek.
Wiele instytucji tak zrobiło. W Bawarii przez kilka godzin nie działały strony policji, ministerstw, sądów, prokuratur, części uniwersytetów i szpitali oraz Monachium (BR24). W Dolnej Saksonii wszystkie strony kraju związkowego przeszły w tryb serwisowy, a w Meklemburgii-Pomorzu Przednim portal rządowy odizolowano od internetu (NDR). heise, za dpa i Reuters, wymienia też Charité, część berlin.de, rządowe strony w Danii, Finlandii, Francji i Holandii i pisze, że w takiej skali nie zdarzyło się to nigdy wcześniej. Według Patchstack, który powołuje się na NOS, w Holandii wyłączono między innymi DigiD, MijnOverheid, stronę parlamentu i stronę tamtejszego NCSC, a The Record wspomina o Nintendo.
Agencje w Niemczech, Stanach Zjednoczonych i Wielkiej Brytanii wprost wskazały wyłączenie serwisu jako dopuszczalną odpowiedź, a polska rekomendacja tej opcji nie wymienia.
Rekomendacja nr 2026/33/6 nie mówi o wyłączaniu serwisów, ale COI zrobił dokładnie to z BIP w SSDIP. Dla kierownika podmiotu to ważna wskazówka: decyzja o zdjęciu strony na kilka godzin, dopóki nie ma poprawki albo ludzi do jej instalacji, mieści się w tym, co w tym tygodniu robiły urzędy w całej Europie. Lepiej podjąć ją świadomie i zapisać, niż wyłączać stronę dopiero po incydencie.
Czy ktoś już wykorzystał PHP2Shell?
Próby są udokumentowane, skuteczne włamania na razie nie. Amazon Threat Intelligence opisał próbę wykorzystania w swojej sieci pułapek MadPot z 17 października, cztery dni przed ujawnieniem, z adresu komercyjnej sieci anonimizującej, i przyznał, że nie wie, skąd atakujący miał informacje. 21 października między 2:00 a 8:00 UTC przyszły kolejne próby, z różnymi ładunkami, co według Amazona wskazuje na kilku sprawców. Nie wiadomo, czy któraś udałaby się na prawdziwym serwerze. heise dodaje, że według Amazona pierwsza próba mogła dotyczyć innej podatności w przesyłaniu plików; w wersji wpisu, którą czytałem, tego zastrzeżenia nie ma.
Skalę podał Cloudflare. Jego prezes Matthew Prince, cytowany przez SecurityWeek, mówił o tysiącach prób w dziesięciu godzinach przed ogłoszeniem, dziesiątkach tysięcy w 45 minut po nim, setkach tysięcy po dwóch godzinach i milionach w czwartek rano. Patchstack zanotował 21 października rano zgłoszenia od firm hostingowych o aktywnych próbach wykorzystania, ale tuż po wydaniu poprawek jego telemetria pokazywała tylko sondowanie.
Najbardziej konkretny przykład opisał VulnCheck. Jego pułapki zarejestrowały skaner z nagłówkiem
User-Agent php2shell-scan/109618, który wysyłał żądania multipart POST do index.php, a 21
października o 17:22 UTC próbę z chińskiego adresu: atakujący przez
PHP_SESSION_UPLOAD_PROGRESS umieszczał w pliku sesji prosty web shell i próbował go odczytać
przez php://filter. Ścieżka nie istniała, serwer odpowiedział błędem 404 i atak się nie udał.
Przy tej podatności liczba prób rosła szybciej, niż ktokolwiek zdążył potwierdzić choćby jedno skuteczne włamanie.
Na GitHubie pojawiły się setki exploitów pokazowych. VulnCheck pisze, że prawdziwych jest wśród nich bardzo mało i żaden publiczny nie omija ASLR na x86-64, a wykonanie kodu jest łatwiejsze na ARM64 i na systemach z wyłączonym ASLR. Ta sama firma ma własny exploit, który według niej działa na PHP 8.4.26 z włączonym ASLR. Według watchTowr rozsyłane masowo exploity nie działają, sprawdzają różnice czasu odpowiedzi albo wywracają serwer, a JFrog, cytowany przez SecurityWeek, znalazł fałszywe exploity i złośliwe żarty. Pobieranie takiego kodu po to, żeby sprawdzić własny serwer, to osobne ryzyko.
Jak duże jest pole ataku, pokazują liczby z SecurityWeek. VulnCheck widzi PHP na ponad 2,6 mln hostów dostępnych z internetu, prawie wszystkie podatne, w tym co najmniej milion na wersjach bez wsparcia. Censys 21 października naliczył około 1,57 mln niezałatanych spośród 1,58 mln hostów, które ujawniają wersję. Sansec podaje, że Calif, jedna z firm zgłaszających podatności, pokazał wykonanie kodu bez logowania na Magento, WordPressie, Drupalu, Joomli, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravelu, Symfony i WHMCS.
Potwierdzonych skutecznych ataków nie zgłosiły do 22 października ani CISA, która w dniu publikacji nie obserwowała wykorzystania, ani BSI, który według NDR nie stwierdził żadnego przypadku.
Co robię w podmiocie w tym tygodniu?
Kolejność biorę z rekomendacji i z zaleceń agencji, które czytałem:
- Spis wszystkich instalacji PHP, nie tylko strony internetowej. PHP bywa w panelach hostingowych, BIP, poczcie przez przeglądarkę (Roundcube) i zaporach sieciowych; BSI wymienia pfSense i OPNsense. CISA i NCSC zwracają uwagę, że w cudzym produkcie PHP bywa niewidoczny.
- Wersja z dziennika zmian pakietu, nie z
php -v, bo dystrybucje przenoszą poprawkę do pakietu ze starszym numerem. Polecenia podałem w aktualności o PHP. Po aktualizacji restart PHP-FPM albo Apache. - Obrazy kontenerów przebudowane z nową wersją PHP. Sama aktualizacja hosta niczego w nich nie zmienia, na co zwraca uwagę BSI.
- Urządzenia i appliance: zapytanie do producenta o datę wersji z poprawką i wpis do rejestru ryzyka do czasu jej wdrożenia, zgodnie z pkt 2 rekomendacji.
- Przegląd logów od 17 października, bo tak radzi Amazon, a nie od dnia ujawnienia. Szukam
żądań POST z
PHP_SESSION_UPLOAD_PROGRESS, plików sesji z kodem PHP i procesów PHP, które uruchamiają powłokę albo pobierają narzędzia, o czym pisze CISA. - PHP 8.1 i starsze bez poprawki od projektu PHP: backport od dystrybucji albo dostawcy wsparcia, a jeśli go nie ma, wyłączenie do czasu migracji, jak zaleca CISA.
- Zapis: lista systemów, wersje, daty, kto zdecydował o ewentualnym wyłączeniu. Ten sam zapis posłuży jako odpowiedź na pytanie z art. 33 ust. 7 i jako dowód przeglądu SZBI.
Jeśli w logach jest ślad udanego ataku, uruchamiam procedurę obsługi incydentów. Kto decyduje, czy incydent jest poważny, i jak zdążyć ze zgłoszeniem, opisałem w tekście o incydencie poważnym, a ministerstwo prosi dodatkowo o kontakt z CERT Polska przez incydent.cert.pl.
Zespół PHP zastrzega, że środki tymczasowe ograniczają tylko znane ścieżki ataku, a Wiz, cytowany przez Patchstack, pokazał na podatnym PHP odczyt pamięci procesu roboczego bez wykonania kodu. W tej pamięci mogą być hasła, tokeny i klucze API, dlatego po aktualizacji zmieniam też dane uwierzytelniające aplikacji, które były wystawione do internetu przed 21 października.
Pojęcia w tym tekście (12)
- Podatność
- Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV.
- Ustawa o KSC
- Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.
- CERT Polska
- Zespół reagowania na incydenty prowadzony przez NASK, źródło ostrzeżeń i analiz, które cytuję w aktualnościach. Ustawa tej nazwy nie zna; ustawowym zespołem jest CSIRT NASK.
- Incydent
- Zdarzenie, które szkodzi albo może zaszkodzić bezpieczeństwu systemów informacyjnych. Zgłaszać trzeba nie każdy incydent, tylko incydent poważny.
- Incydent krytyczny
- Incydent o znacznych skutkach dla bezpieczeństwa publicznego, gospodarki, instytucji publicznych albo życia i zdrowia ludzi. Klasyfikuje go właściwy CSIRT krajowy.
- CSIRT
- Zespół reagowania na incydenty bezpieczeństwa komputerowego. Na poziomie krajowym działają trzy: CSIRT GOV (Szef ABW), CSIRT MON (Minister Obrony Narodowej) i CSIRT NASK (NASK-PIB).
- Podmiot ważny
- Podmiot z sektorów ustawy o KSC, który spełnia jej kryteria, ale nie jest podmiotem kluczowym. Wdraża SZBI i zgłasza incydenty poważne tak jak podmiot kluczowy.
- Podmiot publiczny
- Podmiot z sektora „podmioty publiczne” w załączniku nr 1 lub 2 do ustawy o KSC. Podmiot publiczny, który jest podmiotem ważnym, wdraża SZBI według załącznika nr 4 do ustawy.
- System zarządzania bezpieczeństwem informacji
- Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów.
- CISA
- Cybersecurity and Infrastructure Security Agency, amerykańska agencja ds. cyberbezpieczeństwa i infrastruktury. Prowadzi katalog KEV; nie jest organem w rozumieniu ustawy o KSC.
- Kierownik podmiotu
- Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie.
- Losowe rozmieszczenie przestrzeni adresowej
- Address space layout randomization: zabezpieczenie systemu operacyjnego, które losowo rozmieszcza w pamięci kluczowe obszary procesu, przez co błąd pamięci trudniej zamienić w działający exploit.
Najczęściej zadawane pytania
Czy rekomendacja nr 2026/33/6 w sprawie PHP jest obowiązkowa?
Odpowiada trybowi art. 33 ust. 4a ustawy o KSC, a przy rekomendacjach z art. 33 ustawa nie ma zdania o dobrowolności, które art. 67a ust. 5 zawiera dla rekomendacji z art. 67a. Podmiot krajowego systemu cyberbezpieczeństwa może wnieść zastrzeżenia w ciągu 14 dni od publikacji rekomendacji na stronie podmiotowej BIP Pełnomocnika (art. 33 ust. 5), na wniosek Pełnomocnika informuje go o sposobie i zakresie jej uwzględnienia (art. 33 ust. 7), a nieuwzględnienie rekomendacji jest podstawą do wystąpienia Pełnomocnika do organu sprawującego nadzór nad podmiotem (art. 33 ust. 8).
Czy ustawienia php.ini z pkt 3 rekomendacji zastępują aktualizację PHP?
Nie. Pkt 3 rekomendacji wprowadza je wyłącznie „do czasu wdrożenia poprawki”, a pkt 1 zaleca natychmiastowe wdrożenie wersji PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. Komunikat zespołu PHP, wpis Amazona i ostrzeżenie BSI mówią to samo z drugiej strony - pełną ochronę daje dopiero aktualizacja albo odłączenie serwera od internetu.
Co rekomendacja zmienia w podmiocie ważnym, który jest podmiotem publicznym?
Taki podmiot dokonuje przeglądu systemu zarządzania bezpieczeństwem informacji bezzwłocznie w przypadku wydania przez Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa rekomendacji, w zakresie, w jakim dotyczy ona jego systemów informacyjnych, produktów ICT lub usług ICT (załącznik nr 4 do ustawy o KSC, część III pkt 2). Jeśli urząd ma stronę, BIP albo system dziedzinowy na PHP, rekomendacja go dotyczy i przegląd trzeba przeprowadzić oraz udokumentować.
Źródła
- Pełnomocnik Rządu do Spraw Cyberbezpieczeństwa, Rekomendacja nr 2026/33/6 z dnia 22 października 2026 r. dotycząca podatności w oprogramowaniu PHP (PDF)
- Ministerstwo Cyfryzacji, Ważny komunikat - luki w oprogramowaniu PHP (22 października 2026 r.)
- Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, tekst jednolity Dz.U. 2026 poz. 20, ze zmianami
- php.net, Security advisory. Critical remote code execution vulnerabilities, update now (21 października 2026 r.)
- The PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security (21 października 2026 r.)
- BSI, PHP. Kritische Schwachstellen bedrohen Webanwendungen weltweit, BITS-H 2026-297981-1132, wersja 1.1 (21 października 2026 r., PDF)
- CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21 października 2026 r.)
- NCSC (Wielka Brytania), Critical security issue affecting PHP
- Amazon Threat Intelligence, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot (21 października 2026 r.)
- VulnCheck, PHP2Shell Vulnerabilities. CVE-2026-109618 and CVE-2026-109619
- SecurityWeek, Ionut Arghire, PHP2Shell Exploitation Started Days Before Patches (22 października 2026 r.)
- Patchstack, Major security alert. PHP vulnerable to critical RCE, attacks ongoing (21 października 2026 r.)
- Sansec, PHP2Shell. Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) (21 października 2026 r.)
- heise online, Dirk Knop, php2shell. Updates roll out as websites go offline and attacks begin (22 października 2026 r.)
- BR24, PHP-Sicherheitslücke. Bayerische Behörden sind weg vom Netz (21 października 2026 r.)
- NDR, Sicherheitslücke. Erste Behörden im Norden sind wieder online (22 października 2026 r.)
- The Record, Jonathan Greig, Hundreds of websites taken offline as concern grows over two PHP vulnerabilities (21 października 2026 r.)