Dwie krytyczne luki w PHP z CVSS 9,2 wyciekły dzień przed łatką, a exploity już krążą

Projekt PHP wydał poprawki dwóch błędów, przez które atakujący bez logowania uruchomi kod na serwerze. Wyciek numerów CVE i przypadkiem opublikowane wideo dały jednak napastnikom przewagę, więc administratorzy ścigają się teraz z działającymi exploitami.

Łatki wyszły dzień wcześniej, bo numery CVE wyciekły

21 października projekt PHP wydał wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Naprawiają dwa krytyczne błędy z oceną CVSS v4.0 9,2. Pierwszy (CVE-2026-109618) pojawia się, gdy żądanie trafi na memory_limit w złym momencie. PHP uznaje wtedy niedokończone dane za poprawne i psuje pamięć. Drugi (CVE-2026-109619) zostawia po błędzie krytycznym odwołanie do pamięci, którą zwolniło już wcześniejsze żądanie.

Łatki miały wyjść 22 października o 14:00 UTC. Dzień wcześniej, około 15:00 UTC, oba numery CVE trafiły na fora i do mediów społecznościowych, w dodatku z błędną oceną 10,0. Według PHP Foundation szczegóły techniczne nie wyciekły. Projekt przesunął więc wydanie o dzień. Wieczorem firma Calif przez pomyłkę opublikowała wideo, na którym jej proof of concept działa na kilku celach. Nagranie usunięto, ale kopie dalej krążyły i według fundacji przyspieszyły powstanie kolejnych exploitów.

Najgorzej mają serwery Apache z mod_php. Wystarczy tam jedno żądanie bez logowania, które uruchamia atak, zanim ruszy kod aplikacji, i to przy domyślnych ustawieniach. Zagrożone są jednak wszystkie instalacje obsługujące ruch WWW, w tym PHP-FPM, php-cgi, FrankenPHP i LiteSpeed. Wiz Research, jedna z firm zgłaszających błędy, pokazała atak bez logowania na WordPressa, Drupala i Joomlę. Według Wiz podatna jest każda wersja PHP od 5.4. Ta sama firma podaje, że PHP napędza 70 % stron internetowych.

Błąd siedział w PHP dwa lata, aż rozpracowały go modele frontier

Najciekawsza jest oś czasu. Pierwsze ślady problemu z pamięcią znalazł programista opłacany przez PHP Foundation już w 2024 roku. Stało się to podczas zewnętrznego audytu, który sfinansowała Sovereign Tech Agency, a przeprowadził Quarkslab. Nikt nie znał wtedy drogi do wykonania kodu. Zespół rozważał kilka poprawek i każda coś psuła: kompatybilność, wydajność albo rozszerzenia firm trzecich. Fundacja sama nazywa to opóźnienie strukturalną porażką małego zespołu, który decydował konsensusem.

Przełom nastąpił w sierpniu 2026. 11 sierpnia Calif zgłosił bezwarunkowe wykonanie kodu z tą samą przyczyną. Kolejne ścieżki ataku dorzuciły Wiz i OpenAI. Wiz podaje, że pierwszy błąd znalazł dzięki własnemu narzędziu Wiz Atlas oraz modelom Gemini 4 Argon i GPT-5.6 Sol. Exploit wymaga według firmy połączenia kilku błędów i dopasowania ich do układu pamięci każdego celu. Modele frontier skróciły tę pracę do godzin.

Tu jest drugie dno tej historii. Złożoność exploita długo działała jak cicha ochrona: o błędzie wiedziano, ale nikt nie miał czasu go dokończyć. Skoro tę robotę wykona model, teoretyczny błąd nie poczeka już latami. Administratorzy mają mniej czasu między ogłoszeniem a atakiem, a projekty open source więcej pracy przy niewielkiej liczbie ludzi. Od 1 lipca zespół PHP opublikował 15 CVE i przejrzał ponad 100 zgłoszeń, które okazały się nieważne, zdublowane albo niemożliwe do odtworzenia.

Żadna konfiguracja w pełni nie zabezpieczy serwera

Projekt PHP opisuje środki tymczasowe, na przykład wyłączenie session.upload_progress albo inną obsługę memory_limit. Sam przy tym przyznaje, że żaden z nich nie czyni instalacji bezpieczną. Pełną ochronę daje tylko aktualizacja. Wersje starsze niż 8.2 nie dostaną poprawki od projektu. Ich użytkownicy zależą od backportów dystrybucji albo dostawcy wsparcia długoterminowego. Utrzymywane przez wolontariuszy repozytorium pakietów, na którym polega wiele serwerów, w dniu wydania nie miało aktualizacji.

Dla polskich stron kluczowe pytanie trafia do hostingu. Na hostingu współdzielonym klient często sam nie zmieni wersji PHP, więc ryzyko zależy od tego, jak szybko zareaguje dostawca. Własne kontenery i obrazy same się nie naprawią. Trzeba je przebudować i zrestartować wszystkie workery.

Tempo hostingów pokaże, ile stron zostanie odsłoniętych

Pierwszy sygnał dadzą hostingi i dystrybucje. Dystrybucje Linuksa i dostawcy LTS dostali łatki wcześniej, więc powinni mieć pakiety od razu. Strony u powolnych dostawców będą pierwsze w kolejce dla napastników, którzy mają już działający exploit.

Drugi sygnał jest długoterminowy. PHP Foundation prosi firmy, które opierają się na PHP, o wsparcie finansowe prac nad bezpieczeństwem. Jeśli AI dalej będzie przyspieszać zarówno szukanie błędów, jak i ich wykorzystanie, pieniądze na utrzymanie staną się kwestią bezpieczeństwa operacyjnego. Wersja 8.2 traci przy tym wsparcie 31 grudnia 2026, więc kolejna taka poprawka już jej nie obejmie.

Werdykt Lilith

Błąd z 2024 roku przeleżał dwa lata w notatkach małego zespołu, aż modele frontier zrobiły z niego exploit. Potem wystarczyło jedno przypadkiem opublikowane wideo, żeby napastnicy ruszyli tej samej nocy co administratorzy serwerów.