Krytyczne luki w PHP (CVE-2026-109618 i CVE-2026-109619): co się stało i co zrobić

W dniu 21 października 2026 r. projekt PHP wydał poprawki do dwóch krytycznych luk, a CERT-EU opublikował tego samego dnia ostrzeżenie 2026-018. Obie luki są oceniane na 9,2 i obie opisano jako zdalne wykonanie kodu bez uwierzytelnienia. Jeśli prowadzą Państwo stronę na WordPressie, sklep lub jakąkolwiek inną aplikację PHP, sprawa dotyczy Państwa, a rozwiązaniem jest aktualizacja, nie żadne ustawienie. Artykuł wyjaśnia, co wiadomo, jak atak dociera do celu i co należy zrobić. Stan na 22 października 2026 r., na podstawie wersji 1.1 ostrzeżenia CERT-EU.

Co się stało

PHP zapowiedział wydanie bezpieczeństwa 20 października, a poprawki opublikował 21 października o 13:30 UTC. CERT-EU zatytułował swoje ostrzeżenie „Critical Vulnerabilities in PHP” i wymienia dwa numery CVE: CVE-2026-109618 oraz CVE-2026-109619, każdy z oceną 9,2. CERT-EU pisze też, że szczegóły techniczne są już publicznie omawiane, a pierwszy kod proof-of-concept zaczął krążyć. Ostrzeżenie nie potwierdza ataków w sieci, ale stwierdza, że przez to jest bardziej prawdopodobne, iż atakujący już te luki wykorzystują. Należy traktować sprawę jako pilną.

Kogo to dotyczy

Dotknięta jest każda wersja PHP niższa od poprawionej w wspieranej gałęzi oraz każda gałąź, której wsparcie wygasło.

CERT-EU wymienia PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Według zespołu PHP największe ryzyko niesie mod_php. Dotknięte mogą być także produkty, które osadzają PHP; CERT-EU odsyła do listy holenderskiego NCSC na końcu tego artykułu. Liczy się każda instalacja obsługująca żądania sieciowe, niezależnie od tego, czy ma formularz przesyłania plików.

Jak atakujący dociera do pierwszej luki

Nikt nie musi się logować. Według CERT-EU wykazany exploit pokazuje, że pojedyncze żądanie bez uwierzytelnienia może wywołać atak, zanim uruchomi się jakikolwiek kod aplikacji. To punkt, który większość osób pomija: nie ma znaczenia, czy Państwa WordPress jest aktualny, czy wtyczki są załatane i czy formularz kontaktowy jest chroniony. Żądanie najpierw trafia do silnika PHP.

Pierwsza luka, CVE-2026-109618, działa tak:

1. Żądanie przychodzi na adres obsługiwany przez PHP. Bez logowania, bez konta.
2. PHP zaczyna czytać treść żądania. CERT-EU podaje jako przykład analizę przesyłania plików przez formularz.
3. PHP egzekwuje swój memory_limit za pomocą longjmp(). Gdy limit zostanie przekroczony, przeskakuje z tego, co robił, i kończy żądanie.
4. Jeśli stanie się to w trakcie przygotowywania wewnętrznych danych żądania, dane te są zbudowane tylko w połowie.
5. Późniejsze sprzątanie traktuje nieprawidłowe dane jako prawidłowe i zwalnia pamięć, która nigdy nie została zainicjowana. Pamięć ta może nadal zawierać dane z wcześniejszych alokacji, nad którymi atakujący miał kontrolę.
6. Stąd ostrzeżenie opisuje zdalne wykonanie kodu na serwerze.

Celowo nie opisujemy, jak atakujący kieruje ostatnim krokiem. Wystarczy wiedzieć, że punktem wejścia nie jest Państwa aplikacja, i dlatego nic wewnątrz aplikacji nie może tego zatrzymać.

Druga luka: stan, który przeżywa swoją pamięć

CVE-2026-109619 to inny mechanizm o tym samym skutku. PHP przechowuje wewnętrzny stan dla każdego żądania. Po niektórych błędach, na przykład błędzie krytycznym, stan ten może pozostać, mimo że leżąca pod nim pamięć została zwolniona. Kolejne żądanie obsłużone przez ten sam proces roboczy może wtedy użyć tego nieaktualnego stanu, zanim zostanie on zwykłym trybem zresetowany. Atakujący potrzebuje dwóch żądań trafiających do tego samego procesu roboczego; CERT-EU ocenia skutek tak samo jak w pierwszej luce: zdalne wykonanie kodu.

