Projekt PHP wydał poprawki dwóch krytycznych podatności (CVSS 9.2), które pozwalają wykonać dowolny kod na serwerze bez logowania. Sprawdzę, jakiej wersji PHP używa Twoja strona, zaktualizuję ją albo przeniosę aplikację na PHP 8 i naprawię kod, który po zmianie przestał działać.
Diagnoza bez dostępu do serwera · 199 zł netto, odliczane od ceny naprawy
| Gałąź | Bezpieczna wersja | Stan |
|---|---|---|
| PHP 8.5 | 8.5.12 | Wydanie z poprawką |
| PHP 8.4 | 8.4.27 | Wydanie z poprawką |
| PHP 8.3 | 8.3.36 | Wydanie z poprawką |
| PHP 8.2 | 8.2.35 | Wsparcie kończy się 31.12.2026 |
| PHP 8.1 · 8.0 · 7.4 | Brak wydania | Tylko łatki w kodzie źródłowym |
| PHP 7.3 i starsze, PHP 5 | Brak poprawek | Migracja albo odcięcie od sieci |
Jak sprawdzić wersję na serwerze
php -v # wersja w konsoli
php-fpm8.3 -v # wersja PHP-FPM (nazwa zależy od systemu)Wersja w konsoli bywa inna niż ta, której używa strona. Pakiety Debiana, Ubuntu i RHEL dostają poprawki bez zmiany numeru wersji PHP — liczy się wersja pakietu.
Obie pozwalają na zdalne wykonanie kodu (RCE) bez uwierzytelnienia. Zagrożona jest każda instalacja PHP, która obsługuje żądania z internetu.
Gdy PHP zabraknie pamięci w trakcie obsługi żądania, część wewnętrznych danych zostaje zainicjalizowana tylko częściowo, a sprzątanie po żądaniu traktuje je jak poprawne.
Szczegóły techniczne (GitHub) ↗Wewnętrzny stan żądania może przetrwać zwolnienie pamięci. Kolejne żądanie obsługiwane przez ten sam proces może go użyć, zanim zostanie wyczyszczony.
Szczegóły techniczne (GitHub) ↗Kogo dotyczy
Według autorów PHP największe ryzyko dotyczy Apache z mod_php: pokazano atak, w którym żądanie bez logowania uruchamia exploit, zanim wykona się jakikolwiek kod aplikacji.
199 zł netto
Odliczam ją od ceny aktualizacji lub naprawy, jeśli ją zlecisz.
Raport mailem: co widać z internetu, prawdopodobna wersja PHP, lista ryzyk i to, co trzeba potwierdzić na serwerze.
Diagnozę wykonuję tylko na zlecenie właściciela strony lub osoby przez niego upoważnionej.
Pewną odpowiedź daje sprawdzenie z dostępem do serwera albo potwierdzenie od firmy hostingowej.
Własne aplikacje, sklepy i systemy CMS napisane w PHP — na Twoim serwerze, VPS albo hostingu.
Z dostępem przez SSH lub panel hostingu: ustalam, której wersji PHP faktycznie używa każda strona na serwerze (CLI, PHP-FPM i mod_php potrafią się różnić), skąd pochodzą pakiety i co trzeba zaktualizować.
Wdrażam wersję z poprawką (8.5.12, 8.4.27, 8.3.36, 8.2.35) z pakietów dystrybucji albo ze źródeł, restartuję wszystkie procesy PHP i sprawdzam, czy strona działa na nowej wersji.
Przenoszę aplikację na wspieraną wersję i poprawiam kod, który na PHP 8 przestaje działać: usunięte funkcje, zmiany w typach, stare biblioteki i rozszerzenia.
Biała strona, błąd 500 albo „Fatal error” po zmianie wersji PHP: znajduję przyczynę w logach i poprawiam kod, zamiast cofać serwer do podatnej wersji.
Gdy aktualizacja musi poczekać: ustawienia ograniczające ryzyko zalecane przez PHP, limity żądań w serwerze WWW i odcięcie aplikacji od publicznej sieci (VPN albo lista adresów IP).
Gdy migracja wymaga czasu: kompilacja PHP z łatkami źródłowymi udostępnionymi przez zespół bezpieczeństwa PHP. To rozwiązanie przejściowe, nie zamiennik migracji.
Diagnoza z zewnątrz: 199 zł netto. Pozostałe usługi wyceniam po sprawdzeniu wersji PHP, sposobu uruchomienia i kodu aplikacji.
PHP zaleca te ustawienia, gdy aktualizacji nie da się wdrożyć od ręki. Zamykają znane ścieżki ataku, ale według autorów PHP nie czynią instalacji bezpieczną — pełnym rozwiązaniem jest tylko aktualizacja.
Aplikacje, których nie da się szybko zaktualizować, warto do czasu wdrożenia poprawek odciąć od publicznej sieci: dostęp tylko przez VPN albo z listy adresów IP.
memory_limit = -1Ustaw przez php_admin_value w puli FPM lub konfiguracji Apache, tak żeby aplikacja nie mogła tego nadpisać. Pamięć ogranicz kontenerem lub cgroup, nie przez RLIMIT_AS ani RLIMIT_DATA.
post_max_size = 8M32M, jeśli strona przyjmuje pliki. upload_max_filesize ustaw poniżej post_max_size. Dodatkowo ogranicz rozmiar i złożoność żądań w serwerze WWW lub proxy.
session.upload_progress.enabled = 0W php.ini, puli FPM lub konfiguracji serwera, a potem restart wszystkich procesów PHP. ini_set() i .user.ini nie wystarczą.
fatal_error_backtraces = 0Tylko PHP 8.5, także z restartem wszystkich procesów.
Dostęp przez SSH albo panel hostingu. Spisuję wersje PHP, sposób uruchomienia i strony działające na serwerze.
Kopia plików i bazy danych. Decyzja: aktualizacja w tej samej gałęzi, migracja na PHP 8 czy zabezpieczenie przejściowe.
Wdrażam wersję z poprawką i restartuję procesy PHP. Migrację i poprawki kodu sprawdzam najpierw na kopii strony.
Testuję działanie strony, przeglądam logi błędów i potwierdzam wersję PHP, której używa strona. Dostajesz opis zmian.
Po aktualizacji mogę zająć się dalszym utrzymaniem serwera: kopiami zapasowymi, aktualizacjami systemu i certyfikatami TLS. Jeśli stara strona nie nadaje się do migracji, mogę ją przebudować.
Według komunikatu PHP zagrożona jest każda instalacja PHP obsługująca żądania z internetu: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Poprawki zawierają wersje 8.5.12, 8.4.27, 8.3.36, 8.2.35. Największe ryzyko dotyczy mod_php — pokazano dla niego atak, który działa bez logowania, zanim uruchomi się kod aplikacji.
Najprościej w panelu hostingu albo poleceniem php -v na serwerze. Uwaga: wersja w konsoli może być inna niż ta, której używa strona przez PHP-FPM lub Apache. Jeśli PHP pochodzi z pakietów dystrybucji (Debian, Ubuntu, RHEL), numer wersji może wyglądać na stary mimo wgranej poprawki — wtedy liczy się wersja pakietu i komunikat bezpieczeństwa dystrybucji.
Tak, częściowo. Diagnoza PHP z zewnątrz (199 zł netto, odliczana od ceny naprawy) pokazuje, czy strona działa na PHP, czy widać jej wersję i jakie ryzyka są widoczne z internetu. Nie potwierdzi jednak, czy poprawka jest wgrana, bo pakiety dystrybucji dostają poprawki bez zmiany numeru wersji. Pewną odpowiedź daje sprawdzenie z dostępem do serwera albo potwierdzenie od firmy hostingowej.
Projekt PHP nie wydaje już poprawek dla wersji 8.1 i starszych. Dla PHP 7.4, 8.0 i 8.1 zespół bezpieczeństwa udostępnił tylko łatki w kodzie źródłowym, które trzeba samodzielnie skompilować. Dla starszych wersji, w tym PHP 5, poprawek nie ma. Docelowo aplikację trzeba przenieść na PHP 8.3 lub nowsze (PHP 8.2 traci wsparcie 31 grudnia 2026), a do tego czasu ograniczyć do niej dostęp z internetu.
Nie. Zalecane przez PHP ustawienia (memory_limit, post_max_size, session.upload_progress.enabled) blokują znane ścieżki ataku, ale według autorów PHP nie czynią instalacji bezpieczną. Pełnym rozwiązaniem jest tylko aktualizacja. Ustawienia traktuj jako zabezpieczenie na czas, zanim aktualizacja zostanie wdrożona.
Samo PHP aktualizuje firma hostingowa; w panelu zwykle wybierasz tylko gałąź, np. 8.3. Jeśli strona działa na starej gałęzi, bo na nowszej przestaje działać, trzeba poprawić jej kod — tym się zajmuję.
Aktualizacja w obrębie tej samej gałęzi (np. z 8.3.20 do 8.3.36) zwykle nie wymaga zmian w kodzie. Przejście między gałęziami (np. z 7.4 na 8.3) to migracja i część starego kodu trzeba poprawić. Przed zmianą robię kopię, a migrację sprawdzam najpierw na kopii strony.
Według komunikatu PHP repozytorium rpms.remirepo.net nie miało poprawek w dniu publikacji. PHP zaleca przejście na pakiety dystrybucji albo kompilację ze źródeł, żeby móc od razu wgrać aktualizację. Sprawdź, czy Twój pakiet ma już poprawkę.
Diagnoza z zewnątrz kosztuje 199 zł netto i odliczam ją od ceny aktualizacji lub naprawy. Pełne sprawdzenie serwera, aktualizację i migrację wyceniam po sprawdzeniu wersji PHP, sposobu uruchomienia i kodu aplikacji.
Napisz, jakiej wersji PHP używasz (jeśli wiesz), czy strona stoi na hostingu, czy na własnym serwerze, i na czym jest zbudowana. Odpowiem, co trzeba zrobić.