Krytyczne luki RCE w PHP: CVE-2026-109618 i CVE-2026-109619

Zespół PHP wydał pilne aktualizacje naprawiające dwie krytyczne podatności na zdalne wykonanie kodu bez uwierzytelnienia: CVE-2026-109618 oraz CVE-2026-109619. Obie otrzymały ocenę 9,2 w CVSS 4.0. Poprawki trafiły do PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.

To nie jest komunikat, który powinien czekać do zwykłego miesięcznego okna serwisowego. PHP potwierdza możliwość wykonania kodu przez żądanie HTTP z uprawnieniami procesu webowego. Najwyższy priorytet mają publiczne serwery, na których działa Apache z mod_php, PHP-FPM, php-cgi, FrankenPHP lub LiteSpeed.

Wniosek Breachroad: najbezpieczniejszą odpowiedzią jest aktualizacja, a nie próba zbudowania ochrony wyłącznie z ustawień i reguł WAF. Producent wprost zaznacza, że kompletne obejście nie istnieje. Firma powinna równolegle ustalić ekspozycję, wdrożyć poprawkę, sprawdzić skuteczność i poszukać oznak nadużycia.

Co dokładnie się wydarzyło

21 października 2026 roku PHP opublikował cztery wydania bezpieczeństwa:

• PHP 8.5.12;
• PHP 8.4.27;
• PHP 8.3.36;
• PHP 8.2.35.

Naprawiają one dwa różne błędy prowadzące do podobnego skutku. CVE-2026-109618 dotyczy uszkodzenia pamięci po błędzie alokacji, a CVE-2026-109619 — ponownego użycia nieprawidłowego globalnego stanu między etapami obsługi żądań. W obu przypadkach badacze potwierdzili zdalne wykonanie kodu bez logowania.

Atak nie oznacza automatycznie przejęcia całego systemu jako administrator. Kod działa początkowo z uprawnieniami konta procesu PHP. To jednak nadal może wystarczyć do odczytania konfiguracji aplikacji, sekretów bazy danych, tokenów API i plików klientów, zmiany kodu serwisu albo przygotowania dalszej eskalacji.

Kto jest narażony

Oficjalny komunikat obejmuje instalacje PHP obsługujące żądania webowe, w tym:

• Apache z mod_php;
• PHP-FPM za Nginxem lub Apache;
• php-cgi;
• FrankenPHP;
• LiteSpeed i inne integracje korzystające z podatnego runtime’u.

Ryzyko nie ogranicza się do aplikacji napisanej od zera w PHP. Dotyczy także systemów CMS, sklepów, portali pracowniczych, paneli partnerów i starszych aplikacji, jeżeli ich faktycznym interpreterem jest podatna wersja. Samo sprawdzenie wersji WordPressa, Drupala, Magento czy frameworka nie wystarczy.

Trzeba sprawdzić również obrazy kontenerów, środowiska serverless z własnym runtime’em, serwery testowe, stare panele administracyjne i hosty utrzymywane przez dostawcę. Obraz z poprawionym tagiem nie oznacza jeszcze, że wszystkie repliki zostały odtworzone.

Dlaczego te luki są szczególnie niebezpieczne

Pierwsza podatność może wykorzystać sytuację, w której kontrolowane przez atakującego żądanie doprowadza do wyczerpania lub błędu pamięci, a późniejsza obsługa błędu pozostawia proces w niebezpiecznym stanie. Badacze potwierdzili pełne RCE przez HTTP wobec mod_php w typowej konfiguracji wieloprocesowej.

Druga luka wykorzystuje stan, który nie został prawidłowo wyczyszczony. Oficjalny advisory opisuje potwierdzone ścieżki przez obsługę błędów i cykl życia sesji, zarówno dla mod_php, jak i PHP-FPM. Atak może wymagać, aby odpowiednie żądania trafiły do tego samego workera, ale większa liczba workerów jedynie zmniejsza prawdopodobieństwo pojedynczej próby — nie usuwa podatności.

To ważna informacja dla osób podejmujących decyzję: „mamy kilka procesów” albo „ruch rozkłada load balancer” nie jest wiarygodnym zabezpieczeniem. Złożoność exploita może wpływać na jego niezawodność, ale nie zmienia możliwego skutku.

Co firma powinna zrobić dziś

1. Zbuduj listę rzeczywiście uruchomionych wersji

Nie opieraj się na deklaracji w repozytorium. Sprawdź runtime w działających kontenerach, maszynach wirtualnych, hostingach, workerach i środowiskach odtwarzanych z obrazów. Właściciel każdej usługi powinien potwierdzić wersję, sposób integracji z serwerem webowym i ekspozycję na internet.

2. Aktualizuj do wersji zawierającej poprawkę

