Nowa podatność RCE w PHP bez łatki: CVE-2026-115560 i zalecane obejście

Wprowadzenie do problemu / definicja

Zespół rozwijający PHP ostrzegł przed nową podatnością typu remote code execution, oznaczoną jako CVE-2026-115560. Problem jest istotny, ponieważ w chwili ujawnienia nie opublikowano jeszcze pełnej poprawki, a producent wskazał jedynie tymczasowe działania ograniczające ryzyko. Luka nie dotyczy jednak każdej instalacji PHP, lecz specyficznej kombinacji ustawień obsługi sesji i zachowania aplikacji podczas działania.

Z perspektywy zespołów bezpieczeństwa oznacza to konieczność szybkiej weryfikacji, czy środowisko korzysta z niestandardowych mechanizmów serializacji sesji oraz funkcji śledzenia postępu uploadu. Nawet jeśli scenariusz ataku jest wąski, potencjalne skutki udanej eksploatacji pozostają bardzo poważne.

W skrócie

Nowa luka została ujawniona 23 października 2026 roku i według twórców PHP może zostać wykorzystana tylko w rzadziej spotykanym scenariuszu konfiguracyjnym. Warunkiem ataku jest użycie określonych handlerów serializacji sesji, ich dynamiczna zmiana przed uruchomieniem sesji oraz pozostawienie aktywnej funkcji śledzenia postępu przesyłania plików.

Podatność oznaczono jako CVE-2026-115560.
Na moment ujawnienia nie było jeszcze oficjalnej łatki.
Zalecanym obejściem jest wyłączenie opcji session.upload_progress.enabled.
Problem nie dotyczy domyślnej i typowej konfiguracji PHP.
Ryzyko rośnie w środowiskach legacy oraz aplikacjach z niestandardową logiką sesji.

Kontekst / historia

Ostrzeżenie pojawiło się w czasie zwiększonej presji na ekosystem PHP. Wcześniej społeczność reagowała już na inne krytyczne błędy RCE, określane zbiorczo jako PHP2Shell, dla których opublikowano poprawki w utrzymywanych gałęziach 8.3 i 8.4. W efekcie administratorzy i zespoły SOC już wcześniej otrzymali sygnał, że funkcje związane z obsługą sesji oraz uploadem plików wymagają szczególnej uwagi.

Znaczenie tego tła jest praktyczne. Gdy atakujący obserwują dany ekosystem i aktywnie skanują internet w poszukiwaniu podatnych hostów, nawet luka wymagająca nietypowych warunków może szybko stać się celem prób automatycznej eksploatacji. Dlatego nowy problem należy rozpatrywać nie tylko przez pryzmat samej złożoności technicznej, ale także aktualnego zainteresowania cyberprzestępców środowiskami PHP.

Analiza techniczna

Według opublikowanego ostrzeżenia scenariusz prowadzący do potencjalnego zdalnego wykonania kodu wymaga spełnienia kilku warunków jednocześnie. Po pierwsze, aplikacja musi korzystać z ustawienia session.serialize_handler skonfigurowanego jako php_binary lub php_serialize. Po drugie, przed wywołaniem session_start() aplikacja musi dynamicznie przełączyć ten parametr na wartość php przy użyciu ini_set(). Po trzecie, aktywna musi pozostać funkcja session.upload_progress.enabled.

Taka kombinacja wskazuje, że źródłem ryzyka jest nie tylko sam interpreter, ale również interakcja między sposobem serializacji danych sesyjnych a logiką aplikacji wykonywaną w runtime. Dynamiczna zmiana handlera serializacji nie jest typowym wzorcem dla dobrze utrzymanych wdrożeń produkcyjnych, jednak może występować w starszych aplikacjach, niestandardowych frameworkach, kodzie kompatybilnościowym albo własnych modułach uploadu.

Z technicznego punktu widzenia szczególnie istotna jest funkcja śledzenia postępu przesyłania plików. Rozszerza ona powierzchnię ataku wokół danych sesyjnych i może prowadzić do sytuacji, w której wejście zostanie zinterpretowane w sposób niezamierzony. Jeśli aplikacja dodatkowo modyfikuje sposób serializacji sesji w czasie działania, powstaje warstwa ryzyka, którą atakujący może próbować wykorzystać do uzyskania wykonania kodu na serwerze.

