Poprawka usuwająca luki PHP2Shell jest już dostępna, ale większość witryn, które jej potrzebują, nie ma przycisku, który wystarczy nacisnąć. Błędy tkwią w samym PHP — silniku obsługującym każdą stronę WordPress, Joomla i Drupal — poniżej systemu CMS, jego wtyczek i ekranu logowania. Aktualizacja WordPressa nic tu nie zmieni. Poprawioną wersję interpretera musi dostarczyć podmiot zarządzający serwerem: firma hostingowa, pakiet dystrybucji Linuksa albo obraz kontenera. Dopóki to się nie stanie, witryna pozostaje narażona, niezależnie od działań jej właściciela.

Właśnie ten aspekt pomijają nagłówki wzywające do „natychmiastowej instalacji poprawki”. Zespół PHP wykonał swoją pracę. To, czy trafi ona na konkretny serwer, zależy od łańcucha dostaw, którego tempo wyznacza jego najwolniejsze ogniwo — a już pierwszego dnia było widać, jak duże są różnice między poszczególnymi ogniwami. Właściciel, który nie wie, skąd jego serwer pobiera PHP, nie jest w stanie ocenić, jak bardzo witryna nadal jest narażona.

Dlaczego aktualizacja WordPressa nie rozwiązuje problemu

Ponieważ błędy znajdują się w interpreterze, komunikat bezpieczeństwa PHP obejmuje każdą instalację obsługującą żądania internetowe — od PHP-FPM i mod_php w Apache po php-cgi, FrankenPHP i LiteSpeed. Jak zauważa The Hacker News, atak można przeprowadzić nawet na podatnej wersji strony wyświetlającej zwykły komunikat „Hello World”. Najgorszy scenariusz dotyczy mod_php: pojedyncze żądanie od osoby bez konta może uruchomić atak, zanim wykona się jakikolwiek kod aplikacji. Nie wykryje go więc ani wtyczka bezpieczeństwa, ani ekran logowania.

Wordfence, firma oferująca zabezpieczenia WordPressa, poinformowała właścicieli witryn — jak donosi The Verge — że poprawka nie może dotrzeć do nich za pośrednictwem automatycznych aktualizacji i że muszą ustalić, kto odpowiada za ich PHP. To samo swoim klientom przekazał Laravel Forge w odniesieniu do zarządzanych przez siebie serwerów: automatyczne aktualizacje zabezpieczeń nie obejmują PHP, a mechanizm unattended upgrades w Ubuntu pobiera aktualizacje wyłącznie z własnego repozytorium Ubuntu, nie zaś z zewnętrznych pakietów, z których Forge instaluje PHP.

Poszczególne źródła pakietów nie zareagowały w tym samym czasie. W dniu publikacji poprawek serwis do zarządzania witrynami mySites.guru poinformował, że cPanel EasyApache 4 udostępnił poprawione kompilacje w ciągu kilku minut od ogłoszenia luk. Tymczasem PPA Ondřeja Surý’ego — źródło pakietów Ubuntu, z którego korzysta sam Laravel Forge — oraz repozytorium Remiego nadal ich nie miały. InMotion Hosting przekazał, że jego serwery współdzielone i serwery WordPress czekają na kompilacje CloudLinux. Wśród aktywnych witryn monitorowanych przez mySites.guru o 13:52 UTC poprawioną wersję PHP zgłaszało 0,08%.

Numer wersji może wprowadzać w błąd

Sprawdzenie, czy poprawka jest zainstalowana, nie sprowadza się do odczytania numeru wersji. Ubuntu, Debian i Red Hat przenoszą poprawki bezpieczeństwa do starszych wersji oprogramowania bez zmiany numeru wersji źródłowej. Dlatego na poprawnie zabezpieczonym serwerze Ubuntu 24.04 pakiet nadal może mieć numer 8.3.6. The Hacker News, powołując się na Debiana, zaleca sprawdzenie dziennika zmian pakietu pod kątem identyfikatora CVE, zamiast polegania na numerze wersji. mySites.guru wskazuje też na drugą pułapkę: plik binarny PHP, który odpowiada na polecenie php -v w wierszu poleceń, często nie jest tym samym, który obsługuje strony. Trzeba więc sprawdzić wersję zgłaszaną przez samą witrynę.

Następnie poprawka musi zostać załadowana. W komunikacie PHP i w informacjach od Forge podkreślono, że trzeba zrestartować Apache, PHP-FPM oraz wszystkie procesy działające długotrwale. Procesy kolejek i podobne zadania w tle nadal korzystają ze starego interpretera, dopóki nie zostaną ponownie uruchomione — niezależnie od tego, czy poprawione pliki znajdują się już na dysku.

