CVE-2026-115560: Nowe Niezałatane Ryzyko PHP RCE Wymaga Natychmiastowej Mitigacji

PHP ujawnił CVE-2026-115560, nowe zagrożenie zdalnym wykonaniem kodu dotyczące aplikacji internetowych, które korzystają z nietypowej kombinacji konfiguracji sesji PHP i zachowania środowiska uruchomieniowego. Problem ujawniono 23 października 2026 roku, zaledwie dwa dni po tym, jak PHP wydał awaryjne poprawki dla krytycznych luk PHP2Shell CVE-2026-109618 i CVE-2026-109619.

W przeciwieństwie do wcześniejszych luk, CVE-2026-115560 nie wywołało kolejnego wydania ratunkowego PHP. Zespół bezpieczeństwa PHP uważa, że podatna konfiguracja jest mało prawdopodobna w typowych wdrożeniach i planuje rozwiązać ten problem w ramach następnego regularnego cyklu napraw błędów. Do tego czasu administratorzy powinni wyłączyć funkcję śledzenia postępu przesyłania sesji PHP tam, gdzie można spotkać się z podatną konfiguracją.

Nowa luka jest również ważna, ponieważ instalacja PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 — wydań, które naprawiły dwie wcześniejsze luki PHP2Shell — nie not wyeliminuje CVE-2026-115560. Dlatego w pełni zaktualizowane systemy mogą pozostawać narażone, jeśli ich aplikacje spełniają konkretne wymogi konfiguracyjne.

Zespoły ds. bezpieczeństwa poszukujące możliwości wykrywania CVE-2026-115560 powinny priorytetowo traktować widoczność zarządzania sesjami PHP, nietypowe wieloczęściowe przesyłanie danych, nieoczekiwane zmiany w zachowaniu serializacji sesji oraz podejrzane procesy potomne uruchamiane przez PHP lub pracowników serwera WWW.

Platforma do wykrywania zagrożeń AI-Native Detection SOC Prime umożliwia zespołom ds. bezpieczeństwa wzmocnienie ochrony przed nowymi eksploatacjami podatności i związanym z nimi działaniami po naruszeniu w środowiskach SIEM, EDR i Data Lake.

Kliknij Przeglądaj wykrycia aby uzyskać dostęp do odpowiednich treści dotyczących wykrywania i logiki polowań. Aby Wykryć CVE-2026-115560, obrońcy powinni połączyć ocenę konfiguracji PHP z transmisją internetową, końcową, aplikacyjną i telemetrią rewers-proxy, póki poprawka dostawcy jest niedostępna.

Praktycy bezpieczeństwa mogą również wykorzystać Prime Architect do przekształcania nowo ujawnionych informacji o podatności w zasady Sigma i zapytania łowieckie, weryfikowania logiki wykrywania i tłumaczenia odpowiednich wykryć na wspierane platformy bezpieczeństwa.

Kontakt ze sprzedażą

Analiza CVE-2026-115560

PHP opublikowało informacyjne powiadomienie 23 października opisujące potencjalnie możliwą do wykorzystania interakcję między serializacją sesji a funkcją śledzenia postępu przesyłania sesji.

Według zespołu bezpieczeństwa PHP, aplikacja musi spełniać kilka konkretnych warunków, zanim problem może wystąpić:

• session.serialize_handler musi być początkowo skonfigurowany jako php_binary lub php_serialize.
• Kod aplikacji musi następnie zmienić handler na php w czasie wykonywania za pomocą ini_set().
• Ta zmiana musi nastąpić przed wywołaniem session_start().
• session.upload_progress.enabled musi pozostać włączony.

Aplikacje, które nigdy nie zmieniają handlera serializacji w czasie wykonywania, nie są narażone przez tę konkretną ścieżkę i mogą nadal korzystać z postępu przesyłania sesji. PHP opisuje tę podatną kombinację jako rzadką.

