CVE-2026-109618 i CVE-2026-109619: analiza dwóch krytycznych luk w PHP i porządek reagowania

21 października 2026 roku zespół PHP wydał nadzwyczajne aktualizacje, a europejski zespół reagowania na incydenty komputerowe CERT-EU opublikował pilne ostrzeżenie. Obie luki oceniono na 9,2 punktu i pozwalają wykonać dowolny kod na serwerze bez uwierzytelnienia.

Ponieważ PHP pozostaje najbardziej rozpowszechnionym językiem warstwy serwerowej sieci — działają na nim WordPress, Joomla, OpenCart, Bitrix, Laravel oraz znaczna liczba samodzielnie pisanych integracji z CRM i systemami księgowymi — krąg objętych systemów obejmuje większość organizacji z własnym zasobem internetowym, w tym instytucje naukowe i analityczne.

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.

Ocena ryzyka dla instytucji

Kluczową cechą tego przypadku jest brak potrzeby ukierunkowanego ataku. Po opublikowaniu przykładów eksploatacji masowe skanowanie przestrzeni adresowej rozpoczyna się w ciągu godzin i nie rozróżnia typów organizacji: jedynym kryterium wyboru jest wersja, którą odpowiada serwer.

Dla instytucji naukowych i analitycznych do typowych następstw (umieszczenie web shella, rozsyłanie spamu, trafienie domeny na czarne listy, utrata dostarczalności poczty) dochodzą dwa specyficzne. Pierwsze to integralność danych: zbiory badawcze, dokumenty normatywne i wyniki badań ankietowych umieszczone na tym samym serwerze stają się dostępne do zmiany, a podmianę liczb w publikacji wykrywa się z dużym opóźnieniem. Drugie jest reputacyjne: materiał opublikowany w imieniu instytucji odbierany jest jako jej oficjalne stanowisko.

Oceniając własne ryzyko, warto uwzględnić także systemy, w których PHP występuje niejawnie: panele zarządzania sprzętem, urządzenia sieciowe, systemy wideonadzoru i portale wewnętrzne. Rzadko trafiają one na listę zasobów podlegających aktualizacji.

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

---

Zewnętrzny audyt perymetru i sprawdzenie wersji można zamówić m.in. w SmartGT — zespołu, który opiekuje się zasobami cyfrowymi organizacji partnerskich.

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