Podatności PHP CVE-2026-109618 i CVE-2026-109619

Ujawniono podatności CVE-2026-109618 i CVE-2026-109619 w silniku core PHP, umożliwiające zdalne wykonanie kodu (RCE) bez uwierzytelnienia w procesie nieprawidłowego zakończenia i zarządzania stanem żądania. Problem nie dotyczy aplikacji internetowych, takich jak WordPress czy GnuBoard, lecz uszkodzenia pamięci i błędu użycia po zwolnieniu (Use-After-Free) w samym silniku wykonawczym PHP. Aby usunąć problem, należy niezwłocznie zaktualizować PHP do wersji z zastosowanymi poprawkami bezpieczeństwa, takich jak PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a następnie zrestartować procesy workerów.

Podatność silnika PHP, której nie można usunąć samą aktualizacją aplikacji internetowej

21 października 2026 r. (UTC) zespół PHP opublikował informacje o dwóch podatnościach bezpieczeństwa ocenionych na 9,2 punktu według CVSS v4.0. Atakujący może wykonać dowolny kod na serwerze, wysyłając spreparowane żądanie HTTP, bez przechodzenia przez proces logowania.

Podatności działają w warstwie core PHP, która analizuje żądania internetowe i zwalnia pamięć. Dlatego nawet przy aktualnym CMS-ie i wtyczkach środowisko pozostaje narażone, jeśli sam runtime PHP jest w starszej wersji. Szczególnie w środowiskach Apache z domyślną konfiguracją mod_php potwierdzono możliwość wykonania kodu za pomocą pojedynczego żądania, jeszcze przed uruchomieniem kodu aplikacji internetowej.

Po udanym ataku intruz uzyskuje uprawnienia konta systemowego, na którym działa proces PHP. Nie oznacza to natychmiastowego przejęcia uprawnień roota, ale możliwe jest utworzenie webshella w katalogu głównym witryny albo odczytanie danych dostępowych do bazy danych zapisanych w plikach konfiguracyjnych, a następnie wyprowadzenie lub modyfikacja danych wewnętrznych. Jeśli wiele witryn na jednym serwerze współdzieli to samo konto uruchamiające PHP-FPM, istnieje również ryzyko rozprzestrzenienia się naruszenia z jednej witryny na inne witryny na serwerze.

Uszkodzenie pamięci i mechanizm użycia po zwolnieniu podczas nieprawidłowego zakończenia

Obie podatności powstają, gdy podczas obsługi żądania pamięć nie zostaje bezpiecznie uporządkowana w wyjątkowej sytuacji. Warunki wystąpienia i wewnętrzny mechanizm działania są w obu przypadkach inne.

CVE-2026-109618 (uszkodzenie pamięci podczas obsługi przekroczenia limitu pamięci): gdy podczas obsługi żądania PHP przekroczy dozwolony limit pamięci (Out-Of-Memory), wywołuje longjmp() i natychmiast przerywa wykonanie. Jeśli praca zostanie zatrzymana, zanim wewnętrzne struktury danych żądania zostaną w pełni zainicjowane, niekompletny stan pozostaje bez wycofania. Następnie procedura porządkowania żądania (cleanup) uznaje niezainicjowaną pamięć za prawidłowe dane i uzyskuje do niej dostęp, co prowadzi do uszkodzenia pamięci i zdalnego wykonania kodu.

CVE-2026-109619 (Use-After-Free odwołujący się do zwolnionej pamięci poprzedniego żądania): niektóre globalne stany wewnętrzne PHP lub stany obsługi błędów tymczasowo wskazują obszar pamięci należący do pojedynczego żądania. Gdy żądanie zostanie nieprawidłowo zakończone z powodu błędu krytycznego (fatal error) lub braku pamięci, rzeczywista pamięć może zostać zwolniona, a wewnętrzna referencja wskaźnika wskazująca ten obszar może pozostać niezainicjowana. W środowiskach ponownie wykorzystujących procesy workerów, takich jak PHP-FPM lub mod_php, gdy ten sam worker obsłuży kolejne żądanie HTTP, ponowny odczyt już zwolnionego obszaru pamięci (Use-After-Free) tworzy ścieżkę do wykonania kodu.

Oficjalny komunikat bezpieczeństwa wymienia jako potwierdzone ścieżki dla CVE-2026-109619 funkcję postępu przesyłania sesji (session.upload_progress), ostrzeżenia konfiguracyjne wyświetlane przed inicjalizacją żądania oraz ślady wsteczne błędów krytycznych w PHP 8.5 (fatal_error_backtraces). Jednocześnie wskazuje, że zablokowanie tych ścieżek nie usuwa innych wariantów ataku.

Stan poprawek dla poszczególnych wersji PHP i zakres wpływu zależny od środowiska wykonawczego

