Środowa gorączka wokół dwóch krytycznych luk w PHP — jednym z najpopularniejszych języków skryptowych sieci — okazała się spóźniona. Jak wynika z opublikowanych wieczorem ustaleń Amazona, co najmniej jeden podmiot próbował wykorzystać błędy już 17 października, czyli cztery dni przed tym, zanim świat dowiedział się o ich istnieniu.

Poprawki wydane w środę wywołały wyścig: administratorzy i zespoły bezpieczeństwa gorączkowo szukały podatnych stron i aplikacji, a napastnicy — jak to zwykle bywa — inżynierią wsteczną łatki ustalali, jak zaatakować niezałatane systemy. Część instytucji publicznych i organizacji zdecydowała się nawet profilaktycznie wyłączyć kluczowe serwisy, by nie stały się celem w oknie między ujawnieniem a wdrożeniem zabezpieczeń.

Dowody na wcześniejszą aktywność znalazła firma Amazon Web Services. Analitycy przeglądając zapisy jednego ze swoich honeypotów — celowo podatnych serwerów-pułapek służących do badania metod ataków — natrafili na próbę eksploatacji z 17 października. Połączenie pochodziło z adresu IP powiązanego z „komercyjną siecią anonimizującą”, czyli siecią proxy lub VPN. „Choć podatność była objęta embargiem, kierowanie ataku na honeypot z anonimizowanego adresu sugeruje działania aktora zagrożenia — nie jest jednak jasne, w jaki sposób zdobył on informacje o błędzie przed ujawnieniem” — napisał CJ Moses, dyrektor ds. bezpieczeństwa informacji w AWS.

W środę zaczęły pojawiać się publiczne dowody koncepcji (proof-of-concept), a część z nich — zdaniem badaczy — krążyła w sieci na godziny przed oficjalnym ogłoszeniem o 10 czasu wschodniego. W ciągu kilku godzin poprzedzających ujawnienie honeypoty AWS odnotowały wiele prób eksploatacji, anonimizowanych przez różnych dostawców i prowadzonych najwyraźniej w różnych celach — co wskazuje na kilka niezależnych grup. „Analiza techniczna trwa i nie wiadomo, czy którakolwiek z tych prób zakończyłaby się sukcesem w realnym systemie” — zaznaczył Moses, dodając jednak, że PHP2Shell „jest obecnie powszechnie wykorzystywany w internecie”. Fundacja PHP nie odpowiedziała od razu na prośbę o komentarz.

Najciekawszy wątek ma charakter systemowy. AWS podkreśla, że incydent obnaża słabość dotychczasowego modelu skoordynowanego ujawniania podatności. „Czas od łatki do działającego exploita kurczy się z przyczyn strukturalnych” — pisze Moses. Dawniej większość ataków następowała po publikacji proof-of-concept: nieliczni zdolni gracze budowali narzędzia, reszta czekała. Ta zależność słabnie, bo analiza wspierana sztuczną inteligencją sprawia, że przekształcenie różnicy w łatce lub biuletynu bezpieczeństwa w działający exploit jest tańsze i szybsze — a przez to dostępne także dla mniej biegłych technicznie aktorów. Coraz więcej osób może reagować w ciągu godzin, a nawet minut od ujawnienia szczegółów technicznych.

Wniosek dla administratorów jest prosty, choć niewygodny: samo tempo łatania przestaje wystarczać. Okno bezpieczeństwa skraca się tak szybko, że kluczowa staje się wcześniejsza higiena systemów — minimalizacja ekspozycji, segmentacja, monitoring anomalii i gotowe procedury awaryjnego wyłączania usług. Historia PHP2Shell pokazuje, że w erze AI wyścig zaczyna się, zanim jeszcze zabrzmi sygnał startowy.