To rozróżnienie znacznie zwęża powierzchnię ataku w porównaniu do CVE-2026-109618 i CVE-2026-109619. Wcześniejsze podatności PHP2Shell dotyczyły szeroko PHP obsługujących strony internetowe i wymagały aktualizacji awaryjnych. CVE-2026-115560 zależy od specyficznej dla aplikacji konfiguracji i zachowania kodu.

Szczegóły dotyczące CVE-2026-115560 pozostają celowo ograniczone. PHP nie opublikowało jeszcze kompletnej analizy technicznej przyczyny, dokładnych zakresów wersji podatnych, oceny CVSS ani konkretnego wewnętrznego stanu pamięci lub sesji, który ostatecznie powoduje warunek RCE. Producent oprogramowania twierdzi, że szczegóły te będą uwzględnione w kolejnym regularnym wydaniu.

Na podstawie ujawnionych wymagań, luka wydaje się związana z niespójnym przetwarzaniem danych sesji, gdy aplikacja zmienia formaty serializacji podczas przetwarzania żądań, gdy mechanizm śledzenia postępu przesyłania PHP jest aktywny. Jednak dokładny prymityw exploitu nie powinien być wnioskowany poza tym, co PHP formalnie ujawnił.

CVE-2026-115560 dotyczy aplikacji, które spełniają wzór podatnej konfiguracji, w tym aplikacji uruchamiających w pełni naprawione wydania PHP zawierające poprawki PHP2Shell z 21 października. PHP nie wskazało jeszcze, które gałęzie PHP lub wydania historyczne zawierają podstawową wadę.

Oznacza to, że administratorzy nie powinni określać narażenia wyłącznie na podstawie zainstalowanej wersji PHP. Zamiast tego muszą ocenić konfigurację aplikacji i serwera.

Użytecznym pierwszym krokiem jest sprawdzenie, czy śledzenie postępu przesyłania sesji jest włączone:

session.upload_progress.enabled=1

Administratorzy powinni również zidentyfikować wszystkie fragmenty kodu aplikacji wywołujące ini_set() do modyfikacji session.serialize_handler, w szczególności przejścia z php_binary lub php_serialize na php.

Nowa luka jest oddzielna od CVE-2026-109619, chociaż działania łagodzące zachodzą na siebie. Wyłączenie śledzenia postępu przesyłania sesji już było zalecane jako miara zmniejszenia ryzyka dla jednej z oryginalnych podatności PHP2Shell. Organizacje, które pozostawiły to ustawienie wyłączone po aktualizacji awaryjnej z 21 października, są już chronione przed niedawno ujawnioną ścieżką, zgodnie z PHP.

Obecnie nie ma publicznie udokumentowanego PoC dla CVE-2026-115560 przez PHP ani dostarczonych raportów. Zespół ds. bezpieczeństwa nie ujawnił także wystarczająco szczegółowych informacji technicznych, aby odtworzyć lukę w sposób niezawodny korzystając wyłącznie z publicznej konsultacji.

To znacznie różni się od wcześniejszych błędów PHP2Shell, dla których pojawiły się różne próby dowodów koncepcji i działalność exploatacyjna wokół ujawnienia. Tych ataków nie należy przypisywać nowej podatności.

Nie zgłoszono żadnego wykorzystania CVE-2026-115560 od 26 października 2026 roku. Hacker News wyraźnie rozróżnia obecne skanowanie PHP2Shell i próby eksploatacji od tej nowszej podatności, zauważając, że zaobserwowana aktywność celuje w CVE-2026-109618 i CVE-2026-109619.

W rezultacie, IOCs dla CVE-2026-115560, takie jak złośliwe adresy IP, domeny, hasze, ładunki, czy potwierdzone wzorce żądań eksploatacyjnych, nie są obecnie dostępne.

Dopóki nie pojawią się bardziej szczegółowe informacje techniczne, obrońcy powinni koncentrować się na wskaźnikach związanych z zachowaniem i konfiguracją, takich jak:

