Dwa dni po publikacji poprawek
21 października pisaliśmy o dwóch krytycznych podatnościach w rdzeniu PHP, oznaczonych jako CVE-2026-109618 i CVE-2026-109619 i opisywanych wspólnie jako php2shell (Krytyczne podatności w PHP Core. Czas na pilną aktualizację). Obie mają ocenę 9,2 w skali CVSS v4.0 i pozwalają zdalnie wykonać kod na serwerze, bez logowania. Według CERT Polska dotyczą wszystkich wersji PHP od 5.4 wzwyż.
Luki wykrył zespół Wiz Research. Firma pisze, że w poszukiwaniach pomagała jej sztuczna inteligencja - własne narzędzie Wiz Atlas oraz modele Gemini 4 Argon i GPT-5.6 Sol. Wiz zgłosił problem twórcom PHP 24 sierpnia, a poprawione wydania ukazały się 21 października.
Sprawa szybko dotarła do administracji publicznej. 22 października Centralny Ośrodek Informatyki czasowo wyłączył strony Biuletynu Informacji Publicznej działające w systemie SSDIP. Wicepremier i minister cyfryzacji Krzysztof Gawkowski przekazał, że "został przygotowany plan działań, który obecnie jest wdrażany". Wyłączenie nie objęło wszystkich stron BIP w Polsce, a dostęp do opublikowanych informacji wracał etapami jeszcze tego samego dnia.
Poprawki są dostępne od 21 października. Pozostało pytanie, ile polskich stron rzeczywiście je wdroży, a ile wciąż działa na wersjach, które nigdy ich nie dostaną. Odpowiedź przyniosło niezależne badanie.
Ponad 10 tysięcy serwisów pod lupą
Tomasz Bramson z Instytutu Dostępności Cyfrowej przeskanował ponad 10 tysięcy polskich serwisów internetowych. Sprawdzał wersję PHP i podatność na php2shell. Wyniki opisał we wpisie na LinkedIn. Sam podsumowuje je krótko: "Statystyki nie wyglądają najlepiej".
Według jego ustaleń co piąty serwis z PHP działa na wersji podatnej na php2shell według oficjalnych progów poprawek.
Aż 424 serwisy działają na gałęziach End of Life, czyli PHP 8.1 i starszych. Twórcy PHP nie wydadzą dla nich już żadnej regularnej poprawki. W tej grupie 130 stron działa na PHP 5.x lub starszym, a 211 na gałęzi 7.x.
Najbardziej niepokojąca jest inna liczba. W przypadku 116 serwisów sonda realnie uruchomiła podatną ścieżkę kodu, bez logowania. To strony, które w praktyce mają otwarte drzwi dla atakującego.
Rekordzista działa na PHP 4.4.8. Gałąź 4.4 straciła wsparcie 7 sierpnia 2008 roku, czyli 18 lat temu. Sam php2shell według CERT Polska dotyczy wersji od 5.4 wzwyż, więc PHP 4 formalnie nie mieści się w jego zakresie. To jednak słabe pocieszenie - taki serwer od 18 lat nie dostał żadnej poprawki bezpieczeństwa.
Urzędy, instytuty, sklepy, firmy IT
Na liście serwisów podatnych na atak znalazły się publiczne instytuty, urzędy, firmy z sektora programistycznego i gamingowego, sklepy internetowe i wiele innych.
Bramson świadomie zrezygnował z publikowania nazw. W pierwszej wersji wpisu chciał wymienić wybrane serwisy, ale ostatecznie tego nie zrobił. To rozsądna decyzja, bo lista podatnych stron w rękach atakujących byłaby gotowym celownikiem.
Problem na lata
"Mam wrażenie, że ten problem będzie ciągnął się jeszcze latami" - pisze Bramson.
Trudno się z tym nie zgodzić. Strona na PHP 4 czy PHP 5 to zwykle system, o którym ktoś zapomniał. Często stoi na starym serwerze, jej autor dawno nie współpracuje z firmą, a aktualizacja PHP wymagałaby przepisania aplikacji. Takie serwisy nie zostaną załatane w tydzień. Część z nich nie zostanie załatana nigdy.
Podobny obraz widać w skali świata. Firma Bitsight, która analizuje serwery dostępne z internetu, podaje, że tylko około jednej trzeciej instancji PHP o rozpoznanej wersji działa na gałęziach objętych poprawkami, czyli 8.2-8.5. Najczęściej spotykaną gałęzią jest PHP 7.4 - Bitsight naliczył ponad 2 mln takich obserwacji.
Skala problemu jest globalna. Wiz Research przypomina, że PHP obsługuje około 70 procent stron internetowych na świecie. Szczegóły luk wyciekły przed planowaną publikacją, a Cloudflare informował o ruchu atakującym swoich klientów jeszcze przed wydaniem poprawek. Firma wdrożyła reguły WAF blokujące znane metody ataku, także w darmowym planie.
Co powinni zrobić właściciele stron
Najważniejsza jest aktualizacja do wydań z poprawkami: PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. CERT Polska podkreśla w komunikacie, że "w pełni zabezpiecza jedynie aktualizacja PHP do bezpiecznej wersji". Do czasu aktualizacji zespół zaleca tymczasowe zmiany w konfiguracji PHP, które ograniczają ryzyko pierwszej fali ataków, ale go nie eliminują. Administratorzy powinni też sprawdzić, czy na serwerze nie ma śladów włamania. Incydenty można zgłaszać przez incydent.cert.pl.
Właściciele stron na PHP 8.1 i starszym powinni zaplanować migrację na wspieraną wersję. Zespół PHP przygotował wprawdzie minimalne poprawki źródłowe dla gałęzi 7.4, 8.0 i 8.1, ale są one przeznaczone dla osób, które same kompilują PHP. Część dystrybucji Linuksa i dostawców wsparcia LTS udostępnia też własne łatki, dlatego warto zapytać o nie hostingodawcę.
CERT-EU zaleca, by tam, gdzie natychmiastowa aktualizacja nie jest możliwa, rozważyć odizolowanie aplikacji od sieci publicznej do czasu wdrożenia poprawki.
Reguły WAF i inne obejścia dają tylko czas. Nawet Cloudflare zaleca klientom aktualizację PHP mimo ochrony WAF, bo luki tkwią w samym środowisku PHP, a nie w kodzie strony. Jedyną trwałą ochroną jest aktualizacja.
Następny w kolejce Node.js?
Bramson zwraca uwagę, że w tym samym czasie opublikowano także podatności w Node.js. Tego środowiska jeszcze nie sprawdzał, ale nie wyklucza kolejnego skanu.
Pełny raport z badania - wkrótce.