Notatki o bezpieczeństwie.
21 października projekt PHP opublikował krytyczny komunikat bezpieczeństwa z krótkim zaleceniem: zaktualizuj teraz. Dwie luki umożliwiające zdalne wykonanie kodu, CVE-2026-109618 i CVE-2026-109619, otrzymały ocenę CVSS 9.2. Pierwsza pojawia się, gdy PHP wyczerpie pamięć w trakcie przygotowywania żądania, a później sprząta dane, które nigdy nie zostały w pełni zainicjalizowane. Druga pozwala, by stan wewnętrzny jednego żądania przetrwał zwolnienie jego pamięci, więc kolejne żądanie obsługiwane przez ten sam worker może go przejąć. Podatna jest każda konfiguracja PHP obsługująca ruch WWW — PHP-FPM, mod_php, php-cgi, FrankenPHP i LiteSpeed — przy czym najwyższe ryzyko dotyczy mod_php.
Poprawione wydania to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Komunikat jasno stwierdza, że nie ma pełnego obejścia: jedyną bezpieczną opcją jest aktualizacja.
Co zrobiliśmy, zanim pojawiła się poprawka. Luki ogłoszono przed wydaniem, więc przez godziny dzielące te wydarzenia ograniczaliśmy ryzyko na serwerach, którymi się opiekujemy. Wyłączyliśmy session upload progress, wskazane w komunikacie jako częściowe zabezpieczenie przed drugą luką, i włączyliśmy strict session mode jako dodatkowe utwardzenie. Oba ustawienia trafiły do każdego środowiska PHP na każdym hoście i w kontenerach aplikacji, a sprawdziliśmy je na workerach PHP faktycznie odpowiadających na żądania, zamiast ufać plikom konfiguracyjnym.
Łatanie tego samego dnia. Gdy wydania się pojawiły, zwykłe pakiety dystrybucji i oficjalne obrazy kontenerów jeszcze za nimi nie nadążały. Zamiast czekać, zbudowaliśmy poprawione wersje z oficjalnych źródeł PHP ze zweryfikowanymi sumami kontrolnymi, zachowaliśmy istniejące rozszerzenia i ustawienia każdego serwera i przebudowaliśmy OPcache. Aplikacje działające jeszcze na PHP 8.0 lub 8.1, które nie otrzymują już publicznych wydań, dostały oficjalne backporty poprawek bezpieczeństwa projektu PHP zamiast awaryjnego skoku wersji. Aplikacje kontenerowe przenieśliśmy na załatany obraz 8.4.27, z przypiętym obrazem bazowym, aby przyszła kompilacja nie mogła po cichu wrócić do podatnej wersji.
Sprawdzamy, a nie zakładamy. Sam numer wersji niczego nie dowodzi, gdy załatana i niezałatana kompilacja mogą zwracać ten sam ciąg. Dlatego każdą aktywną pulę WWW zweryfikowaliśmy pod kątem silnika i kompilacji OPcache, które naprawdę działają, a potem sprawdziliśmy publiczne sklepy, strony logowania i strony demo. Wszystkie dwadzieścia trzy aktywne pule PHP w naszych środowiskach i środowiskach klientów przeszły weryfikację.
Co to oznacza dla Państwa sklepu. Jeśli korzystają Państwo z Magento lub innej aplikacji PHP i nie aktualizowali jej od 21 października, proszę potraktować to jako pilne. Proszę sprawdzić wersję PHP, na której faktycznie działają workery WWW, a nie tylko w wierszu poleceń, i zaplanować odejście od PHP 8.0 i 8.1, jeśli nadal z nich Państwo korzystają. Backporty poprawek bezpieczeństwa dają czas, ale nie są rozwiązaniem na dłuższą metę.
Jeśli chcą Państwo, żebyśmy spojrzeli na Państwa infrastrukturę, albo chcą powierzyć nam takie aktualizacje, prosimy o kontakt — dbanie o bezpieczeństwo i ciągłość działania sklepów to duża część naszej codziennej pracy.