• Aplikacje PHP zmieniające session.serialize_handler podczas wykonywania
• Śledzenie postępu przesyłania sesji pozostaje włączone w aplikacjach z niestandardową logiką sesji
• Nieoczekiwany ruch POST wieloczęściowy do aplikacji obsługujących sesje PHP
• Procesy PHP-FPM, php-cgi, Apache lub inne processy PHP uruchamiające powłoki lub interpretery skryptów
• Nieoczekiwane wychodzące połączenia sieciowe z pracowników PHP
• Nowo utworzone pliki wewnątrz korzeni stron internetowych lub katalogów aplikacji z opcją zapisu
• Nietypowe zmiany w plikach sesji lub w magazynie sesji
• Powłoki internetowe, zaplanowane zadania lub nieautoryzowana persystencja utworzona przez konta usług PHP

Deweloperzy aplikacji powinni również przejrzeć niestandardową logikę obsługi sesji. Rozszerzenia frameworka, starsze aplikacje, wewnętrzne platformy lub niestandardowe systemy uwierzytelniania bardziej prawdopodobnie niż bezproblemowe wdrożenia PHP modyfikują ustawienia serializacji dynamicznie.

Ujawnienie ma miejsce w okresie już aktywnej działalności eksploatacyjnej PHP. Oryginalne luki PHP2Shell zostały załatane 21 października, a kilka firm zajmujących się bezpieczeństwem zaobserwowało następnie szerokie sondowanie i próby eksploatacji. Jednak PHP i badacze bezpieczeństwa nie połączyli tych kampanii z CVE-2026-115560.

Łagodzenie CVE-2026-115560

PHP obecnie zaleca jedno bezpośrednie działanie obronne:

session.upload_progress.enabled=0

Administratorzy powinni zastosować ustawienie przez php.ini, konfigurację puli PHP-FPM, konfigurację Apache lub inny mechanizm na poziomie serwera, który działa przed przetwarzaniem żądań.

Organizacje, które wyłączyły tę funkcję podczas łagodzenia CVE-2026-109619 i pozostawiły ją wyłączoną, nie potrzebują dodatkowej zmiany konfiguracji w przypadku tej podatności.

Po zmianie ustawienia, restartuj procesy PHP i odpowiednie usługi internetowe, aby zapewnić, że istniejące procesy załadują zaktualizowaną konfigurację. W zależności od środowiska może to obejmować ponowne uruchomienie pul PHP-FPM, pracowników Apache, kontenerów lub innych procesów runtime aplikacji PHP.

Administratorzy mogą zweryfikować efektywne ustawienie przez inspekcję konfiguracji PHP, zamiast zakładać, że centralna wartość php.ini obowiązuje wszędzie. Wdrożenia PHP często łączą ustawienia z:

• Globalny php.ini
• pliki conf.d
• konfiguracja puli PHP-FPM
• dyrektywy Apache
• konfiguracja specyficzna dla kontenera
• plików .user.ini na poziomie aplikacji
• wywołania runtime ini_set()

Najważniejsza ocena narażenia jest specyficzna dla aplikacji. Przeszukaj kod źródłowy aplikacji pod kątem dynamicznej modyfikacji serializatora sesji, szczególnie wzorów zawierających:

