CVE-2026-115560: wskazówka o session upload progress

Krótko: CVE-2026-115560 to wskazówka opublikowana przez php.net 23 października 2026. Zdalne wykonanie kodu jest według niej możliwe tylko przy nietypowej konfiguracji sesji. Do kolejnego regularnego wydania poprawkowego środek zaradczy brzmi: ustawić po stronie serwera session.upload_progress.enabled=0 i zrestartować wszystkie workery.

Czym jest CVE-2026-115560?

Dwa dni po poprawkach dla luk PHP2Shell CVE-2026-109618 i CVE-2026-109619 projekt PHP opublikował kolejną wskazówkę. CVE-2026-115560 dotyczy obsługi sesji w PHP w połączeniu z funkcją session upload progress, która zapisuje postęp trwających uploadów plików w sesji.

Według php.net możliwe jest zdalne wykonanie złośliwego kodu, ale tylko przy nietypowej konfiguracji. Pełny advisory ze wszystkimi szczegółami ma pojawić się z następnym regularnym wydaniem poprawkowym. Do tego czasu stan wiedzy jest celowo skąpy.

Co robi session upload progress?

Session upload progress to funkcja wygody w PHP. Gdy odwiedzający wysyła większy plik, PHP w trakcie uploadu na bieżąco zapisuje w sesji dane o postępie: ile danych już dotarło i jaki plik jest właśnie przesyłany. Aplikacja może równolegle odpytywać te dane i zbudować z nich pasek postępu.

W praktyce korzysta z tego niewiele aplikacji, ponieważ nowoczesne formularze uploadu zwykle mierzą postęp bezpośrednio w przeglądarce. W PHP funkcja jest jednak domyślnie włączona. Dlatego pojawia się zarówno przy CVE-2026-115560, jak i wśród środków przejściowych przeciw PHP2Shell: co nie jest potrzebne, powinno być wyłączone.

Kiedy serwer jest dotknięty przez CVE-2026-115560?

Według wskazówki php.net muszą wystąpić łącznie trzy warunki:

1. W konfiguracji jako session.serialize_handler ustawiona jest wartość php_binary lub php_serialize.
2. Aplikacja przestawia tę wartość w czasie działania przez ini_set() na php, zanim wywoła session_start().
3. Session upload progress jest aktywny.

Domyślną wartością session.serialize_handler jest php. Zmiana w konfiguracji i przestawienie z powrotem w kodzie jest nietypowe, ale zdarza się w rozwiniętych rozwiązaniach własnych lub bibliotekach z własną obsługą sesji. Czy dotyczy to Państwa, można sprawdzić.

Jak sprawdzić konfigurację

Najpierw obowiązujące wartości. CLI może czytać inny php.ini niż PHP-FPM lub mod_php; proszę więc sprawdzić także konfigurację serwera WWW lub puli FPM.

php -i | grep -E "session.serialize_handler|session.upload_progress.enabled"
grep -rn "serialize_handler\|upload_progress" /etc/php/ 2>/dev/null   # ścieżka zależy od dystrybucji

Następnie kod aplikacji. Poniższe wyszukiwanie jest wyłącznie odczytem i pokazuje miejsca, w których handler jest ustawiany w czasie działania:

grep -rn "session.serialize_handler" /var/www/ --include="*.php"

Jeśli wyszukiwanie nic nie znajdzie, a handler w konfiguracji jest ustawiony na php, opisana kombinacja jest mało prawdopodobna. Session upload progress należy mimo to wyłączyć, ponieważ php.net podaje to samo ustawienie również jako środek przejściowy przeciw PHP2Shell.

Środek zaradczy: session.upload_progress.enabled=0

Proszę ustawić wartość w php.ini, w puli FPM lub w konfiguracji serwera. Według php.net wyraźnie nie przez ini_set() ani .user.ini, ponieważ tam działa za późno lub może zostać nadpisana przez aplikację.

; php.ini (dla wszystkich pul i SAPI, które czytają ten plik)
session.upload_progress.enabled = 0

; lub w puli FPM
php_admin_flag[session.upload_progress.enabled] = off

# Apache z mod_php, w VirtualHost lub w konfiguracji serwera
php_admin_flag session.upload_progress.enabled off

Następnie zrestartować wszystkie workery PHP, na przykład systemctl restart php8.3-fpm albo przy mod_php Apache. Nazwy pakietów i usług różnią się zależnie od dystrybucji. Bez restartu działa nadal stare ustawienie. Więcej na stronie Restart PHP-FPM i wszystkich workerów.

Ocena obok PHP2Shell

CVE-2026-115560 jest wyraźnie węższa niż obie luki PHP2Shell, które działają w zwykłych trybach pracy bez szczególnej konfiguracji. Kto musi teraz ustalać priorytety, powinien najpierw zainstalować aktualizację PHP2Shell, a potem ustawić session.upload_progress.enabled=0. Oba kroki są wykonalne w jednym oknie serwisowym.

Dla zarządu i osób nietechnicznych: CVE-2026-115560 nie jest powodem do niepokoju, ale punktem na liście. Ustawienie wprowadza się szybko, na niewiele aplikacji wpływa zauważalnie i jednocześnie pokrywa jeden ze środków przejściowych przeciw PHP2Shell. Pozostałe środki przejściowe php.net znajdą Państwo na stronie Środki natychmiastowe, gdy nie można jeszcze załatać, a ogólne wskazówki o konfiguracji sesji na stronie Zabezpieczanie sesji w PHP.

Czego jeszcze nie wiemy: które dokładnie wersje PHP są dotknięte i które wydanie przyniesie poprawkę. Zaktualizujemy tę stronę, gdy tylko pojawi się advisory.

Jak konkretnie pomaga PHP SOS?

W ramach utwardzania serwera wdrażamy środek zaradczy trwale i w sposób możliwy do sprawdzenia:

• Odczyt konfiguracji: obowiązujące wartości sesji dla każdego SAPI, puli i hosta wirtualnego.
• Przeszukanie kodu: miejsca, w których handler lub opcje sesji są zmieniane w czasie działania.
• Wyłączenie we właściwym miejscu: w php.ini, puli lub konfiguracji serwera, bez możliwości nadpisania przez aplikację, z następującym restartem.
• Śledzenie: Gdy pojawi się wydanie poprawkowe, instalujemy je i dokumentujemy stan.

Częste pytania

Źródła

• php.net: komunikaty o bezpieczeństwie
• PHP 8 ChangeLog
• OWASP Cheat Sheets