CVE-2026-109618: RCE przez stan out-of-memory

Krótko: CVE-2026-109618 to jedna z dwóch luk kryjących się za PHP2Shell. Stan out-of-memory może przerwać PHP, gdy dane żądania są dopiero częściowo zainicjowane; przy sprzątaniu nieprawidłowe dane mogą być wtedy uznane za prawidłowe. Umożliwia to wykonanie kodu bez logowania. Błąd jest naprawiony w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.

Czym jest CVE-2026-109618?

CVE-2026-109618 (identyfikator GitHub GHSA-w8hw-w9fx-j79w) to luka błędu pamięci w jądrze PHP. Ma w skali CVSS v4.0 ocenę 9,2. Wraz z CVE-2026-109619 tworzy to, co media nazywają PHP2Shell.

Skutkiem jest tzw. unauthenticated Remote Code Execution: atakujący może zdalnie i bez konta użytkownika wykonać kod na serwerze WWW. Luka należy więc do najniebezpieczniejszej klasy słabych punktów, jaką może mieć serwer WWW.

Jak luka powstaje w zarysie

Gdy PHP przetwarza żądanie WWW, tworzy wewnętrznie struktury danych dla tego żądania, na przykład dla przesłanych danych formularza. Jeśli PHP przy tym dochodzi do swojego limitu pamięci, przerywa pracę ze stanem out-of-memory. Według php.net może się to zdarzyć, gdy dane żądania są dopiero częściowo zainicjowane.

Na końcu każdego żądania PHP sprząta i zwalnia pamięć. Właśnie tu leży błąd: sprzątanie może traktować nieprawidłowe, tylko do połowy utworzone dane jako prawidłowe. Z tego błędnego zachowania w pewnych warunkach można wyprowadzić wykonanie kodu.

Dlaczego taki błąd jest tak poważny? Błąd pamięci w języku programowania dotyczy wszystkich działających na nim aplikacji, niezależnie od tego, jak starannie zostały zaprogramowane. Zadbana instalacja WordPress z aktualnymi wtyczkami jest dotknięta tak samo jak stare rozwiązanie własne. Dlatego nie pomaga tu aktualizacja aplikacji, lecz tylko aktualizacja PHP.

Dalszych szczegółów technicznych dotyczących wykorzystania celowo nie publikujemy. Do obrony nie są potrzebne: decydujące jest, czy Państwa serwer używa naprawionej wersji i czy nowe procesy faktycznie działają.

Dotknięte wersje i tryby pracy

Dotknięte są tryby pracy PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Zespół PHP ocenia ryzyko przy mod_php najwyżej. Dystrybucje i dostawcy hostingu częściowo wprowadzają backporty, przez co wyświetlany jest starszy numer wersji, choć błąd jest naprawiony. Miarodajne są stan pakietów i potwierdzenie dostawcy.

Dla porównania skali: Palo Alto Networks (Unit 42) naliczyło ponad 22,6 miliona wystawionych na dostęp, potencjalnie podatnych instancji. BSI ogłosił poziom ostrzeżenia 3 (pomarańczowy) i spodziewał się szybkiego, masowego wykorzystania luki.

Usunięcie CVE-2026-109618: aktualizacja i restart

Jedynym pełnym środkiem zaradczym jest aktualizacja. Proszę najpierw sprawdzić wersję i stan pakietów. Nazwy pakietów różnią się zależnie od dystrybucji; przykłady zakładają PHP 8.3:

php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"

Jeśli changelog pakietu wymienia numer CVE, backport jest wprowadzony. Jeśli go brakuje, nie oznacza to automatycznie, że pakiet jest podatny; wtedy pomaga porównanie z tabelą wersji lub zapytanie do dostawcy.

Po aktualizacji należy zrestartować wszystkie procesy PHP, na przykład poleceniem systemctl restart php8.3-fpm albo przy mod_php restartem Apache. Jak upewnić się, że żaden stary worker już nie działa, opisuje strona Restart PHP-FPM i wszystkich workerów.

Środki przejściowe, gdy aktualizacja jeszcze nie jest możliwa

php.net opublikował dla PHP2Shell środki przejściowe. Obowiązują łącznie dla obu luk i wyraźnie nie są pełną ochroną. To, że kilka z nich dotyczy limitów pamięci, pasuje do wyzwalacza out-of-memory w CVE-2026-109618; oficjalnego przyporządkowania poszczególnych środków do poszczególnych CVE jednak nie ma.

; Przykład puli FPM, np. /etc/php/8.3/fpm/pool.d/www.conf (ścieżka zależy od dystrybucji)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, jeśli potrzebne są uploady
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off

Wartości muszą być ustawione tak, aby aplikacje nie mogły ich nadpisać, stąd php_admin_value. Przy memory_limit=-1 usługa potrzebuje limitu pamięci z zewnątrz, przez kontener lub cgroup, a nie przez RLIMIT_AS czy RLIMIT_DATA. W PHP 8.5 dochodzi fatal_error_backtraces=0. Wszystkie szczegóły znajdą Państwo na stronie Środki natychmiastowe, gdy nie można jeszcze załatać.

Jak konkretnie pomaga PHP SOS?

Przez naszą usługę łatania PHP zamykamy CVE-2026-109618 w sposób uporządkowany:

• Rejestracja stanu faktycznego: gałąź PHP, tryb pracy, źródło pakietów i stan backportów dla każdego serwera.
• Instalacja aktualizacji z odpowiedniego źródła pakietów lub, gdzie się nie da, prawidłowe ustawienie środków przejściowych w konfiguracji puli lub serwera.
• Kontrola restartu: sprawdzamy, że żadne stare procesy PHP już nie działają.
• Dowód: otrzymują Państwo dokumentację z wersjami i stanami pakietów przed i po interwencji, na przykład dla zarządu, ubezpieczyciela lub ochrony danych.

Częste pytania

Źródła

• php.net: komunikaty o bezpieczeństwie
• PHP 8 ChangeLog
• BSI: Federalny Urząd ds. Bezpieczeństwa Informacji (Niemcy)