Dwie krytyczne podatności w samym silniku PHP pozwalają na zdalne przejęcie serwera bez logowania i są już wykorzystywane w atakach. Sprawdź wersje, zaktualizuj i zweryfikuj, czy nie doszło do włamania.
W skrócie
- Co: dwie krytyczne podatności w silniku PHP (nazwane „PHP2Shell”) umożliwiające zdalne wykonanie kodu bez uwierzytelnienia. Ocena CVSS v4.0: 9.2 dla każdej.
- Kogo dotyczy: praktycznie każdej instalacji PHP obsługującej ruch WWW — PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP, LiteSpeed. Najwyższe ryzyko: mod_php.
- Poprawki: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 (wydane 21 października 2026 r.).
- Status: podatności są aktywnie wykorzystywane — 26 października 2026 r. trafiły do katalogu CISA KEV.
- Co zrobić: zaktualizować PHP natychmiast, zrestartować wszystkie procesy PHP i sprawdzić, czy serwer nie został już przejęty.
Co się stało
21 października 2026 r. projekt PHP wydał nadzwyczajne aktualizacje bezpieczeństwa dla wszystkich wspieranych gałęzi. Naprawiają one dwie podatności w samym silniku języka — nie w aplikacjach, frameworkach czy wtyczkach:
- CVE-2026-109618 — uszkodzenie pamięci przy obsłudze jej braku (out of memory). Gdy PHP przerywa żądanie w trakcie inicjalizacji, procedura sprzątania może potraktować częściowo przygotowane dane jak poprawne.
- CVE-2026-109619 — „nieaktualny stan globalny”. Wewnętrzny stan żądania może przetrwać zwolnienie pamięci i zostać użyty przez kolejne żądanie obsługiwane przez ten sam proces.
W obu przypadkach skutkiem może być zdalne wykonanie kodu z uprawnieniami serwera WWW, bez logowania do aplikacji. Według opisów badaczy podatna może być nawet najprostsza aplikacja — błąd leży w silniku, a nie w kodzie strony.
Sytuację pogorszył przeciek: szczegóły podatności pojawiły się w mediach społecznościowych dzień przed planowaną publikacją. Atakujący dostali więc informacje mniej więcej w tym samym czasie co administratorzy.
Czy Twoje systemy są podatne
| Gałąź PHP | Podatne wersje | Wersja z poprawką |
|---|---|---|
| 8.5 | niższe niż 8.5.12 | 8.5.12 |
| 8.4 | niższe niż 8.4.27 | 8.4.27 |
| 8.3 | niższe niż 8.3.36 | 8.3.36 |
| 8.2 | niższe niż 8.2.35 | 8.2.35 |
| 8.1, 8.0, 7.4 i starsze | wszystkie | brak oficjalnych wydań — tylko backporty źródłowe lub pakiety dystrybucji |
Trzy ważne uwagi:
- Numer wersji to nie wszystko. Dystrybucje Linuksa i dostawcy wsparcia LTS otrzymali poprawki wcześniej i często wprowadzają je bez zmiany głównego numeru wersji. Sprawdzaj, czy zainstalowany jest pakiet z poprawką od dostawcy, a nie tylko
php -v. - Starsze gałęzie. Dla PHP 7.4, 8.0 i 8.1 projekt PHP udostępnił jedynie minimalne poprawki w kodzie źródłowym. Jeśli w firmie działa coś na tak starej wersji, to sygnał, że migracja nie może dłużej czekać.
- PHP 8.2 kończy wsparcie 31 grudnia 2026 r. Systemy na tej gałęzi warto od razu wpisać do planu migracji.
Jak poważne jest zagrożenie
- watchTowr obserwuje próby wykorzystania w swoich pułapkach (honeypotach) od 21 października.
- CISA 26 października dodała obie podatności do katalogu znanych, wykorzystywanych podatności (KEV) i nakazała amerykańskim agencjom federalnym nie tylko łatanie, ale też analizę powłamaniową.
- Rapid7 odnotowuje wiele prób ataków. Publicznie dostępne exploity działają na razie tylko w konkretnych konfiguracjach, ale badacze spodziewają się wkrótce bardziej uniwersalnych.
- W Polsce Centralny Ośrodek Informatyki 22 października czasowo wyłączył strony Biuletynu Informacji Publicznej działające w systemie SSDIP.
To nie jest więc podatność „teoretyczna”. Każdy serwer z PHP wystawiony do internetu należy traktować jako zagrożony, dopóki nie zostanie zaktualizowany i sprawdzony.
Co zrobić — plan na dziś
- Zinwentaryzuj PHP w firmie. Nie tylko główną stronę: również WordPressa działu marketingu, intranet, panele administracyjne, sklepy, systemy B2B, środowiska testowe, kontenery i obrazy Dockera, hosting współdzielony oraz urządzenia i oprogramowanie dostawców, które mają PHP „w środku”. Zacznij od systemów dostępnych z internetu.
- Zaktualizuj PHP do wersji z poprawką albo zainstaluj pakiet z poprawką od dostawcy systemu.
- Zrestartuj wszystkie procesy PHP (pule PHP-FPM, Apache z mod_php). Sama instalacja pakietu nie wystarczy, jeśli stare procesy dalej działają.
- Przebuduj obrazy kontenerów na zaktualizowanym obrazie bazowym i wdroż je ponownie.
- Zweryfikuj po aktualizacji, że na każdym serwerze działa poprawiona wersja.
- Zapytaj dostawców — firmę hostingową, producentów systemów i software house’y — o potwierdzenie na piśmie, że ich środowiska są zaktualizowane.
Jeśli nie możesz zaktualizować od razu
Projekt PHP opisał środki ograniczające ryzyko. Podkreśla jednak wyraźnie, że nie czynią one instalacji bezpieczną — to tylko zmniejszenie ekspozycji do czasu aktualizacji:
- ustaw
session.upload_progress.enabled=0wphp.ini, konfiguracji puli FPM lub serwera, - ustaw
memory_limit=-1administracyjnie (np. przezphp_admin_value) i ograniczpost_max_size(8M bez uploadów, 32M z uploadami), - w PHP 8.5 ustaw dodatkowo
fatal_error_backtraces=0, - ogranicz rozmiar i złożoność żądań na serwerze WWW lub proxy; jeśli aplikacja nie przyjmuje formularzy multipart, blokuj je przed PHP,
- po każdej zmianie zrestartuj wszystkie procesy PHP.
Ustawienia przez ini_set() w kodzie lub plik .user.ini działają za późno i nie chronią. Ukrywanie błędów (display_errors, @) też nie pomaga. Najbezpieczniejszą opcją tymczasową jest ograniczenie dostępu z internetu do systemu, którego nie da się zaktualizować.
Sprawdź, czy nie doszło do włamania
Skoro ataki trwają od dnia publikacji, sama aktualizacja może nie wystarczyć. Na serwerach wystawionych do internetu warto sprawdzić:
- nowe lub zmienione pliki PHP w katalogach aplikacji, uploadów i plików tymczasowych (typowe miejsce dla „webshelli”),
- nietypowe procesy uruchamiane przez użytkownika serwera WWW,
- nieoczekiwane połączenia wychodzące z serwera,
- zmiany w zadaniach cron, kontach użytkowników i kluczach SSH,
- błędy krytyczne PHP i nietypowe żądania w logach z okresu od 20 października.
Brak śladów w logach nie dowodzi, że do włamania nie doszło. Jeśli masz wątpliwości, potraktuj serwer jak przejęty: odtwórz go z czystego obrazu, zmień hasła i klucze używane przez aplikację.
Lekcja dla zarządu
Takie sytuacje bezlitośnie weryfikują trzy rzeczy:
- Czy wiemy, co mamy. Bez aktualnej inwentaryzacji systemów nie da się sprawnie zareagować w ciągu godzin.
- Jak szybko łatamy. Firma powinna mieć zdefiniowany czas reakcji na krytyczne podatności — liczony w godzinach lub dniach, nie tygodniach.
- Czy nie trzymamy przestarzałego oprogramowania. Systemy na niewspieranych wersjach PHP to ryzyko, które przy takiej podatności staje się realnym problemem.
Dla firm objętych nową ustawą o krajowym systemie cyberbezpieczeństwa dochodzi kwestia zgłaszania incydentów: wczesne ostrzeżenie o incydencie poważnym trzeba przekazać w ciągu 24 godzin. Więcej o obowiązkach piszę w artykule NIS2 w średniej firmie: od czego zacząć.
Źródła
- PHP — ogłoszenie wydań bezpieczeństwa z 21.10.2026 (php.net)
- PHP Foundation — Today’s PHP security release and how we’re strengthening PHP security
- Rapid7 — CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP
- watchTowr — CVE-2026-109618: Exploited Remote Code Execution in PHP (FAQ)
- Wiz — PHP2Shell: PHP RCE
- Sekurak — Krytyczne podatności w PHP core. Wyszła łatka
- Android.com.pl — wyłączone strony BIP w związku z PHP2Shell
- CISA — Critical Vulnerabilities in PHP Require Immediate Patching
Stan wiedzy na 29 października 2026 r. Sytuacja szybko się zmienia — sprawdzaj komunikaty projektu PHP i dostawcy swojego systemu.