Konsekwencje / ryzyko

Najważniejsze jest to, że nie chodzi o trywialne RCE działające na każdej instalacji PHP. Warunki eksploatacji są ograniczone, ale sam rezultat potencjalnego ataku pozostaje krytyczny. W przypadku skutecznej eksploatacji napastnik może uzyskać możliwość uruchamiania poleceń na serwerze aplikacyjnym, a następnie próbować eskalacji uprawnień, wdrożenia webshella, kradzieży danych lub manipulacji kodem aplikacji.

W organizacjach utrzymujących systemy legacy ryzyko bywa wyższe, niż sugerowałaby sama teoria. W dużych środowiskach produkcyjnych nietypowe manipulowanie ustawieniami sesji nie zawsze jest dobrze udokumentowane, a część zmian może być zaszyta w starszych bibliotekach lub komponentach tworzonych lata temu. To sprawia, że nawet zawężony warunek podatności może zostać nieświadomie spełniony.

Dodatkowym czynnikiem ryzyka jest kontekst operacyjny. Przy wzmożonym skanowaniu internetu przez botnety i grupy cyberprzestępcze nawet niszowy wektor ataku może szybko zostać zautomatyzowany. Organizacje nie powinny więc zakładać bezpieczeństwa wyłącznie na podstawie przekonania, że używają rzadkiej konfiguracji.

Rekomendacje

Najważniejszym działaniem krótkoterminowym jest wyłączenie opcji session.upload_progress.enabled, o ile nie jest ona niezbędna biznesowo. To obecnie podstawowe obejście zalecane do czasu publikacji regularnej poprawki bezpieczeństwa.

Równolegle warto przeprowadzić audyt konfiguracji i kodu aplikacyjnego, koncentrując się na obszarach związanych z obsługą sesji oraz uploadem plików.

Sprawdzić użycie session.serialize_handler i potwierdzić, czy nie wykorzystuje wartości php_binary lub php_serialize w ryzykownym scenariuszu.
Wyszukać wywołania ini_set() zmieniające parametry sesji przed session_start().
Przeanalizować własne moduły uploadu, starsze komponenty i niestandardowe frameworki.
Zweryfikować, czy wdrożono wcześniej poprawki i mitygacje związane z ostatnimi błędami PHP2Shell.
Zwiększyć monitoring logów HTTP, aplikacyjnych i systemowych pod kątem nietypowych żądań uploadu oraz anomalii sesyjnych.
Ograniczyć uprawnienia procesu serwera WWW i stosować segmentację usług, aby zmniejszyć skutki ewentualnego RCE.
Dodać kontrole w CI/CD wykrywające niedozwolone zmiany krytycznych parametrów sesji w runtime.

W środowiskach o wysokim poziomie ekspozycji internetowej warto potraktować ten incydent jako sygnał do szerszego przeglądu polityk bezpieczeństwa aplikacji PHP. Szczególnie ważne są zasady ograniczające złożoność konfiguracji sesji i eliminujące niestandardowe wzorce, które utrudniają ocenę ryzyka.

Podsumowanie

CVE-2026-115560 to nowa podatność RCE w PHP, która w momencie ujawnienia pozostawała bez oficjalnej łatki, ale z jasno wskazanym obejściem konfiguracyjnym. Choć warunki potrzebne do eksploatacji są zawężone do niestandardowych wdrożeń, nie należy bagatelizować problemu ze względu na ciężar potencjalnych skutków i trwające zainteresowanie atakujących ekosystemem PHP.

Dla organizacji korzystających z PHP jest to dobry moment na pilny przegląd obsługi sesji, wyłączenie funkcji śledzenia postępu uploadu tam, gdzie nie jest niezbędna, oraz weryfikację, czy aplikacje nie stosują ryzykownych zmian konfiguracji podczas działania. W praktyce szybko wykonany audyt może mieć dziś większą wartość niż oczekiwanie wyłącznie na przyszłą aktualizację.