Pe 23 octombrie 2026, la două zile după patch-urile pentru PHP2Shell, echipa de securitate PHP a anunțat o nouă vulnerabilitate de tip execuție de cod de la distanță: CVE-2026-115560. Nu există încă versiune reparată. Update-urile din 21 octombrie (8.5.12, 8.4.27, 8.3.36, 8.2.35) nu o acoperă.

Ce e nou

  • Problema e tot în session upload progress, aceeași funcție implicată în PHP2Shell.
  • Recomandarea oficială: session.upload_progress.enabled=0 până la următoarea versiune de PHP.
  • Reparația vine în ciclul normal de release, odată cu advisory-ul complet. Scorul de severitate și lista exactă de versiuni nu sunt publicate încă.
  • Nu s-a raportat exploatare până acum.

Pentru PHP2Shell, Cloudflare a raportat milioane de încercări de exploatare până pe 22 octombrie. Sophos spune că nu are dovezi de servere compromise reușit.

Cine e expus

Doar dacă sunt adevărate toate trei condițiile:

  • în configurație, session.serialize_handler este php_binary sau php_serialize;
  • codul aplicației îl schimbă în php cu ini_set() înainte de session_start();
  • session.upload_progress.enabled e pornit (implicit este On).

Majoritatea site-urilor nu ating serialize_handler. Dacă ai aplicat deja măsura temporară pentru PHP2Shell și ai păstrat-o, nu mai ai nimic de făcut.

Cum verifici

Setările curente din linia de comandă:

php -i | grep -E \
 'serialize_handler|upload_progress.en'

Ce fișiere php.ini sunt încărcate:

php --ini

CLI-ul poate avea alt php.ini decât site-ul. Pentru valoarea reală de pe web, pune temporar un fișier cu un nume greu de ghicit în webroot, deschide-l în browser și șterge-l imediat:

<?php echo ini_get(
 'session.upload_progress.enabled');

Setări puse direct în pool-urile PHP-FPM (Debian/Ubuntu):

grep -rn -e upload_progress \
 -e serialize_handler /etc/php/*/fpm/

Pe RHEL / AlmaLinux / Rocky:

grep -rn -e upload_progress \
 -e serialize_handler \
 /etc/php.ini /etc/php.d /etc/php-fpm.d

Pe CWP sau CloudLinux, verifică fiecare versiune din /opt/alt:

for p in /opt/alt/php*/usr/bin/php; do \
 echo "$p"; $p -i | grep -E \
 'serialize_handler|upload_progress.en'; \
 done

Pool-urile FPM ale conturilor din CWP:

grep -rln upload_progress \
 --include='*.conf' /opt/alt/

Caută în cod (inclusiv în vendor/ și pluginuri) dacă ceva schimbă serialize_handler:

grep -rn serialize_handler \
 --include='*.php' \
 /var/www /home/*/public_html

Dacă găsești un ini_set('session.serialize_handler', 'php') și configurația are php_binary sau php_serialize, aplicația e în zona de risc.

Ce faci: dezactivezi session upload progress

Setarea trebuie să se aplice înainte ca PHP să parseze request-ul. Pune-o în php.ini, în pool-ul FPM sau în config-ul serverului web. Nu te baza pe ini_set() sau pe .user.ini.

În php.ini (fiecare versiune folosită):

session.upload_progress.enabled = 0

În fiecare pool FPM, ca aplicațiile să nu o poată suprascrie:

php_admin_flag[session.upload_progress.enabled] = off

Pe Apache cu mod_php, în VirtualHost sau .htaccess:

php_flag session.upload_progress.enabled off

Restart la toate workerele, altfel cele vechi păstrează setarea veche. Debian/Ubuntu:

systemctl restart 'php*-fpm' apache2

RHEL / AlmaLinux / Rocky:

systemctl restart php-fpm httpd

CWP (toate versiunile PHP-FPM alternative):

systemctl restart 'php-fpm*' httpd

Verifică după restart, din nou prin fișierul de test din browser sau:

php -i | grep upload_progress.enabled

Trebuie să apară Off. Pierzi doar progresul de upload prin $_SESSION. Majoritatea barelor de progres moderne sunt făcute în JavaScript și merg mai departe.

Dacă nu ai făcut încă update-ul pentru PHP2Shell, fă-l acum. Pașii sunt în articolul despre PHP2Shell. Apoi urmărește următorul release PHP, care va repara și CVE-2026-115560.

Surse

Vrei să verific eu serverul sau site-ul tău? Scrie-mi aici.