Podatne są wersje PHP 8.2–8.5 starsze niż wersje z poprawkami, natomiast niewspierana już gałąź 8.1 i wcześniejsze nie jest objęta oficjalnymi aktualizacjami projektu PHP. Pod względem sposobu uruchamiania podatność dotyczy wszystkich instalacji obsługujących żądania internetowe, w tym PHP-FPM, mod_php, php-cgi, FrankenPHP i LiteSpeed. Oficjalny komunikat uznaje mod_php za najbardziej ryzykowny z tych wariantów. Red Hat klasyfikuje PHP-FPM jako warunkowo podatny przez ścieżkę na poziomie aplikacji.

Zweryfikowane środowisko: 22 października 2026 r. w środowisku serwera Linux korzystającego z repozytorium Remi zaktualizowano PHP 8.4.26 do 8.4.27, a następnie zweryfikowano restart workerów PHP-FPM i obsługę żądań internetowych.

Procedura aktualizacji pakietów i zastosowania ustawień łagodzących w PHP-FPM

Zespół PHP informuje, że sama zmiana ustawień nie blokuje wszystkich ścieżek ataku, a jedynym kompletnym rozwiązaniem jest aktualizacja do wersji z poprawką. Po aktualizacji można dodatkowo wyłączyć niepotrzebne funkcje, aby zmniejszyć powierzchnię ataku.

1. Instalacja aktualizacji pakietów PHP
   Za pomocą menedżera pakietów systemu operacyjnego zaktualizuj używaną gałąź PHP do wersji z poprawką (dla gałęzi 8.4 jest to 8.4.27). Po instalacji najpierw sprawdź wersję CLI w terminalu.

   php -v

   Po wykonaniu polecenia na ekranie zostanie wyświetlony zaktualizowany numer wersji i data kompilacji, na przykład PHP 8.4.27 (cli). Wersja CLI i wersja procesu PHP faktycznie używanego przez serwer internetowy mogą się jednak różnić, dlatego należy koniecznie wykonać następny krok.

2. Dostosowanie ustawień PHP-FPM w celu zmniejszenia powierzchni ataku (opcjonalne i tymczasowe łagodzenie)
   Jeśli natychmiastowa aktualizacja jest trudna albo potrzebna jest dodatkowa warstwa ochrony, wykonaj kopię zapasową pliku php.ini lub pliku konfiguracji puli PHP-FPM (na przykład /etc/php-fpm.d/www.conf), a następnie zmień poniższe ustawienia.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   Wyłączenie session.upload_progress.enabled blokuje potwierdzoną ścieżkę ataku opartą na sesji. Obniżenie post_max_size (na przykład do 8M w środowiskach, w których przesyłanie plików nie jest potrzebne, lub do 32M w środowiskach, w których jest potrzebne) utrudnia próby wyczerpania pamięci za pomocą dużych żądań. Należy przy tym uwzględnić rozmiar dodatkowych nagłówków multipart i ustawić upload_max_filesize nieco niżej niż post_max_size. W środowisku PHP 8.5 należy również zastosować ustawienie fatal_error_backtraces = 0.

3. Sprawdzenie składni konfiguracji PHP-FPM i restart procesów
   Po zapisaniu konfiguracji sprawdź, czy nie zawiera błędów składni, a następnie zrestartuj usługę PHP-FPM.

   php-fpm -t
   systemctl restart php-fpm

   Jeśli konfiguracja jest prawidłowa, po wykonaniu php-fpm -t na ekranie pojawi się komunikat NOTICE: configuration file ... test is successful. Restart workerów jest konieczny, aby zakończyć działanie starych workerów pozostających w pamięci i zastosować nową poprawkę oraz konfigurację.

4. Sprawdzenie rzeczywistej wersji używanej przez żądania internetowe
   Otwórz kartę informacji „Stan witryny (Site Health)” w WordPressie albo stronę diagnostyczną integracji z serwerem internetowym i sprawdź, czy worker PHP-FPM obsługujący żądania odpowiada wersją z poprawką, taką jak 8.4.27. Jeśli tymczasowo utworzono diagnostyczny plik PHP, usuń go natychmiast po sprawdzeniu, aby nie ujawniać na zewnątrz informacji o systemie.

Postępowanie w razie opóźnienia aktualizacji lub skutków ubocznych zmiany konfiguracji

Pakietu nie można pobrać z powodu opóźnienia synchronizacji mirrora repozytorium zewnętrznego (np. Remi)

Bezpośrednio po pilnej poprawce bezpieczeństwa pakiety aktualizacyjne w repozytorium zewnętrznym (na przykład rpms.remirepo.net) mogą nie być od razu dostępne albo mogą pobierać się wolno z powodu dużego ruchu lub opóźnienia synchronizacji. Oficjalny komunikat wskazuje, że w dniu publikacji aktualizacje nie pojawiają się w repozytorium utrzymywanym przez wolontariuszy, i zaleca przejście na pakiety dystrybucji albo kompilację ze źródeł.

