AI pomogła znaleźć dziurę w PHP, ale łatanie starych serwerów to wciąż robota dla człowieka

W środę 21 października twórcy PHP wydali wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, zapowiedziane dzień wcześniej bez szczegółów. Łatają one dwie luki nazwane wspólnie PHP2Shell, obie z oceną 9,2 na 10 w skali CVSS. Najgroźniejsze są na serwerach Apache z mod_php: napastnik może tam bez logowania, samymi żądaniami HTTP, uruchomić własny kod, zanim strona zdąży wykonać choćby jedną linijkę. Nie omijają jednak innych sposobów uruchamiania PHP, w tym popularnego PHP-FPM. Na PHP działa ok. 69% stron, których język serwerowy da się ustalić, w tym Wikipedia i strony na WordPressie - podaje The Verge za serwisem W3Techs. O odkryciu luk pisaliśmy w środę.

Najstarszy podatny kod pochodzi z PHP 5.4, czyli z 2012 roku. Sam błąd w obsłudze braku pamięci zauważono już w 2024 roku, przy łataniu usterek wskazanych przez zewnętrzny audyt. Nikt jednak nie pokazał, jak go wykorzystać, więc zespół bezpieczeństwa PHP, któremu brakowało ludzi, odkładał poprawkę - PHP Foundation nazywa to „systemową porażką”. W sierpniu tego roku błąd zgłosiły niezależnie od siebie Calif i OpenAI, a dwa tygodnie później także Wiz, należący do Google.

Wiz pisze, że korzystał z modeli Gemini 4 Argon i GPT-5.6 Sol oraz z własnego narzędzia Wiz Atlas. Według firmy „jeden badacz z czołowymi modelami AI i odpowiednimi narzędziami zrobił w tydzień to, co wcześniej zajęłoby światowej klasy zespołowi miesiące pracy”. Który model pomógł Califowi, wiemy tylko od OpenAI. Calif szukał błędów w programie Patch the Planet, który prowadzi OpenAI, i to OpenAI ogłosiło, że lukę znaleziono dzięki GPT-5.6 Sol. Sam Calif nie podaje nazwy modelu, pisze tylko, że korzystał z modeli dostępnych dla każdego.

AI przyspiesza też pracę atakujących. CJ Moses, szef bezpieczeństwa Amazona, tłumaczy, że dawniej większość ataków zaczynała się dopiero po publikacji gotowego exploita. Jego zdaniem AI pozwala dziś tanio zbudować działający exploit z samej poprawki albo komunikatu o luce. Dlatego atakujących może być więcej i mogą uderzyć w ciągu kilku godzin, a nawet minut od ujawnienia szczegółów. Matthew Prince, szef Cloudflare, podał, że w 45 minut od wydania poprawki firma odnotowała w swojej sieci dziesiątki tysięcy prób ataku, a po niespełna 12 godzinach - miliony.

Część atakujących nie czekała nawet na poprawkę. Jak podaje PHP Foundation, w przeddzień jej wydania do sieci wyciekły numery luk, a Calif przez pomyłkę opublikował na chwilę nagranie działającego ataku. Cloudflare zarejestrował tysiące prób w ciągu 10 godzin przed wydaniem poprawki. Amazon znalazł w swoich danych próbę jeszcze wcześniejszą, z 17 października, czyli sprzed wycieku. Skąd ktoś już wtedy wiedział o luce, nie wiadomo. Udanego włamania nikt jednak na razie nie potwierdził.

Część instytucji wolała nie czekać. Jak podaje CNBC za agencją Reutera, w Holandii wyłączono m.in. rządowy portal Overheid.nl, stronę portu w Rotterdamie, a nawet stronę NCSC, czyli samego krajowego centrum cyberbezpieczeństwa. W Finlandii Valtori, państwowy dostawca usług IT, odłączył od internetu publiczne serwisy urzędów, a we Francji wyłączono strony lokalnych urzędów. CERT Polska jeszcze przed wydaniem poprawki zalecał to samo: tymczasowo wyłączyć dostępne z internetu usługi działające na PHP, o ile nie zakłóci to pracy organizacji. Amerykańska agencja CISA radzi zdjąć z sieci systemy, których nie da się od razu zaktualizować, a także wszystkie działające na PHP 8.1 lub starszym.

Niektórzy administratorzy już zaktualizowali stare systemy z pomocą AI i opisują to na forach. Użytkownik Reddita pisze, że Claude pomógł mu w pół godziny przenieść rozbudowaną platformę e-learningową z PHP 5.6 na 8.5. Administrator setek stron na Drupalu 7 pisze, że bez AI takie aktualizacje zajęłyby mu miesiące, a teraz Claude Code naprawia mu błędy, które pojawiają się po zmianie wersji PHP. Inny administrator opisuje, jak w dwie godziny przejrzał z agentem swoje systemy i zaplanował aktualizację. Potem zlecił mu przygotowanie panelu z podsumowaniem i poszedł na obiad. Na Hacker News ktoś napisał, że Claude przerobił mu blog z MediaWiki na statyczne strony, więc do czasu załatania serwera blog może działać bez PHP. To tylko relacje samych autorów i nikt ich nie potwierdził.

