Krytyczne luki w PHP: sprawdźcie stronę swojej firmy lub inicjatywy

Wielu weteranów po służbie otwiera własną działalność, bierze się za projekt społeczny albo uruchamia inicjatywę edukacyjną — i niemal zawsze w którymś momencie pojawia się strona. Zrobiono ją zwykle na WordPress: szybko, niedrogo, często rękami znajomego albo freelancera, z którym dawno nie było kontaktu.

21 października 2026 roku zespół PHP wydał nadzwyczajne aktualizacje, a europejski zespół reagowania na incydenty komputerowe CERT-EU opublikował pilne ostrzeżenie. Powód to dwie luki z oceną zagrożenia 9,2 na 10, które pozwalają napastnikowi wykonać własny kod na waszym serwerze. Bez loginu, bez hasła, bez żadnego działania z waszej strony.

Poniżej — bez zbędnego języka technicznego: co się stało, dlaczego dotyczy to nawet najmniejszej strony i jakie trzy zdania warto napisać swojemu hostingowi już dziś.

Co dokładnie znaleziono

Luk jest dwie, obie ocenione na 9,2 punktu i obie prowadzą do tego samego skutku — wykonania obcego kodu na serwerze bez autoryzacji.

CVE-2026-109618 — awaria przy braku pamięci

W PHP jest ustawienie memory_limit: żądanie, które zużyło zbyt wiele pamięci, jest przerywane siłowo. Problem polega na tym, jak dokładnie zostaje przerwane. PHP może urwać się w momencie, gdy wewnętrzne dane żądania są wypełnione tylko do połowy — na przykład w trakcie analizy pliku przesłanego przez formularz wysyłania. Porządkowanie po takim żądaniu bierze niedokończone dane za prawdziwe i próbuje zwolnić pamięć, której nigdy nie było. A w tej pamięci może leżeć to, co napastnik umieścił tam wcześniejszymi żądaniami.

CVE-2026-109619 — pozostałości poprzedniego żądania

Druga dziura dotyczy tego, że serwer nie do końca „zapomina” poprzedniego odwiedzającego. Stan wewnętrzny, który należał do jednego żądania, czasem przeżywa zwolnienie pamięci — powiedzmy po błędzie krytycznym. Następne żądanie, które trafiło do tego samego procesu roboczego, zdąży skorzystać z tych pozostałości, zanim zwykła inicjalizacja je wyzeruje.

Zagrożona jest każda instalacja PHP obsługująca żądania sieciowe: PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP, LiteSpeed. Za najbardziej ryzykowne zespół PHP uznaje właśnie połączenie Apache z mod_php — jest ono do dziś standardem na wielu tanich hostingach.

Demonstracyjny exploit działa jednym jedynym nieuwierzytelnionym żądaniem — jeszcze przed tym, jak zacznie wykonywać się kod samej strony. Czyli nie pomogą tu ani wtyczki bezpieczeństwa, ani skomplikowane hasła, ani uwierzytelnianie dwuskładnikowe: atak odbywa się o poziom niżej.

Które wersje są zagrożone

Wszystko, co jest niższe od tych wersji, jest podatne:

Gałąź PHP	Bezpieczna wersja
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 i starsze	brak wsparcia

Osobną kategorią ryzyka są produkty komercyjne i otwarte, wewnątrz których PHP jest wbudowany, choć z zewnątrz tego nie widać: panele zarządzania, urządzenia sieciowe, systemy monitoringu wideo, portale korporacyjne. Spis takiego oprogramowania prowadzi repozytorium niderlandzkiego NCSC.

Dlaczego „mam małą stronę” tu nie ratuje

Nikt nie szuka waszej strony osobno. Kiedy przykłady włamania stają się publiczne — a już są publiczne — w ciągu kilku godzin ruszają automatyczne skanery, które przeczesują cały internet po kolei. Jest im obojętne, czy to strona dużej firmy, czy strona warsztatu z pięcioma usługami: liczy się tylko to, czy serwer odpowiada podatną wersją.

Dalej scenariusz jest typowy: na serwer wrzucany jest obcy kod, strona zaczyna rozsyłać spam albo pokazywać strony obcych reklam, domena trafia na czarne listy, a poczta z niej przestaje dochodzić do klientów. Dla niewielkiej działalności to boli podwójnie: strona często jest jedyną witryną, a na przywrócenie idą tygodnie i pieniądze, których nie planowano.

