Zespół bezpieczeństwa PHP opublikował awaryjne wydania łat dla dwóch krytycznych luk bezpieczeństwa, oznaczonych jako CVE-2026-109618 oraz CVE-2026-109619. Podatności te są wspólnie określane nazwą PHP2Shell i pozwalają na nieuwierzytelnione zdalne wykonanie kodu (RCE).

Problem dotyczy wszystkich środowisk PHP przetwarzających żądania webowe, w tym PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP oraz LiteSpeed. Według zespołu PHP największe ryzyko występuje w przypadku konfiguracji z mod_php, gdzie przygotowane żądanie od nieuwierzytelnionego użytkownika może wywołać atak jeszcze przed uruchomieniem kodu aplikacji.

Podatności PHP2Shell wynikają z uszkodzenia stanu pamięci

Obie luki mają to samo źródło: nieprawidłowe zakończenie żądania pozostawia pamięć interpretera w stanie uszkodzonym, co pozwala na osiągnięcie zdalnego wykonania kodu.

Luka CVE-2026-109618 polega na wywołaniu łańcucha błędów prowadzących do wyczerpania pamięci i uszkodzenia jej struktur, co daje możliwość wykonania kodu z uprawnieniami konta roboczego web. Podatność CVE-2026-109619 dotyczy nieaktualnego stanu globalnego i umożliwia nieuwierzytelniony błąd typu heap use-after-free, ujawnienie zawartości pamięci oraz zdalne uruchomienie kodu z uprawnieniami procesu roboczego web.

Według danych VirusTotal w sieci dostępnych jest ponad 5,1 miliona hostów z PHP, z czego około 3,8 miliona ma przynajmniej jeden otwarty port. PHP zasila od 75% do 80% stron internetowych, w tym serwisy oparte o WordPress, Joomla i Drupal.

Wydane wersje i aktywne próby ataków

Administratorzy powinni niezwłocznie wdrożyć poprawione wydania: PHP 8.5.12, 8.4.27, 8.3.36 oraz 8.2.35. Gałęzie PHP 8.1 i starsze nie otrzymują już oficjalnego wsparcia od projektu, dlatego autorzy zalecają migrację lub kontakt z dostawcami dystrybucji oferującymi wsparcie długoterminowe. Z uwagi na powagę tych luk udostępniono również minimalne łatki w kodzie źródłowym dla wersji PHP 7.4, 8.0 oraz 8.1.

Brytyjskie Narodowe Centrum Bezpieczeństwa Cybernetycznego (NCSC) wezwało brytyjskie organizacje do bezzwłocznej aktualizacji lub wyłączenia podatnych systemów. Dyrektor ds. technologii w firmie Cloudflare, Dane Knecht, potwierdził zaobserwowanie wczesnych prób wykorzystania obu podatności, podkreślając tymczasowy charakter reguł zapory WAF.

Tymczasowe środki zaradcze nie zastępują aktualizacji

Przedstawicielka zespołu deweloperskiego PHP, Gina Peter Banyard, zaznaczyła, że żadne reguły ochronne ani obejścia nie blokują ataków w całości, a jedyną trwałą ochroną pozostaje instalacja oficjalnych poprawek. Dla systemów, które nie mogą zostać od razu zaktualizowane, zespół PHP wskazał doraźne kroki ograniczające wybrane ścieżki ataku:

Ustawienie wartości memory_limit=-1 w konfiguracji, której aplikacje nie mogą nadpisać, na przykład poprzez php_admin_value w puli FPM lub konfiguracji serwera Apache.
Obniżenie dyrektywy post_max_size do wartości 8M w systemach bez obsługi wgrywania plików lub do 32M, jeśli przesyłanie plików jest wymagane.
Wprowadzenie limitów cgroup lub ograniczeń kontenera z polityką zabijającą wyłącznie dotknięty proces roboczy.
Ustawienie session.upload_progress.enabled=0 oraz ponowne uruchomienie wszystkich procesów roboczych.
Wyłączenie generowania śladów błędów fatalnych w PHP 8.5 za pomocą fatal_error_backtraces=0 wraz z restartem procesów roboczych.
Usunięcie nieprawidłowych lub przestarzałych dyrektyw ustawianych per żądanie, które zgłaszają diagnostykę przed inicjalizacją. Ukrywanie komunikatów przez error_reporting, display_errors lub @ nie chroni przed błędem.
Naprawienie dostępnych dla atakującego błędów krytycznych i przekroczeń czasu wykonania skryptów, w tym niepowodzeń w funkcjach zwrotnych, przetwarzaniu wgrywania lub importu oraz czyszczeniu.