Tyle że to historie ludzi, którzy wiedzieli, co robią, i mogli spokojnie przesiąść się na nową wersję. Kto dziś musi w pośpiechu ratować serwer produkcyjny, ma dużo trudniej, a takich serwerów jest mnóstwo. Recorded Future przytacza skany VirusTotal: serwery pod ok. 1,1 mln adresów IP zdradzają wersję PHP, a na 758 tys. z nich, czyli blisko 70%, działa PHP 8.1 lub starszy. Zespół PHP już tych wersji nie wspiera i nie wydał dla nich gotowego wydania z poprawką. Amerykańska agencja CISA radzi odłączyć takie serwery od sieci, dopóki nie zostaną zaktualizowane.

Zostają poprawki z dystrybucji Linuksa i paneli hostingowych, ale nie każdy się ich doczeka. Z zestawienia Digital Applied wynika, że Amazon części pakietów PHP w Amazon Linux nie zamierza łatać wcale. Ubuntu 20.04 dostało poprawkę tylko w Ubuntu Pro, które bez opłat można włączyć najwyżej na pięciu maszynach. Laravel Forge radzi więc, żeby serwer z Ubuntu 20.04 lub starszym zastąpić nowym, a stary wyłączyć.

Bez gotowego pakietu zostają tylko poprawki do kodu źródłowego, które zespół PHP opublikował dla wersji 7.4, 8.0 i 8.1. Trzeba je samemu nanieść i skompilować PHP, i to z tymi samymi rozszerzeniami co dotąd. Starsze wersje nie dostały nawet tego. Pewien użytkownik Reddita ma stronę na PHP 5.6, więc kazał Claude'owi przenieść poprawki do tej wersji. I od razu przyznał: „Czy da się tego używać? A kto to wie”.

Nawet po aktualizacji trudno ocenić, czy serwer jest bezpieczny. Numer wersji z php -v tego nie rozstrzyga: w zestawieniu Digital Applied 21 z 76 pozycji to pakiety, które dostały poprawkę, ale zachowały stary numer. Na przykład Ubuntu 24.04 po aktualizacji dalej pokazuje 8.3.6. Także narzędzie OpenAI do sprawdzania serwerów zastrzega, że wynik „UNKNOWN” nie znaczy „załatany”. Sama instalacja poprawki to jeszcze nie koniec. Trzeba zrestartować wszystkie procesy PHP-FPM, bo te uruchomione przed aktualizacją dalej wykonują stary, podatny kod. Na serwerach z cPanelem albo Pleskiem każdą zainstalowaną wersję PHP łata się osobno.

Doraźne obejścia mają swoją cenę. Blokada żądań multipart, którą zaleca m.in. Sansec, odcina wgrywanie plików, a w części sklepów, jak przyznaje sama firma, psuje też koszyk. Zdjęcie limitu (memory_limit=-1) pozwala obejść błąd w obsłudze braku pamięci, ale wtedy jedno żądanie może zająć całą pamięć serwera. Zespół PHP zastrzega zresztą, że żadne ustawienie nie chroni w pełni.

Zawiodła też AI. Według klientów Hostingera firmowy czatbot zapewniał, że PHP-FPM nie jest podatny, choć twórcy PHP piszą wprost, że jest. Na Hacker News kilku użytkowników skarżyło się, że filtry bezpieczeństwa Claude'a i Codexa przerywały im pracę, gdy zajmowali się tą luką.

Z tych relacji rysuje się prosty podział. AI mocno przyspiesza pracę temu, kto wie, w jakim trybie działa PHP na jego serwerze, skąd pochodzą pakiety i co sprawdzić po aktualizacji. Kto tego nie wie, też dostanie gotowy plan, tylko nie będzie umiał ocenić, czy jest dobry.

Właściciel strony, który sam nie zajmuje się serwerem, może zacząć od dwóch pytań do osoby, która się nim opiekuje: czy poprawka jest już zainstalowana i czy ktoś przejrzał logi od 17 października, kiedy Amazon odnotował pierwszą próbę ataku. Jeśli nikt nie potrafi na nie odpowiedzieć, jeden z komentujących na Hacker News radzi rozważyć hosting zarządzany, na którym PHP aktualizuje dostawca.

Słowniczek: CVSS - skala od 0 do 10, na której ocenia się, jak groźna jest luka w zabezpieczeniach. Exploit - program albo ciąg żądań, który w praktyce wykorzystuje lukę. mod_php - PHP uruchamiane jako moduł serwera Apache. PHP-FPM - PHP uruchamiane jako osobna pula procesów, do której serwer WWW przekazuje żądania. Multipart - format żądania HTTP, w którym przeglądarka wysyła formularze z plikami.