Minimalne wersje naprawione to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Starszych gałęzi nie należy uznawać za bezpieczne tylko dlatego, że nie ma dla nich nowej paczki. W ich przypadku właściwą decyzją jest migracja do wspieranej linii.

PHP przypomina również, że gałąź 8.2 kończy wsparcie bezpieczeństwa 31 grudnia 2026 roku. Aktualizacja do 8.2.35 zamyka bieżącą lukę, ale nie rozwiązuje problemu dalszego cyklu życia.

3. Wdróż poprawkę na każdym węźle i zrestartuj workery

Zweryfikuj źródło pakietu lub obrazu, wykonaj test zgodności, wdrożenie etapowe i restart wszystkich procesów korzystających ze starej biblioteki lub binarnego runtime’u. Następnie ponownie odczytaj wersję z uruchomionego procesu. Sam build zakończony powodzeniem nie jest dowodem skutecznego wdrożenia.

4. Ogranicz ekspozycję do czasu aktualizacji

Jeżeli poprawki nie da się wdrożyć natychmiast, ogranicz publiczny dostęp, odseparuj panel administracyjny, zmniejsz uprawnienia konta webowego i wzmocnij limity żądań na reverse proxy. Oficjalne wskazówki opisują ustawienia zmniejszające część znanych ścieżek, ale nie są one kompletnym rozwiązaniem.

5. Prowadź triage równolegle z patchowaniem

Zachowaj logi reverse proxy, WAF, serwera HTTP, PHP i systemu operacyjnego. Szukaj nietypowych serii dużych lub błędnych żądań, restartów workerów, błędów alokacji, nowych plików w katalogach aplikacji, uruchamiania powłoki przez konto webowe oraz niespodziewanego ruchu wychodzącego.

Brak gotowej sygnatury nie jest dowodem braku ataku. Zestaw zachowanie procesu z osią czasu wdrożeń, zmianami plików i aktywnością sekretów dostępnych dla aplikacji.

Czego nie robić

• Nie odkładaj aktualizacji tylko dlatego, że publiczny exploit nie pojawił się jeszcze w Twoich źródłach.
• Nie traktuj reguły WAF jako pełnego zamiennika poprawki.
• Nie sprawdzaj wyłącznie wersji pakietu na hoście, jeśli aplikacja działa w kontenerze lub ma własny runtime.
• Nie restartuj w ciemno przed zabezpieczeniem potrzebnych logów i danych ulotnych, gdy występują oznaki kompromitacji.
• Nie obracaj wszystkich sekretów bez planu. Najpierw ustal, które poświadczenia były dostępne dla procesu i gdzie są używane, a następnie rotuj je w kontrolowanej kolejności.

Plan dla osób nietechnicznych

Właściciel biznesowy nie musi analizować pamięci procesu. Powinien jednak uzyskać od IT lub dostawcy jednoznaczne odpowiedzi:

1. Czy którakolwiek publiczna usługa korzysta z PHP?
2. Jaką wersję uruchamia każdy węzeł, a nie tylko dokumentacja?
3. Kiedy wszystkie instancje otrzymały poprawkę i zostały zrestartowane?
4. Jak potwierdzono nową wersję po wdrożeniu?
5. Jakie logi sprawdzono i czy znaleziono sygnały nadużycia?
6. Jakie sekrety mógł odczytać proces webowy?

Jeżeli system utrzymuje podwykonawca, odpowiedź „mamy automatyczne aktualizacje” nie wystarcza. Poproś o wersję, czas wdrożenia, zakres instancji i wynik weryfikacji. To dowody techniczne, które da się zebrać bez ujawniania wrażliwej konfiguracji.

Fakty źródłowe i wnioski Breachroad

PHP potwierdza dwie krytyczne podatności, możliwość nieuwierzytelnionego RCE, objęte środowiska webowe, naprawione wydania oraz brak pełnej mitygacji zastępującej aktualizację. Advisories projektu opisują potwierdzony wpływ na mod_php i PHP-FPM oraz ograniczenia częściowych obejść.

Priorytetyzacja publicznych usług, sposób inwentaryzacji, równoległy triage, pytania do dostawcy i model dowodów wdrożenia są rekomendacjami Breachroad. Warto połączyć je ze stałym procesem zarządzania podatnościami i planem reagowania na incydenty. Zespoły techniczne i właściciele usług mogą przećwiczyć podobny scenariusz podczas szkoleń cyberbezpieczeństwa dla organizacji, a rzeczywistą ekspozycję serwerów zweryfikować przez audyt bezpieczeństwa IT.

Źródła pierwotne: PHP — komunikat i wydania bezpieczeństwa z 21 października 2026, GHSA-w8hw-w9fx-j79w — RCE via OOM corruption, GHSA-6wmf-4rv5-p3rp — RCE via stale global state.