Amazon podał, że system MadPot zarejestrował 17 października 2026 r. próbę wykorzystania luk PHP2Shell przeciwko honeypotowi, cztery dni przed publicznym ujawnieniem podatności. PHP opublikowało poprawki 21 października. Obserwacja Amazonu dotyczyła jego pułapki i czujników; firma nie ustaliła, czy próby zadziałałyby w rzeczywistych systemach. Relacja Amazonu o telemetrii MadPot
Co Amazon zaobserwował przed ujawnieniem luk
Według Amazonu pierwsza opisana próba trafiła do honeypotu MadPot 17 października. Firma odnotowała też aktywność 21 października: pierwsze exploity typu proof of concept pojawiły się około 02:00 UTC, a kolejne próby przeciwko czujnikom MadPot napływały między 02:00 a 08:00 UTC. Po zniesieniu embarga przez PHP o 14:00 UTC Amazon zauważył dalszą aktywność.
Honeypot to system-pułapka, który ma rejestrować próby ataków. W tym przypadku Amazon opisał ruch skierowany na własne sensory. Nie oznacza to, że doszło do włamania na strony lub serwery korzystające z PHP.
Dwie luki w rdzeniu PHP umożliwiały zdalne wykonanie kodu
PHP2Shell to wspólna nazwa dla dwóch krytycznych podatności w rdzeniu PHP: CVE-2026-109618 i CVE-2026-109619. PHP oceniło każdą na 9,2 w skali CVSS v4.0. Obie mogły umożliwić nieuwierzytelnione zdalne wykonanie kodu w instalacjach obsługujących żądania sieciowe.
CVE-2026-109618 wiąże się z błędem obsługi braku pamięci. Niekompletne dane żądania mogły zostać przetworzone podczas zamykania żądania. CVE-2026-109619 dotyczy nieaktualnego stanu globalnego i użycia zwolnionej pamięci: proces roboczy mógł zachować odwołanie do danych poprzedniego żądania, zanim inicjalizacja zastąpiła ten stan.
PHP wymieniło jako objęte zakresem środowiska PHP-FPM, Apache mod_php, php-cgi, FrankenPHP i LiteSpeed. Projekt wskazał Apache mod_php jako konfigurację o najwyższym ryzyku.
Poprawione wersje PHP i starsze gałęzie
PHP opublikowało poprawki dla obu CVE w wersjach 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Wskazane przez projekt wersje upstream poniżej tych wydań są objęte podatnościami. Pakiety dystrybucji mogą jednak zawierać poprawki przeniesione do starszej gałęzi, czyli backporty, dlatego sam numer wersji upstream nie zawsze rozstrzyga o stanie pakietu. Komunikat bezpieczeństwa PHP
PHP 8.1 i starsze nie otrzymują już aktualizacji od projektu PHP. Dystrybucje i dostawcy oferujący długoterminowe wsparcie mogą przygotować własne backporty; projekt PHP przekazał też poprawki źródłowe dla wersji 7.4, 8.0 i 8.1. Administrator powinien sprawdzić stan konkretnego pakietu u jego dostawcy.
WAF nie zastępuje poprawki
Zapora aplikacji internetowej, czyli WAF, ani zmiana konfiguracji nie stanowią pełnego rozwiązania. PHP wskazuje instalację wydania zawierającego poprawki jako jedyną kompletną metodę usunięcia podatności. Ustawienia mogą ograniczyć wybrane ścieżki ataku, ale nie czynią instalacji bezpieczną bez aktualizacji. Szczegóły dotyczące obu błędów opisują biuletyn CVE-2026-109618 i biuletyn CVE-2026-109619.
