Dwie dziury w PHP na 9,2 punktu: co to znaczy dla firmy i ile kosztuje zwłoka

21 października 2026 roku zespół PHP wydał nadzwyczajne aktualizacje, a europejski zespół reagowania na incydenty komputerowe CERT-EU opublikował pilne ostrzeżenie. Dwie luki z oceną zagrożenia 9,2 na 10 pozwalają napastnikowi uruchomić własny kod na serwerze — bez loginu, bez hasła i bez żadnego działania ze strony pracowników firmy.

Dla firmy to nie abstrakcyjna wiadomość techniczna. PHP to język, w którym napisana jest większość stron: WordPress, Joomla, OpenCart, Bitrix, Laravel, a do tego setki własnych skryptów, którymi stronę łączy się z CRM, pocztą czy 1C. Jeśli Państwa firma ma stronę, sklep internetowy albo panel klienta — pytanie jest tylko o to, czy zdążyli Państwo zaktualizować, czy nie.

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.

Ile to kosztuje firmę

Nikt nie szuka Państwa firmy osobno. Kiedy przykłady wykorzystania luki stają się publiczne — a są już 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 strona zakładu fryzjerskiego: liczy się tylko to, czy serwer odpowiada podatną wersją.

Potem zaczyna się to, co liczy się w pieniądzach. Na serwer wgrywany jest webshell, strona rozsyła spam albo obcą reklamę, domena trafia na czarne listy — i poczta z niej przestaje dochodzić do klientów i partnerów. Sklep w tym czasie nie sprzedaje, handlowcy nie dostają zapytań, a wyszukiwarki zdążą oznaczyć stronę jako niebezpieczną. Odzyskanie sprawności to nie jedna noc pracy, lecz czyszczenie, ponowne wydanie kluczy, zmiana haseł i wyprowadzanie domeny z czarnych list, które trwa tygodniami.

Osobnym ryzykiem są dane. Jeśli na serwerze leży baza klientów albo historia zamówień, ich wyciek oznacza również pytania do firmy ze strony klientów i regulatora, a nie tylko incydent techniczny.

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 w Państwa firmie nie ma osoby odpowiedzialnej za wersje i aktualizacje na serwerze, audyt można zamówić na zewnątrz — na przykład w SmartGT: sprawdzą zasoby i powiedzą wprost, czy jest zagrożenie i co z nim zrobić.

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