Awaryjna aktualizacja PHP: dwie krytyczne podatności RCE załatane w 8.2.35–8.5.12
PHP wydało poza harmonogramem aktualizację bezpieczeństwa, zamykającą dwie krytyczne podatności use-after-free w rdzeniu języka — obie podatne na zdalne wykonanie kodu bez uwierzytelnienia, obie z oceną 9,2 w skali CVSS v4.0. Poprawione wersje to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, opublikowane dzisiaj i wymienione w archiwum wydań projektu. Minimalne backporty źródeł dla dawno nieutrzymywanych gałęzi 7.4, 8.0 i 8.1 istnieją wyłącznie na GitHubie — oficjalne pakiety binarne dla nich nie powstaną.
Wydaniu poprzedziło wyjątkowo chaotyczne okno przedujawnienia. 20 października projekt ogłosił awaryjną publikację na dziś, 14:00 UTC, bez podawania podatnych wersji czy funkcji; jak udokumentowało OX Security, zrzuty ekranu narzędzia eksploitacyjnego krążyły zanim patche trafiły do sieci, a sam projekt ostrzegał, że kod proof-of-concept krążący w tym oknie to często przebrany malware. Teraz, gdy patche i biuletyny są publiczne, obraz techniczny jest jaśniejszy, niż sugerował cykl zapowiedzi.Droga od braku pamięci do wykonania kodu
CVE-2026-109618, zarejestrowana jako GHSA-w8hw-w9fx-j79w, nadużywa sposobu, w jaki PHP obsługuje wyczerpanie pamięci. Gdy alokacja zawodzi, silnik rozwija żądanie przez longjmp() — a jeśli dzieje się to, gdy pamięć żądania jest zainicjalizowana tylko częściowo, faza zamykania czyta lub rozgałęzia się później po pamięci w nieprawidłowym stanie. Biuletyn opisuje rodzinę trików presji alokacyjnej, które czynią to osiągalnym ze zwykłego żądania HTTP: ciała multipart bez użytecznego content-length przeciskające się obok post_max_size, części z tysiącami nagłówków, których reprezentacja w pamięci przytłacza rozmiar na przewodzie, oraz puste kontrolki plików, alokujące tablice metadanych bez liczenia się nigdy do max_file_uploads. SAPI mod_php w Apache jest potwierdzony jako podatny: badacze zwalidowali nieuwierzytelnione zdalne wykonanie kodu z konta workera webowego po gołym HTTP na domyślnych konfiguracjach prefork — przy wysokiej złożoności ataku i możliwie wielu próbach. PHP-FPM uznaje się za podatny poprzez ścieżki alokacji specyficzne dla aplikacji; FrankenPHP i LiteSpeed — prawdopodobnie także. Patch zastępuje surowy longjmp miękką pułapką braku pamięci w najbliższym bezpiecznym punkcie VM plus twardą porażką, natychmiast kończącą workera.Zaległy stan globalny w procesach worker
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) to cichsza siostra: procesy worker niosą stan globalny — handlery błędów, dane sesji, ewidencję obiektów i rozszerzeń — który może zacząć wskazywać na pamięć należącą do pojedynczego żądania. Jeśli błąd krytyczny, przerwanie z powodu braku pamięci albo późna diagnostyka zapiszą taki stan i nic go nie zresetuje przed zwolnieniem pamięci żądania, globalne workera wiszą w próżni. Cokolwiek dotknie ich przed inicjalizacją świeżego żądania, czyta zwolnioną pamięć. Potwierdzono dwie produkcyjne ścieżki: krytyczne backtrace'y, nowe w PHP 8.5, pod mod_php oraz mechanizm session upload progress pod mod_php i FPM. Producent i konsument muszą trafić na ten sam proces workera, co czyni pulę FPM z wieloma workerami trudniejszą — ale nie niemożliwą — do trafienia.Strategicznie ułożony układ sterty może dać pełne zdalne wykonanie kodu (RCE). — Biuletyn bezpieczeństwa PHP, GHSA-6wmf-4rv5-p3rp
Co powinni teraz zrobić administratorzy
Aktualizacja to jedyna pełna mitygacja i nie ma czegoś takiego jak „załataj i zapomnij”: oba biuletyny podkreślają restart wszystkich workerów PHP po aktualizacji, bo zaległy stan może przetrwać w długowiecznych procesach. Wspierane gałęzie dostają binaria wydania; strony przykute do gałęzi EOL muszą nałożyć backporty źródłowe same.- Zaktualizuj do 8.2.35, 8.3.36, 8.4.27 lub 8.5.12 (albo nałóż backporty z GitHuba dla 7.4/8.0/8.1), po czym zrestartuj każdy proces workera.
- Jeśli aktualizacja dziś niemożliwa: ustaw session.upload_progress.enabled=0 oraz, na PHP 8.5, fatal_error_backtraces=0, i zrestartuj workery.
- Dla podatności OOM wymuś centralnie memory_limit=-1 i sprawdź, że żaden override puli czy .htaccess nie przywróci skończonego limitu.
- Trzymaj konserwatywny post_max_size, blokuj żądania multipart na froncie, jeśli aplikacja ich nie używa, i ograniczaj zmienne wejściowe, nagłówki i uploady.
- Używaj limitów pamięci kontenera/cgroup zamiast RLIMIT_AS lub RLIMIT_DATA — biuletyn wprost ostrzega, że mechanizmy RLIMIT popychają błędy alokacji na podatną ścieżkę.
- Opcjonalnie ogranicz recykling workerów przez pm.max_requests, skracając okno na przenoszenie stanu.