Według Amazon Web Services (AWS) system pułapek MadPot zarejestrował próbę wykorzystania PHP2Shell 17 października 2026 roku, cztery dni przed publicznym ujawnieniem podatności. Zdarzenie dotyczyło honeypota, czyli systemu-pułapki, a AWS ocenił, że skuteczność podobnych prób na rzeczywistych serwerach pozostaje niejasna. PHP wskazał dwie podatności, zagrożone integracje i poprawione wydania runtime’u.

Co AWS odnotował przed ujawnieniem podatności

Amazon Threat Intelligence podał, że 17 października ruch z adresu IP powiązanego z komercyjną infrastrukturą anonimizującą skierowano przeciw MadPot. AWS odnotował też kolejne próby i exploity proof of concept wokół publicznego ujawnienia podatności 21 października. Nie wskazał, kto stał za aktywnością ani jak zdobył informacje o luce przed jej ujawnieniem.

Dwie podatności i poprawione wydania PHP

PHP2Shell to wspólna nazwa dwóch błędów w jądrze PHP, które mogą umożliwić zdalne wykonanie kodu bez uwierzytelnienia. CVE-2026-109618 dotyczy uszkodzenia pamięci przy jej wyczerpaniu. CVE-2026-109619 wiąże się z nieaktualnym stanem żądania, którego pamięć została zwolniona, a który może zostać użyty przez kolejne żądanie obsługiwane przez ten sam proces roboczy. PHP ocenił obie podatności na 9,2 w skali CVSS 4.0.

Komunikat PHP wymienia instalacje obsługujące żądania internetowe przez PHP-FPM, Apache mod_php, php-cgi, FrankenPHP i LiteSpeed. Za wariant najwyższego ryzyka uznaje Apache mod_php, ponieważ niezalogowane żądanie może wywołać problem, zanim ruszy kod aplikacji.

Poprawki zawierają wydania PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dostawcy systemów i długoterminowo wspieranych pakietów mogą przenosić poprawki do starszych gałęzi, zachowując własną numerację. Dlatego administrator powinien sprawdzić komunikat dostawcy używanego pakietu PHP, a nie zakładać, że jedynym potwierdzeniem poprawki jest numer wydania upstream. Oficjalny komunikat PHP wymienia również starsze gałęzie i środki ograniczające część dróg ataku.

Co wynika z obserwacji innych sensorów

Telekom Security opisał dane z własnej sieci honeypotów. Jej sensory nie odnotowały ładunku przypominającego exploit przed pojawieniem się komunikatów o podatnościach; pierwsze takie ładunki serializowane zarejestrowały 21 października o 14:18 UTC. To obserwacja z odrębnej sieci sensorów, podczas gdy AWS przypisał próbę z 17 października telemetrii MadPot.

Aktualizacja i analiza ruchu

PHP wskazuje aktualizację runtime’u do wydania z poprawką jako pełne rozwiązanie. Ustawienia konfiguracyjne mogą ograniczyć konkretne ścieżki ataku, ale nie zastępują aktualizacji. AWS zaleca administratorom, którzy nie mogą od razu zaktualizować PHP, rozważenie czasowego ograniczenia przesyłania plików wieloczęściowych po sprawdzeniu wpływu takiej zmiany na aplikację. Wskazuje też na analizę żądań POST zawierających PHP_SESSION_UPLOAD_PROGRESS, logów serwera WWW oraz nieoczekiwanego uruchamiania procesów i zmian plików.

AWS wymienił sześć adresów IP zaobserwowanych w związku z aktywnością: 103.216.220.92 17 października oraz 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 i 95.217.98.37 21 października. AWS zaznaczył, że adresy obejmują współdzieloną infrastrukturę anonimizującą i nie są wyłączne dla tej aktywności; zalecił analizę dopasowań zamiast automatycznego blokowania.