Wydano pilne aktualizacje PHP po doniesieniach o próbach wykorzystania poważnych luk w zabezpieczeniach. Błędy mogą umożliwić zdalne wykonanie kodu na podatnych serwerach, dlatego twórcy PHP apelują o jak najszybsze zainstalowanie poprawek.
Dwie krytyczne luki w PHP
Biuletyn bezpieczeństwa PHP opisuje podatności CVE-2026-109618 i CVE-2026-109619. Pierwsza wiąże się z nieprawidłową obsługą braku pamięci, druga — z błędem typu use-after-free. Obie otrzymały ocenę 9,2 na 10, co oznacza krytyczny poziom zagrożenia.
Poprawki udostępniono w wersjach PHP 8.5.12, 8.4.27, 8.3.36 oraz 8.2.35. Użytkownicy powinni pobrać je z oficjalnej strony projektu albo sprawdzić dostępność aktualizacji u dostawcy swojej dystrybucji Linuxa lub usługi z długoterminowym wsparciem.
Ataki mogły rozpocząć się przed publikacją poprawek
Informacje o lukach pojawiły się w internecie jeszcze przed wydaniem aktualizacji. Według doniesień Reutersa część instytucji rządowych, placówek medycznych i szkół w Europie czasowo wyłączyła swoje strony, by ograniczyć ryzyko ataku.
Cloudflare informowało o zaobserwowaniu pierwszych prób wykorzystania podatności jeszcze przed udostępnieniem łatek. Firma zapowiedziała także aktualizowanie zabezpieczeń w miarę pojawiania się nowych sposobów ataku.
LastPass potwierdza wyciek danych po ataku na łańcuch dostaw — co o tym wiemy. To kolejny przykład zagrożeń, które wymagają szybkiego reagowania i aktualizowania zabezpieczeń.
Skala potencjalnego zagrożenia jest duża: według danych przywołanych przez BleepingComputer w VirusTotal widniało ponad 5,1 mln dostępnych z internetu hostów PHP. W przypadku około 3,8 mln wykryto co najmniej jeden otwarty port.
Administratorzy powinni potraktować te ostrzeżenia priorytetowo. Sama obecność podatnej wersji PHP może zwiększyć ryzyko przejęcia serwera. Warto sprawdzić wszystkie środowiska, także te utrzymywane przez zewnętrznych dostawców.
Szczególnie narażone są starsze instalacje
PHP wskazuje, że problem może dotyczyć serwerów korzystających z różnych konfiguracji, między innymi PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP oraz LiteSpeed. Szczególną ostrożność powinni zachować administratorzy używający mod_php — w tym przypadku atak może zostać uruchomiony nieuwierzytelnionym żądaniem, zanim zacznie działać kod aplikacji.
PHP 8.1 i starsze wersje nie otrzymają standardowych aktualizacji. Zespół projektu przygotował jednak ograniczone poprawki źródłowe dla PHP 7.4, 8.0 i 8.1 z myślą o osobach kompilujących oprogramowanie samodzielnie lub korzystających z dostawców LTS. Nie zastępuje to pełnej aktualizacji do wspieranej wersji.
Co zrobić, jeśli aktualizacja nie jest możliwa?
Najbezpieczniejszym rozwiązaniem pozostaje instalacja poprawionej wersji PHP. Jeśli administrator nie może zrobić tego od razu, może tymczasowo ograniczyć rozmiar przyjmowanych żądań i przesyłanych plików oraz ustawić odpowiednie limity pamięci. Pomocne może być również zastosowanie limitów kontenerów, aby ewentualny problem z jednym procesem nie wpłynął na cały system.
W przypadku drugiej luki PHP zaleca wyłączenie śledzenia postępu przesyłania plików w sesji. W PHP 8.5 można też włączyć śledzenie stosu dla błędów krytycznych. Warto ponadto usunąć błędy aplikacji prowadzące do awarii lub przekroczenia limitu czasu i sprawdzić ustawienia, które mogą generować komunikaty o błędach przed pełnym uruchomieniem aplikacji.
Twórcy PHP podkreślają, że takie działania ograniczają ryzyko, ale nie są pełnym rozwiązaniem problemu. Administratorzy powinni więc potraktować je jako środki przejściowe i zaktualizować system tak szybko, jak to możliwe.
[Przykład symulacyjny] Przy mod_php nie czekałbym na „dogodny moment” — aktualizacja i restart usług powinny być priorytetem. Warto też sprawdzić, czy pakiet z repozytorium faktycznie zawiera poprawkę.
[Przykład symulacyjny] Miliony hostów z PHP brzmią groźnie, ale sama liczba otwartych portów nie mówi, ile z nich jest podatnych. Przydałoby się rozróżnić serwery wystawione na internet od faktycznie zagrożonych konfiguracji.
[Przykład symulacyjny] Mam kilka serwisów na PHP-FPM za nginxem. Łatki już są w repozytoriach, ale przed wdrożeniem sprawdzam changelog i robię rolling restart. Ograniczenia requestów traktowałbym tylko jako pomost, nie naprawę.
[Przykład symulacyjny] Czy ktoś wie, jak szybko dostawcy hostingu współdzielonego zwykle wdrażają takie aktualizacje? Nie mam dostępu do systemu, a panel nadal pokazuje starą wersję.
[Przykład symulacyjny] Utrzymywanie PHP 8.1 bez wsparcia to proszenie się o kłopoty. Rozumiem legacy, ale jeśli aplikacja nie przechodzi aktualizacji od lat, to problem jest większy niż te dwie CVE.
[Przykład symulacyjny] Wyłączanie stron szkół i placówek medycznych brzmi jak ostrożność na wyrost, jeśli mają aktualny WAF. Ale bez informacji o konkretnych regułach i konfiguracji trudno oceniać decyzję.
[Przykład symulacyjny] Kontenery mogą ograniczyć skutki awarii procesu, ale nie zabezpieczą aplikacji przed wykonaniem kodu w jej uprawnieniach. Po aktualizacji sprawdziłbym logi i nietypowe procesy, zwłaszcza jeśli serwer był wystawiony przed publikacją łatek.