Krytyczne podatności PHP: aktualizacji nie można odkładać

21 października 2026 roku zespół PHP wydał nadzwyczajne aktualizacje, a Europejski Zespół Reagowania na Incydenty Cybernetyczne CERT-EU opublikował pilne ostrzeżenie. Powód — dwie podatności o ocenie zagrożenia 9,2 na 10, które pozwalają atakującemu wykonać własny kod na Państwa serwerze. Bez loginu, bez hasła, bez jakiegokolwiek działania ze strony Państwa pracowników.

PHP to język, w którym napisana jest większość stron w internecie: WordPress, Joomla, OpenCart, Bitrix, Laravel, a także setki własnoręcznie napisanych skryptów, którymi strona jest połączona z CRM, pocztą czy programem „1C”. Jeśli Państwa strona nie działa na PHP — ten artykuł można zamknąć. Jeśli nie wiedzą Państwo, na czym działa — to już powód, by zapytać osobę, która się nią opiekuje.

Co dokładnie znaleziono

Podatności są dwie, obie ocenione na 9,2 punktu i obie prowadzą do tego samego skutku — wykonania cudzego kodu na serwerze bez autoryzacji.

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

PHP ma ustawienie memory_limit: żądanie, które zużyło za dużo pamięci, jest przerywane siłą. Problem w tym, jak dokładnie jest przerywane. PHP może się zatrzymać w chwili, gdy wewnętrzne dane żądania są wypełnione tylko w połowie — na przykład w trakcie przetwarzania pliku przesłanego przez formularz. Sprzątanie 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 atakujący umieścił tam poprzednimi żądaniami.

CVE-2026-109619 — pozostałości po poprzednim żądaniu

Druga luka 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 — na przykład po błędzie krytycznym. Kolejne żądanie, które trafi do tego samego procesu roboczego, zdąży wykorzystać te pozostałości, zanim zwykła inicjalizacja je wyzeruje.

Zagrożona jest każda instalacja PHP obsługująca żądania webowe: 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 — wciąż jest ono standardem u wielu tanich hostingodawców.

Demonstracyjny exploit działa za pomocą jednego jedynego nieuwierzytelnionego żądania — jeszcze zanim zacznie się wykonywać kod samej strony. Czyli ani wtyczki bezpieczeństwa, ani skomplikowane hasła, ani uwierzytelnianie dwuskładnikowe tu nie pomogą: atak odbywa się poziom niżej.

Które wersje są zagrożone

Wszystko poniżej 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

Osobna kategoria ryzyka — produkty komercyjne i otwarte, w których PHP jest wbudowany, choć z zewnątrz tego nie widać: panele zarządzania, urządzenia sieciowe, systemy monitoringu wizyjnego, portale korporacyjne. Listę takiego oprogramowania prowadzi repozytorium holenderskiego NCSC.

Dlaczego „mamy małą stronę” tu nie działa

Nikt nie szuka akurat Państwa strony. Gdy przykłady wykorzystania luki stają się publiczne — a już są publiczne — w ciągu kilku godzin uruchamiają się automatyczne skanery, które przeczesują cały internet po kolei. Jest im obojętne, czy to strona fabryki, czy salonu fryzjerskiego: liczy się tylko, czy serwer odpowiada podatną wersją.

Dalej scenariusz jest typowy: na serwer wgrywany jest webshell, strona zaczyna rozsyłać spam albo wyświetlać cudzą reklamę, domena trafia na czarne listy, a poczta z niej przestaje dochodzić. Stratę liczy przy tym nie ten, kto włamał się na stronę, lecz ten, komu strona jest potrzebna do pracy.

Co robić — krok po kroku

1. Proszę sprawdzić swoją wersję. W panelu hostingu jest to sekcja „Wersja PHP” lub „PHP Selector”; na własnym serwerze — polecenie php -v. Ważne, by sprawdzić wersję, na której działa właśnie strona, a nie tę, która jest w wierszu poleceń: często są różne.
2. Proszę zaktualizować w obrębie swojej gałęzi. Przejście z 8.2.29 na 8.2.35 to poprawka wewnątrz jednej gałęzi: zgodność zostaje zachowana, strona się od tego nie psuje. Nie należy tego mylić z przejściem z 8.2 na 8.4 — to już wymaga sprawdzenia.
3. Jeśli mają Państwo 8.1 lub starszą — te gałęzie nie są już wspierane. Ze względu na powagę sytuacji zespół bezpieczeństwa PHP wydał minimalne poprawki także dla 7.4, 8.0 i 8.1, a część hostingodawców utrzymuje własne kompilacje. Ale właściwym rozwiązaniem jest przejście na wspieraną gałąź i lepiej zaplanować je teraz, a nie przy następnej okazji.
4. Proszę zrestartować procesy obsługi. Bez restartu php-fpm czy Apache procesy robocze nadal działają na starym kodzie i aktualizacja w praktyce 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 ponownym uruchomieniu.

Użytkownikom hostingu najczęściej nie trzeba nic robić ręcznie: więksi dostawcy otrzymali poprawki z wyprzedzeniem i aktualizują swoje maszyny sami. Warto napisać do wsparcia jedną linijkę — „czy PHP zaktualizowano do wersji z 21 października 2026” — i otrzymać odpowiedź na piśmie.

Jeśli nie da się zaktualizować od razu

Zdarza się, że strona jest stara, a aktualizacja wymaga przygotowania. Wtedy istnieją środki tymczasowe, które zawężają okno dla ataku:

• zablokować przepełnienie pamięci jako punkt wejścia: memory_limit=-1, ustawione 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 wgrywania plików, 32M jeśli wgrywanie jest potrzebne, a upload_max_filesize utrzymywać 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 ścieżki — całkowicie problem rozwiązuje wyłącznie aktualizacja.

Jeśli i to jest niemożliwe, CERT-EU zaleca proste i niepopularne rozwiązanie: wyłączyć 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
• Opis techniczny CVE-2026-109618 i CVE-2026-109619

---

Nie wiedzą Państwo, jaka wersja PHP działa na Państwa stronie i kto ma ją aktualizować? Proszę napisać do nas — sprawdzimy Państwa zasoby i powiemy wprost, czy jest zagrożenie i co z nim zrobić.