PHP2Shell: pilne łatki dla krytycznych luk

PHP2Shell staje się realnym problemem

Środowisko PHP znalazło się pod presją po ujawnieniu dwóch krytycznych podatności, które mogą prowadzić do remote code execution bez uwierzytelnienia. Błędy oznaczone jako CVE-2026-109618 i CVE-2026-109619 otrzymały ocenę 9,2 w skali CVSS v4.0 i zostały zbiorczo nazwane PHP2Shell.

Najważniejsze jest to, że problem dotyczy samego runtime PHP, a nie konkretnej aplikacji. W praktyce oznacza to zagrożenie dla całego ekosystemu stron i usług opartych na PHP, w tym popularnych platform takich jak WordPress, Drupal, Joomla czy Laravel.

Jakie wersje dostały poprawki

Dla wspieranych gałęzi PHP opublikowano pilne wydania:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Poprawki trafiły najpierw do oficjalnych kanałów, a część dostawców dystrybucji Linux i hostingów otrzymała je wcześniej, by móc przygotować własne pakiety. W przypadku starszych środowisk sytuacja jest trudniejsza: PHP 8.1 i starsze wersje nie są już wspierane upstream, więc wielu administratorów musi polegać na backportach od dystrybucji lub dostawcy hostingu.

Gdzie ryzyko jest największe

Z punktu widzenia ekspozycji najgorszy scenariusz dotyczy konfiguracji Apache z mod_php. Właśnie tam potwierdzono możliwość uruchomienia ataku za pomocą zwykłego, nieautoryzowanego żądania HTTP, jeszcze zanim wykona się jakikolwiek kod aplikacji.

Zagrożone są również inne tryby obsługi ruchu webowego:

• PHP-FPM
• php-cgi
• FrankenPHP
• LiteSpeed

To oznacza, że łatki trzeba wdrażać szeroko, a nie tylko na wybranych serwerach.

Na czym polegają błędy

Obie luki mają wspólny mianownik: nieprawidłową obsługę stanu pamięci po przerwaniu przetwarzania żądania.

CVE-2026-109618

Ta podatność wiąże się z sytuacją, w której PHP trafia na błąd braku pamięci, a część danych żądania pozostaje tylko częściowo zainicjalizowana. Później mechanizm sprzątający traktuje je tak, jakby były poprawne. W rezultacie możliwe staje się wykorzystanie tego stanu do wykonania własnego kodu.

CVE-2026-109619

Druga luka dotyczy pozostawienia odwołań do już zwolnionej pamięci, czyli klasycznego scenariusza use-after-free. Kolejne żądanie obsługiwane przez ten sam worker może użyć nieaktualnych danych, co otwiera drogę do wycieku pamięci, a w niektórych warunkach również do zdalnego wykonania kodu.

Co już obserwują specjaliści

Według dostępnych informacji ruch atakujący już się pojawia. Część prób ma charakter rozpoznawczy, ale widoczne są też próby obchodzenia reguł WAF poprzez modyfikowanie payloadów. W odpowiedzi niektórzy dostawcy usług ochrony sieciowych wdrożyli tymczasowe reguły blokujące znane wektory ataku.

Warto jednak podkreślić: WAF nie jest zamiennikiem patcha. Może jedynie ograniczyć ryzyko na czas wdrażania poprawek.

Co powinien zrobić administrator

Najważniejsze jest szybkie i uporządkowane działanie:

1. Zidentyfikować wszystkie systemy używające PHP – także kontenery, starsze instancje i środowiska testowe.
2. Sprawdzić, jaka wersja PHP faktycznie działa na serwerze.
3. Wdrożyć poprawki dla wspieranych wersji.
4. Zrestartować usługi i workerów, aby nowe biblioteki rzeczywiście zaczęły działać.
5. Jeśli patch nie jest dostępny, ograniczyć ekspozycję lub czasowo odłączyć usługę od Internetu.

Tymczasowe obejścia, nie rozwiązanie

Wśród proponowanych obejść pojawia się kilka ustawień, które mogą zmniejszyć powierzchnię ataku, ale nie zastępują aktualizacji.

Dla części scenariuszy zaleca się wyłączenie mechanizmu śledzenia postępu uploadu:

session.upload_progress.enabled = Off

To może pomóc w ograniczeniu jednego z możliwych wektorów, ale nie daje pełnej ochrony. Wspominane są także dodatkowe kroki, takie jak:

• ograniczenie rozmiaru i liczby żądań multipart,
• zmniejszenie post_max_size tam, gdzie to możliwe,
• wyłączenie fatal_error_backtraces w PHP 8.5,
• odcięcie aplikacji publicznych od Internetu, jeśli nie da się ich szybko załatać.

Starsze wersje PHP to dziś poważny kłopot

Cała sytuacja ponownie pokazuje, jak duże ryzyko wiąże się z utrzymywaniem starych gałęzi PHP. Jeśli organizacja wciąż działa na wersjach bez wsparcia, każda kolejna krytyczna podatność staje się problemem operacyjnym, a nie tylko technicznym.

W praktyce oznacza to, że samo „posiadanie działającej strony” nie wystarcza. Trzeba jeszcze mieć możliwość szybkiego wdrażania poprawek, restartu usług i kontroli nad całym łańcuchem wdrożeniowym.

Wniosek

PHP2Shell nie jest zwykłą podatnością w aplikacji, lecz problemem na poziomie fundamentu, na którym działa ogromna część Internetu. Dla administratorów liczy się teraz jedno: sprawdzić wersje, wdrożyć poprawki i ograniczyć ekspozycję, zanim ktoś zrobi to za nich.