Notatki dotyczące bezpieczeństwa.
21 października projekt PHP opublikował krytyczny komunikat z krótkim zaleceniem: natychmiast zaktualizować oprogramowanie. Dwie luki umożliwiające zdalne wykonanie kodu — CVE-2026-109618 i CVE-2026-109619 — otrzymały ocenę CVSS 9.2. Pierwsza jest wykorzystywana, gdy PHP wyczerpie pamięć w trakcie przygotowywania żądania, a następnie zwalnia dane, które nigdy nie zostały w pełni zainicjalizowane. Druga pozwala, by wewnętrzny stan jednego żądania przetrwał w pamięci, przez co kolejne żądanie obsługiwane przez ten sam proces może go przejąć. Podatna jest każda konfiguracja PHP obsługująca ruch sieciowy — PHP-FPM, mod_php, php-cgi, FrankenPHP i LiteSpeed — przy czym najwyższe ryzyko dotyczy mod_php.
Poprawki zawierają wersje PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Komunikat jasno wskazuje, że nie ma pełnego sposobu obejścia problemu: jedynym bezpiecznym rozwiązaniem jest instalacja poprawki.
Nasze działania przed udostępnieniem poprawki. Podatności ogłoszono przed publikacją nowych wersji, dlatego w międzyczasie ograniczyliśmy ryzyko na obsługiwanych przez nas serwerach. Wyłączyliśmy śledzenie postępu przesyłania plików w sesjach — częściowe zabezpieczenie drugiej luki wskazane w komunikacie — i włączyliśmy rygorystyczny tryb sesji jako dodatkowe wzmocnienie. Oba ustawienia wdrożyliśmy w każdym środowisku PHP na każdym hoście oraz w kontenerach aplikacji. Zweryfikowaliśmy je bezpośrednio w procesach PHP obsługujących żądania, zamiast polegać wyłącznie na plikach konfiguracyjnych.
Poprawki wdrożone tego samego dnia. Po publikacji nowych wersji pakiety dystrybucyjne i oficjalne obrazy kontenerów nie były jeszcze zaktualizowane. Zamiast czekać, zbudowaliśmy poprawione wersje z oficjalnych, zweryfikowanych sumami kontrolnymi źródeł PHP, zachowaliśmy istniejące rozszerzenia i ustawienia każdego serwera oraz przebudowaliśmy zgodną wersję OPcache. Aplikacje korzystające jeszcze z PHP 8.0 lub 8.1, dla których nie są już publikowane ogólne wydania, otrzymały oficjalne poprawki bezpieczeństwa projektu PHP zamiast awaryjnego skoku na inną wersję. Aplikacje w kontenerach przenieśliśmy na załatany obraz 8.4.27 i przypięliśmy obraz bazowy, aby przyszłe kompilacje nie mogły po cichu wrócić do podatnej wersji.
Weryfikujemy, zamiast zakładać. Sam numer wersji niczego nie dowodzi, ponieważ kompilacja z poprawką i bez niej może zgłaszać ten sam ciąg znaków. Dlatego zweryfikowaliśmy faktycznie używane silniki i kompilacje OPcache w każdej aktywnej puli WWW, a następnie sprawdziliśmy publiczne sklepy, strony logowania i witryny demonstracyjne. Wszystkie 23 aktywne pule PHP w naszych środowiskach i środowiskach klientów przeszły kontrolę.
Co to oznacza dla Państwa sklepu. Jeśli korzystają Państwo z Magento lub innej aplikacji PHP i nie przeprowadzili aktualizacji od 21 października, sprawa wymaga pilnej uwagi. Proszę sprawdzić wersję PHP używaną przez procesy obsługujące witrynę, a nie tylko wersję dostępną w wierszu poleceń. Warto też zaplanować migrację z PHP 8.0 i 8.1, jeśli aplikacja nadal z nich korzysta. Poprawki bezpieczeństwa dają dodatkowy czas, ale nie są rozwiązaniem długoterminowym.
Jeśli chcą Państwo, abyśmy sprawdzili konfigurację lub przeprowadzili aktualizacje, prosimy o kontakt — codziennie dbamy o bezpieczeństwo i ciągłe działanie sklepów.