Co zrobić dziś

1. Ustalić, jaka wersja PHP faktycznie obsługuje Państwa stronę. php -v w wierszu poleceń pokazuje wersję wiersza poleceń, która może różnić się od tej, której używa serwer WWW. Proszę sprawdzić php-fpm -v, panel hostingu lub stronę wywołującą phpinfo(). W hostingu współdzielonym należy zapytać dostawcę.
2. Zaktualizować do poprawionej wersji: 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. Dystrybucje często przenoszą poprawki bez zmiany numeru wersji, dlatego w komunikacie bezpieczeństwa dostawcy należy szukać numerów CVE. W kontenerach należy zbudować obraz ponownie z zaktualizowanego obrazu bazowego. Zespół PHP zaznacza, że rpms.remirepo.net w dniu wydania nie miał aktualizacji, i zaleca pakiety dystrybucji lub kompilację ze źródeł.
3. Uruchomić ponownie wszystkie procesy robocze PHP. Aktualizacja na dysku nie zmienia procesów, które już działają. Należy zrestartować PHP-FPM lub serwer WWW, a następnie ponownie sprawdzić działającą wersję.
4. Jeśli nie można zaktualizować dziś, odizolować serwer od sieci publicznych, aż poprawka zostanie wdrożona i sprawdzona. CERT-EU wyraźnie stwierdza, że te luki w pełni usuwa tylko aktualizacja.
5. Jeśli używają Państwo PHP 8.1 lub starszego, należy poprosić dostawcę o backport albo przejść na wspieraną gałąź. Te wersje nie otrzymują regularnych aktualizacji.

Obejścia, które zmniejszają ryzyko, ale nie usuwają luki

CERT-EU wymienia środki, które utrudniają atak. Wprost stwierdza, że nie czynią one instalacji bezpieczną. Należy stosować je na czas przygotowywania aktualizacji, a nie zamiast niej.

• Przeciw CVE-2026-109618: ustawić memory_limit=-1 w sposób, którego aplikacje nie mogą nadpisać, na przykład przez php_admin_value w puli FPM, i sprawdzić, że żadna pula, katalog ani wpis aplikacji nie ustawia ponownie skończonego limitu. Ustawić niski post_max_size (8M bez przesyłania plików, 32M z nim) i utrzymywać upload_max_filesize poniżej niego. Ograniczyć rozmiar żądania, liczbę pól, liczbę części multipart, liczbę nagłówków i głębokość zagnieżdżenia na serwerze WWW lub proxy. Limitu pamięci kontenera lub cgroup używać jako granicy dostępności, ale nie RLIMIT_AS ani RLIMIT_DATA, które mogą wywołać podatną awarię alokacji.
• Przeciw CVE-2026-109619: ustawić session.upload_progress.enabled=0 w php.ini, puli FPM lub konfiguracji serwera, która działa przed analizą żądania (nie przez ini_set() ani .user.ini), i uruchomić ponownie wszystkie procesy robocze. W PHP 8.5 ustawić dodatkowo fatal_error_backtraces=0. Usunąć nieprawidłowe lub przestarzałe ustawienia dla pojedynczych żądań, które wypisują diagnostykę przed inicjalizacją, oraz naprawić błędy krytyczne i przekroczenia czasu wykonania, do których atakujący może dotrzeć.

Co SilentShield może tu zrobić, a czego nie

To nie jest problem botów i wolimy to powiedzieć, niż pozwolić, by strona produktu sugerowała co innego. Atak uderza w silnik PHP, zanim żądanie zobaczy cokolwiek z naszych rozwiązań, jakikolwiek CAPTCHA, wtyczka lub reguła zapory wewnątrz aplikacji. Ochrona przed botami na formularzu tego nie zatrzymuje i nikt nie powinien Państwu mówić, że zatrzymuje. Jedynym pełnym rozwiązaniem jest aktualizacja PHP.

API i panel SilentShield nie są napisane w PHP. Wtyczka WordPress i PHP SDK działają w Państwa własnym PHP, więc w ich przypadku aktualizacja musi nastąpić na Państwa serwerze. Po aktualizacji zwykła ochrona przed botami i spamem z formularzy jest tak samo przydatna jak wcześniej; po prostu nigdy nie była odpowiedzią na to zagrożenie.

Źródła

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Zapowiedź PHP z 20 października 2026 r.
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produkty osadzające PHP