php2shell: co krytyczne luki RCE w PHP oznaczają dla Twojej infrastruktury

Czym jest php2shell

php2shell to nazwa pary luk w silniku Zend w PHP, oznaczonych jako CVE-2026-109618 i CVE-2026-109619. Zespół bezpieczeństwa PHP ocenia obie na CVSS v4.0 9.2. (We wczesnych doniesieniach krążyła liczba 10.0; oficjalna ocena to 9.2 i to ją należy traktować jako wiążącą.)

Obie luki leżą w różnych miejscach cyklu obsługi żądania:

• CVE-2026-109618: po nieudanej alokacji pamięci PHP zostawia nieprawidłowe dane, które trafiają do procedury sprzątającej. Atakujący może wywołać to niepowodzenie spreparowanym żądaniem i uzyskać wykonanie kodu w trakcie sprzątania przez PHP.
• CVE-2026-109619: worker PHP może ponownie użyć nieaktualnego stanu pozostawionego po poprzednim żądaniu.

Najważniejsze dla każdego, kto korzysta z PHP: żądanie wcale nie musi dotrzeć do kodu Twojej aplikacji. Reprodukcja przygotowana przez badaczy bezpieczeństwa wywołuje błąd pojedynczym, nieuwierzytelnionym żądaniem HTTP POST, a PHP uruchamia polecenie atakującego w trakcie obsługi nieudanego żądania. Podatną ścieżkę odsłania dowolny skrypt PHP, nawet taki, który jedynie zwraca odpowiedź. Nie da się tego obejść na poziomie własnej aplikacji: luka jest w interpreterze.

Kogo to dotyczy

Podatne są wersje PHP od 5.4 do 8.5. To w praktyce każde wdrożenie PHP, które nie zainstalowało jeszcze poprawki z 21 października. Ponieważ błąd jest w rdzeniu PHP, obejmuje cały ekosystem:

• strony na WordPressie i WooCommerce
• Drupal
• sklepy Magento / Adobe Commerce
• aplikacje na Laravelu, Symfony i innych frameworkach
• własne usługi PHP i narzędzia wewnętrzne
• wszystko za serwerem PHP-FPM lub mod_php

Jeśli serwer uruchamia PHP i jest osiągalny z internetu, zakładaj, że jest w zasięgu, dopóki nie potwierdzisz wersji.

Poprawka: załataj teraz

Załatane wydania to:

Jeśli jesteś na wspieranej gałęzi (8.2–8.5), zaktualizuj do powyższej wersji i zrestartuj PHP-FPM lub serwer WWW. Na większości zarządzanych platform to aktualizacja pakietu:

# Debian / Ubuntu (dostosuj wersję do zainstalowanej gałęzi)
sudo apt update && sudo apt upgrade php8.3 php8.3-fpm
sudo systemctl restart php8.3-fpm

# RHEL / Amazon Linux (przez Remi lub wybrane repozytorium)
sudo dnf upgrade php php-fpm
sudo systemctl restart php-fpm

# Potwierdź działającą wersję po restarcie
php -v

Sprawdź wersję, którą faktycznie serwuje PHP-FPM, a nie tylko CLI, bo potrafią się różnić:

# Co uruchamia warstwa WWW
php-fpm -v
# Albo ze strony, którą kontrolujesz:
# <?php echo PHP_VERSION;

Nie istnieje pewne obejście inne niż załatanie lub wyłączenie hosta. Web application firewall może przytępić część ładunków, ale ponieważ wyzwalaczem jest zniekształcone żądanie obsługiwane zanim zadziała Twoja aplikacja, nie traktuj WAF-a jako zamiennika poprawki. W chwili publikacji oficjalnych ostrzeżeń nie potwierdzono ataków w praktyce (in-the-wild), ale działające proof-of-concept istnieją w laboratoriach badawczych, więc okno między teraz a aktywnymi atakami jest krótkie.

Jeśli jesteś na PHP 8.1 lub starszym: to decyzja o modernizacji

Tu php2shell zmienia się z łatki w projekt. PHP 8.1 i każda niższa wersja są po end-of-life i mogą nie dostać poprawki. PHP 5.x i 7.x są bez wsparcia od lat. Wciąż działa na nich spora populacja serwerów dostępnych z internetu.

Jeśli to Twój przypadek, apt upgrade nie rozwiązuje problemu. Nie ma załatanej wersji 7.4, na którą można przejść. Realne opcje to:

1. Aktualizacja gałęzi PHP do wspieranej, załatanej wersji (8.2+). To właściwy stan docelowy, ale skok z 7.x na 8.x może nie być przezroczysty: mogą wyjść przestarzałe funkcje, zmienione zachowanie typów i zależności, które same wymagają aktualizacji.
2. Modernizacja platformy wokół aplikacji. W praktyce serwery uwięzione na PHP po EOL są zwykle uwięzione na wszystkim po EOL: stary system operacyjny, niezarządzana maszyna, brak czystej ścieżki wdrożeń do szybkiego nakładania aktualizacji. Zmiana wersji to dobry moment, żeby przenieść środowisko do wersji, którą następnym razem załatasz w minuty (kontenery na ECS lub EKS, albo zarządzane środowisko uruchomieniowe) zamiast serwera-pupila, którego nikt nie chce dotykać.

Uczciwe ujęcie dla decydenta: z PHP po end-of-life i tak trzeba było kiedyś wymienić. php2shell tylko wyznaczył termin. Kosztem pozostania jest teraz niezałatana, nieuwierzytelniona dziura RCE na publicznym serwerze.

Co zrobić w tym tygodniu

1. Inwentaryzacja. Wypisz każdy host, kontener i usługę zarządzaną, która uruchamia PHP, i zanotuj dokładną wersję serwowaną przez warstwę WWW. Nie pomijaj środowisk przed-produkcyjnych jak staging czy development, paneli administracyjnych i tego jednego starego serwera.
2. Załataj wspierane. Wszystko na 8.2–8.5 natychmiast idzie na załataną wersję.
3. Zajmij się tymi po EOL. Dla PHP ≤ 8.1 zdecyduj per obciążenie: zaktualizować gałąź, zmigrować platformę, albo wyłączyć do czasu, aż się da. Nie zostawiaj publicznego hosta z PHP po EOL bez działania.
4. Zweryfikuj. Po załataniu ponownie sprawdź serwowaną wersję i potwierdź, że host nie jest już skompromitowany (nieoczekiwane procesy, nowe wpisy cron, zmodyfikowane pliki w katalogu web).

Łatanie wspieranych wersji opisaliśmy wyżej, więc działaj dziś. Dla obciążeń po EOL, których nie da się po prostu załatać, rozwiązaniem jest rozmowa o migracji i modernizacji. Pomagamy zespołom przenieść starsze PHP z serwerów po end-of-life na łatalną, zarządzaną infrastrukturę. Zobacz Migrację do chmury, a jeśli najpierw chcesz uporządkowane spojrzenie na całe środowisko, nasz Well-Architected Review.

Masz aplikacje w PHP i nie wiesz, na czym stoisz?

Umów bezpłatną 30-minutową rozmowę. Pomożemy znaleźć podatne PHP, załatać to, co da się załatać, i zaplanować zejście z wszystkiego, co jest po end-of-life.

Umów rozmowę Napisz do nas