Wprowadzenie do problemu / definicja
Projekt PHP opublikował ostrzeżenie dotyczące nowej podatności oznaczonej jako CVE-2026-115560, która w określonych warunkach może prowadzić do wykonania kodu po stronie serwera. Problem dotyczy mechanizmu sesji oraz funkcji śledzenia postępu przesyłania plików i pojawił się krótko po udostępnieniu poprawek dla krytycznych błędów zbiorczo określanych jako PHP2Shell.
Choć maintainterzy PHP podkreślają, że podatność wymaga rzadkiej i bardzo specyficznej konfiguracji aplikacji, jej znaczenie pozostaje wysokie. Powodem jest zarówno potencjalny wpływ udanego ataku, jak i fakt, że luka dotyczy podstawowych elementów działania aplikacji webowych opartych na PHP.
W skrócie
Nowa luka została ujawniona 23 października 2026 r. i nie jest usuwana przez awaryjne aktualizacje opublikowane 21 października 2026 r. dla wcześniejszych podatności zdalnego wykonania kodu. Oznacza to, że organizacje, które zakończyły już pilne aktualizacje po PHP2Shell, muszą dodatkowo zweryfikować konfigurację sesji i uploadów.
- Podatność otrzymała identyfikator CVE-2026-115560.
- Wymaga spełnienia kilku jednoczesnych warunków konfiguracyjnych.
- Dotyczy obsługi sesji oraz funkcji session.upload_progress.
- Tymczasowym obejściem jest wyłączenie session.upload_progress.enabled.
- Problem ma zostać usunięty w standardowym cyklu wydawniczym PHP.
Kontekst / historia
Ujawnienie nowego błędu nastąpiło zaledwie dwa dni po publikacji pilnych poprawek dla dwóch krytycznych luk RCE: CVE-2026-109618 i CVE-2026-109619. Tamte podatności były szczególnie niebezpieczne, ponieważ dotyczyły szerokiej powierzchni ataku w środowiskach obsługujących ruch webowy i wymusiły szybką reakcję administratorów oraz zespołów DevSecOps.
W praktyce wiele organizacji koncentrowało się najpierw na wdrożeniu naprawczych wersji PHP 8.2.35, 8.3.36, 8.4.27 oraz 8.5.12. Krótko później pojawiło się jednak kolejne ostrzeżenie, tym razem związane z mniej typowym, ale nadal istotnym scenariuszem obejmującym sesje i obsługę uploadów.
Ta sekwencja zdarzeń pokazuje, że bezpieczeństwo silnika PHP pozostaje jednym z kluczowych elementów ochrony aplikacji internetowych. Nawet jeśli nowa podatność nie wygląda na masowo eksploatowalną, jej pojawienie się zwiększa presję na dokładny przegląd niestandardowych ustawień środowisk produkcyjnych.
Analiza techniczna
Mechanizm podatności koncentruje się wokół sposobu użycia parametru session.serialize_handler. Według opisu problem może wystąpić wyłącznie wtedy, gdy aplikacja korzysta z określonych handlerów serializacji sesji, a następnie dynamicznie przełącza konfigurację przed uruchomieniem sesji.
Scenariusz podatny wymaga jednoczesnego spełnienia kilku warunków:
- session.serialize_handler jest ustawiony na php_binary albo php_serialize,
- aplikacja zmienia ten parametr w czasie działania na php przy użyciu ini_set(),
- zmiana następuje przed wywołaniem session_start(),
- włączona pozostaje funkcja session.upload_progress.enabled.
Nie jest to więc klasyczna podatność aktywna w każdej domyślnej instalacji. Zagrożone są przede wszystkim aplikacje niestandardowe, starsze komponenty lub rozwiązania frameworkowe, które modyfikują zachowanie sesji w trakcie obsługi żądania. Taki model utrudnia szybką ocenę ekspozycji, ponieważ problem może nie wynikać z globalnej konfiguracji PHP, lecz z logiki osadzonej bezpośrednio w kodzie aplikacji.
Projekt PHP wskazuje, że środowiska, które nie przełączają handlera serializacji przed session_start(), nie są narażone na ten konkretny wektor ataku. Sugeruje to, że źródłem błędu jest niespójność stanu pomiędzy konfiguracją sesji a obsługą danych pomocniczych związanych z postępem przesyłania plików.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem udanego ataku może być wykonanie kodu w kontekście procesu PHP obsługującego aplikację. Taki scenariusz może otworzyć drogę do przejęcia aplikacji, dostępu do danych sesyjnych, ruchu bocznego w infrastrukturze, a także wdrożenia trwałych mechanizmów utrzymania dostępu.
Ryzyko operacyjne zwiększa fakt, że wiele organizacji nie posiada pełnej widoczności zmian konfiguracyjnych wykonywanych dynamicznie w kodzie. O ile globalne ustawienia w PHP-FPM, Apache lub innych SAPI są zwykle stosunkowo łatwe do audytu, o tyle użycie ini_set() w starszych modułach lub niestandardowych bibliotekach może pozostać niezauważone.
Nawet bez potwierdzonych informacji o aktywnej eksploatacji warto przyjąć ostrożne założenie, że po nagłośnieniu wcześniejszych błędów w PHP wzrośnie aktywność skanerów i prób identyfikacji mniej popularnych wariantów podatności. Atakujący często testują także scenariusze uboczne, które początkowo uznawane są za mało prawdopodobne.
Rekomendacje
Najważniejszym środkiem tymczasowym jest wyłączenie śledzenia postępu uploadu poprzez ustawienie session.upload_progress.enabled na wartość 0. To najprostszy i najszybszy sposób ograniczenia powierzchni ataku do czasu udostępnienia docelowej poprawki w regularnym cyklu wydawniczym.
Poza wdrożeniem obejścia organizacje powinny wykonać także dodatkowe działania kontrolne:
- przeprowadzić przegląd kodu pod kątem użycia ini_set() dla session.serialize_handler,
- zidentyfikować aplikacje zmieniające handler serializacji przed session_start(),
- sprawdzić konfigurację PHP na poziomie globalnym, per-vhost oraz w pulach PHP-FPM,
- utrzymywać aktualne wersje wspieranych gałęzi i monitorować kolejne wydania projektu PHP,
- objąć monitoringiem żądania związane z uploadami oraz nietypowe błędy sesji,
- wykonać testy regresyjne po zmianach konfiguracyjnych,
- ograniczyć uprawnienia procesów PHP oraz segmentować środowiska wykonawcze.
W środowiskach o wyższym poziomie dojrzałości bezpieczeństwa warto również przygotować prosty runbook dla zespołów operacyjnych. Powinien on obejmować sposób weryfikacji konfiguracji, wdrożenie obejścia, procedurę sprawdzania oznak nadużycia oraz plan wycofania zmiany, jeśli wpłynie ona na działanie aplikacji biznesowych.
Podsumowanie
CVE-2026-115560 nie wygląda obecnie na podatność o charakterze powszechnym, ale jej waga wynika z kontekstu i potencjalnych skutków. Luka pojawiła się bezpośrednio po krytycznych błędach PHP2Shell i dotyczy obszaru szczególnie wrażliwego, czyli przetwarzania żądań HTTP, sesji oraz uploadów.
Dla zespołów bezpieczeństwa i administratorów to wyraźny sygnał, że samo wdrożenie wcześniejszych aktualizacji nie zamyka całego tematu. Należy zweryfikować niestandardowe ustawienia sesji, wdrożyć zalecane obejście i obserwować kolejne wydania PHP zawierające pełną poprawkę.
Źródła
- https://securityaffairs.com/201595/security/php-warns-of-new-code-execution-flaw-days-after-php2shell-patches.html
- https://www.php.net/archive/2026.php
- https://www.php.net/releases/8.2/en.php
- https://www.php.net/releases/8.3/en.php
- https://www.php.net/releases/8.4/en.php