W takiej sytuacji można bezpośrednio wskazać w konfiguracji repozytorium mirror, który zakończył synchronizację i działa z prawidłową prędkością, a następnie przeprowadzić aktualizację. Nawet po ręcznej zmianie mirrora należy pozostawić aktywne sprawdzanie podpisu GPG (gpgcheck=1), aby zapobiec modyfikacji pakietów. Jeśli użycie mirrora jest niemożliwe, należy skorzystać z oficjalnego pakietu backportowanego przez dystrybucję systemu operacyjnego albo skompilować i zastosować kod źródłowy.

Obawy przed brakiem pamięci (OOM) lub odrzucaniem przesyłania po zastosowaniu ustawień łagodzących

Oficjalny komunikat wskazuje memory_limit = -1 (bez ograniczeń) jako środek łagodzący dla CVE-2026-109618, gdy natychmiastowa aktualizacja nie jest możliwa, oraz zaleca jednoczesne zastosowanie limitu pamięci kontenera lub cgroup. Jednak zniesienie limitu pamięci na serwerze z niewielką ilością pamięci fizycznej może doprowadzić do sytuacji, w której pojedyncze żądanie zużyje całą pamięć serwera, a systemowy OOM Killer wymusi zakończenie kluczowych daemonów. Jest to tymczasowe działanie do czasu aktualizacji; po przejściu na wersję z poprawką bezpiecznie jest przywrócić pierwotny limit pamięci.

Przed obniżeniem post_max_size względem dotychczasowej wartości (na przykład 64 MB) należy również sprawdzić sposób przesyłania plików w witrynie. W witrynach, w których duże kopie zapasowe lub wtyczki są przesyłane bezpośrednio przez panel administracyjny, żądania mogą zostać zablokowane. Natomiast jeśli duże pliki są przesyłane przez SFTP lub rsync albo ograniczenie aplikacji jest już ustawione na 30 MB lub mniej, obniżenie limitu przesyłania PHP do 32 MB nie wpłynie na działanie usługi.

Jeśli po aktualizacji wersji PHP workery PHP-FPM sporadycznie kończą działanie w sposób nieprawidłowy, warto sprawdzić ustawienia kompilacji JIT (Just-In-Time) w OPcache. Funkcja JIT (na przykład opcache.jit=1255) nie jest bezpośrednio związana z tą podatnością bezpieczeństwa, ale jeśli po zmianie wersji występowały problemy ze stabilnością, można ją wyłączyć w pliku konfiguracji za pomocą opcache.jit=off, aby zapobiec awariom.

Często zadawane pytania

Czy aktualizacja WordPressa lub wtyczek do najnowszej wersji rozwiąże problem?

Nie. Podatność występuje w silniku core PHP, na etapie poprzedzającym uruchomienie WordPressa lub wtyczki bezpieczeństwa. Zapora aplikacji internetowej (Cloudflare, AWS WAF itp.) może tymczasowo blokować znane wzorce ataków, ale aby usunąć przyczynę problemu, należy za pośrednictwem dostawcy hostingu lub administratora serwera zaktualizować samą wersję PHP na serwerze.

Czy po wyłączeniu ustawienia session.upload_progress.enabled można bezpiecznie pominąć aktualizację?

Nie. Oficjalny komunikat wskazuje, że ustawienie to blokuje tylko potwierdzoną ścieżkę sesji i nie blokuje innych wariantów. Ponadto ustawienie należy zastosować przed analizą żądania, w php.ini, puli FPM lub konfiguracji serwera, a nie za pomocą ini_set() czy .user.ini w FPM, oraz zrestartować wszystkie workery. Pełne rozwiązanie stanowi wyłącznie instalacja poprawki.

Czy po zakończeniu aktualizacji można od razu wrócić do pracy bez dodatkowej kontroli?

Aktualizacja blokuje przyszłe ataki, ale nie informuje, czy do wcześniejszego naruszenia już doszło. Po zakończeniu aktualizacji warto osobno sprawdzić, czy nie doszło do wcześniejszej kompromitacji. Należy sprawdzić, czy w katalogu internetowym nie ma ostatnio nietypowo utworzonych lub zmodyfikowanych plików PHP, takich jak webshell, oraz przeanalizować logi dostępu serwera internetowego i logi błędów PHP pod kątem nietypowych dużych żądań POST lub powtarzających się błędów pamięci.

Jak reagować w środowisku kontenerów lub obrazów chmurowych?

Aktualizacja pakietów na serwerze hosta nie zmienia automatycznie runtime PHP zawartego w kontenerze. Należy więc ponownie zbudować i wdrożyć obraz kontenera na podstawie obrazu bazowego zawierającego poprawioną wersję (8.5.12, 8.4.27, 8.3.36 lub 8.2.35).

Źródła

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (po koreańsku)