Kto nie dostanie oficjalnej poprawki

Poprawione wydania to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Usuwają one luki CVE-2026-109618 i CVE-2026-109619, którym w skali CVSS v4.0 przypisano ocenę 9,2. Użytkownicy PHP 8.1 i starszych wersji nie dostaną od projektu PHP nic poza minimalnymi poprawkami przeniesionymi do kodu źródłowego wersji 7.4, 8.0 i 8.1, przeznaczonymi dla osób samodzielnie kompilujących PHP. Niektórzy dostawcy uzupełniają tę lukę: InMotion informuje, że cPanel przeniósł poprawki do pakietów w wersjach od 7.4 do 8.1, a CloudLinux łata każdą wydawaną przez siebie wersję. CentOS 7 nie otrzyma żadnej poprawki.

Ta grupa przestarzałych instalacji wcale nie jest mała. Dzień przed publikacją poprawek 22,7% aktywnych witryn Joomla i WordPress monitorowanych przez mySites.guru działało na PHP 8.1 lub starszym, a 16,6% nadal korzystało z PHP 7 lub wcześniejszej wersji. Firma wskazuje, że częściowo odpowiada za to sam WordPress: zaleca PHP 8.3, ale wciąż wymienia dawno wycofaną wersję 7.4 jako zgodną. PHP 8.2 otrzymało tę poprawkę, jednak wsparcie bezpieczeństwa dla tej wersji kończy się 31 grudnia 2026 roku.

Co blokuje tymczasowe ustawienie

Rozwiązanie tymczasowe, które krążyło przed publikacją poprawki — ustawienie session.upload_progress.enabled=0 — jest skuteczne, ale tylko częściowo. PHP informuje, że blokuje ono potwierdzone ścieżki wykorzystujące sesje do uruchomienia CVE-2026-109619, ale nie inne warianty ataku. Ustawienie trzeba wprowadzić w pliku php.ini albo w konfiguracji serwera lub puli, a następnie zrestartować wszystkie procesy robocze. W PHP 8.5 ustawienie fatal_error_backtraces=0 zamyka jeszcze jedną potwierdzoną ścieżkę. Żadne z tych ustawień nie zabezpiecza przed CVE-2026-109618. W tym przypadku PHP zaleca niepodlegające nadpisaniu ustawienie memory_limit=-1, niski limit post_max_size oraz ograniczenia rozmiaru żądań na serwerze WWW lub serwerze proxy. Jak stwierdza sam projekt, nie ma pełnych zabezpieczeń łagodzących skutki ataku. InMotion zwraca uwagę, że WordPress, Joomla, Drupal, Magento i PrestaShop nie korzystają z mechanizmu śledzenia postępu przesyłania plików, więc jego wyłączenie niczego w tych systemach nie zepsuje.

Cloudflare włączył reguły zapory dla wszystkich planów. Dyrektor ds. technologii firmy, Dane Knecht, określił je jako rozwiązanie doraźne. Jak zauważa mySites.guru, pomogą one tylko wtedy, gdy serwer za zaporą odrzuca ruch omijający Cloudflare i kierowany bezpośrednio na jego adres IP.

Dotychczasowe ataki

Firma watchTowr poinformowała, że w dniu publikacji poprawek jej pułapki honeypot zarejestrowały próby wykorzystania obu luk. Cloudflare zaobserwował zaś, że napastnicy zmieniali ładunki, by ominąć jego reguły. Żadne źródło nie potwierdziło skutecznego włamania na konkretny serwer. Niektórzy operatorzy nie chcieli ryzykować: The Hacker News donosi, że BambooHR wyłączyło swoją usługę, a holenderskie usługi publiczne, w tym DigiD, zostały prewencyjnie odcięte. CERT UE i brytyjskie National Cyber Security Centre zaleciły organizacjom, które nie mogą zainstalować poprawki, odizolowanie narażonych aplikacji albo ich wyłączenie.

Luki wykryły zespoły Wiz Research, Calif i Codex Security z OpenAI. Według PHP Foundation ślady błędu związanego z pamięcią pojawiły się podczas audytu w 2024 roku, ale prace nad poprawką utknęły na wiele miesięcy. Fundacja określiła to opóźnienie jako „strukturalną porażkę”. Badacze twierdzą, że modele AI pomogły przekształcić błędy mające dekadę w działające exploity w ciągu około tygodnia.

PHP potrzebowało audytu, miesięcy impasu i wycieku, by opublikować tę poprawkę. W przypadku witryny na hostingu współdzielonym ostatnim krokiem jest zgłoszenie sprawy do pomocy technicznej.

Tagi: Cloudflare, luki bezpieczeństwa, PHP, PHP2Shell, WordPress