Osobno przestrzegamy przed tym, co zwykle idzie w parze. Po takich wiadomościach aktywizują się „fachowcy”, którzy sami piszą do właścicieli stron: „macie lukę, pilnie dajcie dostępy”. Dostępy do strony i hostingu przekazujcie tylko temu, kogo znacie i komu płacicie za obsługę.

Co robić — krok po kroku

1. Proszę sprawdzić swoją wersję. W panelu hostingu to sekcja „Wersja PHP” lub „PHP Selector”; na własnym serwerze — polecenie php -v. Ważne jest sprawdzenie wersji, na której pracuje sama strona, a nie tej, która stoi w wierszu poleceń: często się różnią.
2. Proszę zaktualizować w ramach swojej gałęzi. Przejście z 8.2.29 na 8.2.35 to poprawka wewnątrz jednej gałęzi: zgodność zostaje zachowana, strona od tego się nie psuje. Nie należy tego mylić z przejściem z 8.2 na 8.4 — ono już wymaga sprawdzenia.
3. Jeśli mają Państwo 8.1 lub starszą — te gałęzie nie mają wsparcia. Z powodu powagi sytuacji zespół bezpieczeństwa PHP wydał minimalne poprawki także dla 7.4, 8.0 i 8.1, a część hostingów utrzymuje własne kompilacje. Właściwym rozwiązaniem jest jednak przeniesienie się na wspieraną gałąź, a lepiej zaplanować je teraz niż następnym razem.
4. Proszę zrestartować moduły obsługi. Bez restartu php-fpm lub Apache procesy robocze dalej pracują na starym kodzie i aktualizacja faktycznie nie działa.
5. Proszę sprawdzić wynik. Najprościej — tymczasowa strona z phpinfo(), którą zaraz po sprawdzeniu trzeba usunąć, albo sekcja „Wersja PHP” w panelu po restarcie.

Użytkownicy hostingu najczęściej nie będą musieli robić niczego ręcznie: duzi dostawcy dostali poprawki z wyprzedzeniem i sami aktualizują swoje maszyny. Warto napisać do wsparcia jedną linijkę — „czy PHP zostało zaktualizowane do wersji z 21 października 2026” — i dostać odpowiedź na piśmie.

Jeśli aktualizacja od razu nie jest możliwa

Bywa, że strona jest stara, a aktualizacja wymaga przygotowania. Wtedy są środki tymczasowe, które zwężają okno do ataku:

• zablokować przepełnienie pamięci jako punkt wejścia: memory_limit=-1, ustawiony tak, by aplikacja nie mogła tego nadpisać, oraz sprawdzenie, że żadna pula ani katalog nie przywraca limitu;
• zmniejszyć post_max_size — 8M dla stron bez wysyłania plików, 32M jeśli wysyłanie jest potrzebne, a upload_max_filesize trzymać niżej;
• wyłączyć session.upload_progress.enabled i zrestartować wszystkie procesy robocze;
• na PHP 8.5 dodatkowo wyłączyć fatal_error_backtraces;
• ograniczyć rozmiar i złożoność żądań na poziomie serwera WWW lub proxy.

Żaden z tych środków nie czyni instalacji bezpieczną. Zamykają one tylko znane drogi — całkowicie problem zamyka wyłącznie aktualizacja.

Jeśli i to jest niemożliwe, CERT-EU doradza proste i niepopularne rozwiązanie: usunąć podatną usługę z publicznego internetu, dopóki poprawka nie zostanie zainstalowana i sprawdzona.

Skąd te dane

• CERT-EU, Security Advisory 2026-018 „Critical Vulnerabilities in PHP”
• Ogłoszenie o wydaniu aktualizacji na php.net
• Techniczny opis CVE-2026-109618 i CVE-2026-109619

---

Jeśli nie wiecie, na czym zrobiona jest wasza strona i kto za nią odpowiada, to już powód, by to wyjaśnić, nie czekając na kolejną wiadomość. Sprawdzenie można zlecić także firmie SmartGT, zespołowi, który utrzymuje cyfrowe zasoby klastra.

Autor materiału — SmartGT. Źródło pierwotne: „Krytyczne luki w PHP: aktualizacji nie można odkładać”.