ini_set(’session.serialize_handler’, 'php’)

Aplikacje, które nigdy nie zmieniają serializatora z php_binary lub php_serialize na php przed session_start(), nie pasują do podatnego scenariusza, jaki ujawniło PHP.

Organizacje powinny jednakże utrzymywać aktualizacje bezpieczeństwa PHP2Shell z 21 października. Wyłączenie postępu przesyłania adresuje nowo zidentyfikowaną ścieżkę, ale nie zastępuje awaryjnych poprawek dla CVE-2026-109618 i CVE-2026-109619.

Wsparte instalacje powinny zatem pozostać co najmniej na:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Te wydania naprawiają wcześniejsze problemy PHP2Shell, ale nie nowo ujawnioną podatność.

Zespoły ds. bezpieczeństwa powinny również zinwentaryzować niewspierane instalacje PHP. Wydania PHP 8.1 i starsze nie otrzymują już rutynowych aktualizacji bezpieczeństwa upstream, co oznacza, że organizacje działające w środowiskach legacy mogą mieć trudności z ustaleniem pełnego narażenia po opublikowaniu końcowego komunikatu o CVE.

Jeśli wyłączenie postępu przesyłania sesji jest operacyjnie niemożliwe, organizacje powinny najpierw ustalić, czy ich aplikacje faktycznie modyfikują handler serializacji dynamicznie. PHP wyraźnie stwierdza, że aplikacje, które nigdy nie wykonują tej zmiany w czasie wykonywania, mogą pozostawić włączone śledzenie postępu przesyłania sesji.

Jako dodatkowe środki ochronne, obrońcy mogą:

• Ograniczyć zewnętrzny dostęp do wrażliwych aplikacji PHP.
• Stosować restrykcyjne reguły rewers-proxy wokół zbędnych punktów końcowych przesyłania plików.
• Monitorować żądania wieloczęściowe związane z sesjami PHP.
• Alarmować o nietypowych procesach podrzędnych pracowników PHP.
• Stosować zasadę najmniejszych uprawnień do kont PHP-FPM i serwera sieciowego.
• Zapobiegać, aby usługi PHP pisały do katalogów wykonywalnych, gdy tylko jest to możliwe.
• Ograniczać wychodzącą łączność ze środowisk aplikacyjnych sieci WWW.
• Monitorować korzenie stron internetowych i katalogi tymczasowe pod kątem nieautoryzowanego tworzenia plików.

AWS zauważyło również, że reguły WAF dla aplikacji PHP mogą blokować żądania POST łączące identyfikatory sesji PHP z polem PHP_SESSION_UPLOAD_PROGRESS, zapewniając dodatkową warstwę ochronną dla środowisk, które nie mogą natychmiast wprowadzić zmian konfiguracyjnych. Tego typu filtrowanie powinno być nadal traktowane jako głębokość obronna, a nie zamiennik zalecanej zmiany konfiguracji PHP.

Po wydaniu regularnej aktualizacji naprawiającej przez PHP, organizacje powinny natychmiast wdrożyć ją, nawet jeśli tymczasowe łagodzenie jest już włączone.

Po zastosowaniu łatek administratorzy mogą zdecydować, czy konieczne jest ponowne włączenie śledzenia postępu przesyłania sesji, w oparciu o wymagania aplikacji.

Jeśli podejrzewa się eksploatację, należy odizolować serwer aplikacji dotknięty problemem i zachować telemetrię sieci WWW, PHP, rewers-proxy, końcową i sieciową. Przypatrz się katalogom z możliwością zapisu dla powłok internetowych lub nowo utworzonych plików, przeszukaj procesy potomne PHP i zidentyfikuj poświadczenia lub tajemnice dostępne dla skompromitowanej usługi.

W związku z tym, że pomyślna eksploatacja mogłaby potencjalnie prowadzić do wykonania kodu z uprawnieniami pracownika PHP, osoby reagujące powinny odświeżyć odpowiednie poświadczenia aplikacji, sekrety baz danych, tokeny API, klucze chmurowe i inne poufne informacje, jeśli nie można wykluczyć kompromitacji.

Zastrzeżenie: Treści dotyczące wykrywania mogą nie być dostępne dla każdej CVE. Sprawdź platformę SOC Prime pod kątem aktualnego pokrycia. Jeśli odpowiednie wykrycia nie są jeszcze dostępne, sprawdź ponownie, ponieważ nowe informacje o zagrożeniach i treści wykryć są dodawane na bieżąco.