Krótko: Kto chce mieć lukę PHP2Shell w PHP zamkniętą jeszcze dziś, potrzebuje czterech rzeczy: właściwej aktualizacji, restartu wszystkich procesów PHP, sprawdzenia pod kątem już wprowadzonego złośliwego kodu oraz dowodu. Czy są Państwo dotknięci? Proszę zadzwonić. Pomożemy. Przejmujemy to zdalnie, od pierwszej wiadomości.
Teraz niczego nie usuwać i niczego nie instalować od nowa. Także przy wgrywaniu poprawek obowiązuje zasada: najpierw zabezpieczyć, potem zmieniać. Jeśli coś już się przedostało, potrzebujemy stanu plików i logów. Zgłoś awarię, ustalimy z Państwem kolejność.
Dlaczego luka nie może czekać
Obie luki, CVE-2026-109618 i CVE-2026-109619, tkwią w samym PHP i umożliwiają zdalne wykonanie złośliwego kodu bez logowania. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) ogłosiło poziom ostrzeżenia 3 (pomarańczowy) i zaleca natychmiastową aktualizację. Jeśli nie jest to możliwe od razu, serwery WWW mają zostać czasowo odłączone od sieci. Według doniesień medialnych pierwsze próby ataku zaobserwowano jeszcze przed opublikowaniem poprawek 21.10.2026. Cloudflare zaobserwował próby i wprowadził reguły ochronne, ale ostrzega, że reguły oparte wyłącznie na danych żądania nie wystarczają.
Ważne dla operatorów: aktualizacja CMS nie zamyka luki w PHP. Według doniesień także WordPress.org nie planuje aktualizacji w tej sprawie, ponieważ luka leży w interpreterze. Zamyka się ją wyłącznie na poziomie PHP, czyli w tym, co Państwa serwer faktycznie wykonuje.
Co należy zrobić teraz
- Poznać wersję docelową. Naprawione są PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. PHP 8.2 kończy wsparcie 31.12.2026, proszę to uwzględnić w planowaniu.
- Uwzględnić wszystkie systemy. Także serwery testowe, obrazy kontenerów i stare systemy dostępne z internetu.
- Wyjaśnić odpowiedzialność. W pakietach hostingowych i na serwerach zarządzanych aktualizację wgrywa dostawca. Proszę zapytać go pisemnie o wersję i restart.
- Zachować logi. Od 20.10.2026, jak podaje prasa branżowa.
- Uzgodnić okno czasowe. Restart na krótko przerywa trwające żądania. Proszę ustalić termin, w którym ktoś może podejmować decyzje.
- Nie czekać, jeśli system jest otwarty. Jeśli nie można od razu wgrać poprawki, proszę wspólnie z nami rozważyć odizolowanie systemu lub środki przejściowe.
Jak PHP SOS pomaga w praktyce?
- Ocena sytuacji: Spisujemy systemy, wersje PHP, tryby pracy, hostingodawców i dostępność oraz ustalamy kolejność: najpierw systemy najbardziej wystawione na ataki.
- Zabezpieczenie i zamknięcie: Zabezpieczamy stan bieżący, wgrywamy aktualizację lub doprowadzamy hosting do udokumentowanego, załatanego stanu i restartujemy wszystkie procesy. W przypadku kontenerów budujemy obraz od nowa i go wdrażamy.
- Sprawdzenie i oczyszczenie: Ponieważ poprawka nie usuwa złośliwego kodu, sprawdzamy, czy nie ma oznak wcześniejszego włamania, i w razie potrzeby oczyszczamy system.
- Wzmocnienie i raport: Otrzymują Państwo pisemny dowód dla każdego systemu oraz zalecenia, dzięki którym kolejna aktualizacja przebiegnie szybciej. Zakres usługi opisuje usługa poprawek PHP (PHP-Patch-Service).
Aktualizacja, restart, dowód: na co zwrócić uwagę
Najczęstszym błędem jest aktualizacja bez restartu. Dopóki w pamięci działają stare procesy, podatny kod pozostaje aktywny, nawet jeśli pliki są nowe. Instrukcja znajduje się na stronie Restart PHP-FPM i wszystkich procesów roboczych. Drugim błędem jest wiara w wyświetlany numer: dystrybucje i hostingodawcy często dostarczają backporty, wtedy numer wersji pozostaje taki sam. Wiarygodny jest changelog pakietu z numerami CVE, w rodzinie Debiana poleceniem apt-get changelog <paket>.
Ponadto według podręcznika PHP od wydań bezpieczeństwa obowiązuje nowa dyrektywa memory_hard_limit_percent. Jeśli wersja PHP jej nie zna, jest dotknięta luką. Test jest krótki:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Trzeba go wykonać dla każdej wersji i trybu pracy, ponieważ wiersz poleceń może używać innej wersji PHP niż serwer WWW. Na koniec utrwalamy wynik, aby mogli Państwo pokazać go hostingodawcy, ubezpieczycielowi lub zleceniodawcy.
Gdy aktualizacja nie jest możliwa od razu
Są powody, dla których aktualizacja nie jest możliwa dzisiaj: stara aplikacja, która nie działa na nowszych wersjach PHP, hostingodawca bez zgody, obraz kontenera w sztywnym potoku wdrożeniowym. W takich przypadkach php.net podaje środki przejściowe, które wyraźnie nie stanowią pełnej ochrony: ustawić memory_limit=-1 tak, aby aplikacje nie mogły go nadpisać, ograniczyć post_max_size, session.upload_progress.enabled=0 oraz w PHP 8.5 fatal_error_backtraces=0, każdorazowo z restartem. Dochodzą do tego reguły ochronne na brzegu sieci, które nie zastępują aktualizacji. Krążącą radę, aby blokować wszystkie żądania z PHPSESSID, autorzy branżowi wyraźnie odrzucają.
Jakie środki pasują do Państwa systemu i co mogą zepsuć, omawiamy wcześniej. Więcej na stronie Środki doraźne, gdy nie można jeszcze wgrać poprawki oraz w temacie WAF i wirtualne łatanie. Dla PHP 8.1 i starszych obowiązuje odrębna sytuacja, opisana w artykule PHP 8.1 i starsze: co teraz obowiązuje.
Co warto nam przesłać
- Listę serwerów i hostingodawców, o ile jest dostępna
- Wynik
php -vdla każdego systemu oraz informację o trybie pracy - Informację, czy używane są kontenery, Plesk, cPanel lub oferta zarządzana
- Pożądane okno czasowe i osobę kontaktową do restartów
- Wskazówki dotyczące nieprawidłowości od 17.10.2026
Dlaczego PHP SOS
Pracujemy w standardzie Made in Germany i od ponad 25 lat specjalizujemy się w bezpieczeństwie IT wraz z naszą siecią partnerów złożoną z ekspertów od cyberbezpieczeństwa. Mają Państwo jedną osobę kontaktową, która towarzyszy aktualizacji, sprawdza restart i dostarcza dowód. Pracujemy zdalnie, bez dojazdu, i dokumentujemy każdy krok. Nie obiecujemy cudów: poprawka zamyka lukę, ale nie dowodzi, że wcześniej nic się nie stało, i właśnie tak to Państwu powiemy.
Czy są Państwo dotknięci? Proszę zadzwonić. Pomożemy.
Proszę nie zostawiać luki dłużej otwartej. Proszę zadzwonić lub napisać na WhatsApp. Przejmujemy sprawę od pierwszej wiadomości i zostajemy przy niej, aż incydent zostanie zakończony i udokumentowany. Zgłoś awarię teraz.
Częste pytania
Czy mogę sam zamknąć lukę w PHP, czy potrzebuję pomocy?
Aktualizacja jest wykonalna dla administratorów, ale podatna na błędy: musi obowiązywać wersja, która faktycznie obsługuje stronę, a wszystkie procesy muszą się zrestartować. Kto ma kilka serwerów, obrazy kontenerów lub hostingodawcę ze swoimi osobliwościami, dzięki wsparciu oszczędza czas i błędy.
Czy po aktualizacji trzeba zrestartować PHP?
Tak. Same nowe pliki nie wystarczą, dopóki w pamięci działają stare procesy PHP. Wszystkie procesy robocze muszą zostać zrestartowane, a przy mod_php serwer WWW.
Co zrobić, gdy dla mojej wersji PHP nie ma jeszcze aktualizacji?
Dla PHP 8.1 i starszych projekt PHP nie dostarcza już oficjalnych aktualizacji. Potrzebny jest wtedy udokumentowany, załatany backport dostawcy, migracja na wersję objętą wsparciem lub środki przejściowe, które jednak nie dają pełnej ochrony.
Czy wystarczy ustawić session.upload_progress.enabled na 0?
Nie. Według raportów branżowych samo to ustawienie nie zamyka obu luk, aktualizacja PHP pozostaje obowiązkowa. Proszę ustawiać je wyłącznie w php.ini, puli FPM lub konfiguracji serwera, a nie przez ini_set() ani .user.ini.
Skąd wiem, że luka jest potem naprawdę zamknięta?
Dzięki dowodowi na działającym systemie: wersja lub changelog pakietu, test na nową dyrektywę memory_hard_limit_percent oraz potwierdzenie, że po aktualizacji zrestartowano wszystkie procesy.