Vulnerabilitățile critice din PHP: CVE-2026-109618 și CVE-2026-109619

Două vulnerabilități critice de PHP, ambele cu scor CVSS 9.2. Versiunile corectate, ce am aplicat pe serverele Simplenet și ce poți face dacă îți administrezi singur serverul.

De Andrei ChiraPublicat 6 min de citit

Stadiul la publicare, 21 octombrie, ora 13:30: PHP nu lansase încă corecțiile; lansarea era programată pentru ora 17:00 (ora României).

Actualizare, ora 16:15: o regulă de WAF care blochează cererile cu câmpul de upload progress folosit în aceste atacuri este activă pe toate serverele platformei premium.

Actualizare, ora 19:15: PHP a lansat versiunile corectate — 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Le-am instalat pe toate serverele, atât pe platforma premium cât și pe cea cPanel, cu repornirea PHP. Pe ambele platforme sunt active și reguli de WAF pentru aceste atacuri. Nu trebuie să faci nimic.

Actualizare, 22 octombrie: pe serverele shared cu cPanel sunt securizate toate versiunile de PHP instalate, de la 5.4 până la 8.5. Corecțiile au venit de la CloudLinux și au păstrat numele de versiune vechi, deci numărul afișat în cPanel nu se schimbă.

Pe 20 octombrie 2026, echipa PHP a anunțat o lansare de securitate neprogramată pentru două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, ambele cu scor CVSS v4.0 de 9.2.

Nu sunt probleme de WordPress și nici de pluginuri. Sunt în PHP, deci afectează orice aplicație rulată de interpretor: WordPress, Laravel, Magento, PrestaShop, cod scris în casă.

Ambele permit execuție de cod la distanță fără autentificare, iar corecțiile sunt disponibile de pe 21 octombrie. Singura rezolvare completă este actualizarea PHP.

Ce spune anunțul oficial

  • Versiunile corectate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Echipa PHP recomandă actualizarea imediată.
  • Riscul există pe orice instalare care servește cereri web: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP, LiteSpeed. Cel mai expus este mod_php, unde există un exploit demonstrat care se declanșează înainte să ruleze cod din aplicație.
  • CVE-2026-109618, „RCE via OOM corruption”: tratarea situațiilor de memorie epuizată poate întrerupe PHP în timp ce datele interne ale cererii sunt doar parțial inițializate, iar curățarea de la final le poate trata ca valide.
  • CVE-2026-109619, „RCE via stale global state”: stare internă care aparține unei cereri poate supraviețui după eliberarea memoriei, iar o cerere ulterioară servită de același worker o poate folosi înainte de reinițializare.
  • PHP 8.1 și versiunile mai vechi nu primesc actualizări de la proiectul PHP. Pentru severitatea asta echipa de securitate a publicat totuși backport-uri minimale de cod sursă pentru 7.4, 8.0 și 8.1, iar unele distribuții livrează patch-uri proprii.
  • Nicio setare din configurație nu rezolvă complet problema. Măsurile de mai jos reduc expunerea pe anumite căi de atac, nu fac instalarea sigură.

Ce facem la Simplenet

Pe planurile cu Panou Enhance

Pe găzduirea premium — business, publisher, ecommerce, reseller — și pe VPS-urile administrate de noi situația este rezolvată:

  • Am actualizat panoul la Enhance 12.26.1, versiune care dezactivează implicit session.upload_progress.enabled pe toate site-urile.
  • Firewallul nostru de aplicații web blochează acum orice cerere care transportă câmpul PHP_SESSION_UPLOAD_PROGRESS, una dintre rutele folosite pentru exploatarea acestor vulnerabilități. Regula este activă pe toate serverele și acoperă fiecare site, fără nimic de configurat de partea ta.
  • Am instalat pachetele PHP corectate pe toate serverele și am repornit PHP, în aceeași zi cu lansarea oficială. Site-urile rulează pe o versiune corectată.
  • Fiecare site rulează în containerul lui, deci un exploit reușit rămâne limitat la site-ul respectiv, cu excepția situației în care ar fi înlănțuit cu o vulnerabilitate de escaladare de privilegii din kernel.

Nu e nevoie să faci nimic pentru această parte. Dacă site-ul tău rulează pe PHP 8.1 sau mai vechi, însă, nu primește pachete corectate de la proiectul PHP și ar trebui mutat pe 8.2 sau mai nou: vezi cum schimbi versiunea PHP sau scrie-ne și te ajutăm cu testarea.

Pe planurile cu Panou cPanel

Platforma cPanel este separată de cea premium și folosește pachetele PHP distribuite oficial. Toate corecțiile apărute pentru ea au fost aplicate:

  • Pachetele PHP corectate de la cPanel și de la CloudLinux — adică versiunile din MultiPHP Manager și cele din PHP Selector — sunt instalate pe toate serverele, cu repornirea PHP.
  • Pe serverele shared sunt securizate toate versiunile de PHP instalate, de la 5.4 până la 8.5. Corecțiile pentru versiunile ieșite din suport au venit de la CloudLinux, nu de la proiectul PHP.
  • cPGuard a publicat reguli noi de WAF pentru aceste vulnerabilități. Sunt active pe toate serverele cPanel.

Nu trebuie să faci nimic.

Atenție la numărul versiunii: actualizările de la CloudLinux au păstrat numele de versiune vechi. Dacă deschizi phpinfo() sau te uiți în cPanel și vezi tot 7.4.33, de exemplu, nu înseamnă că site-ul a rămas nepatch-uit — corecția este în pachetul instalat, fără schimbarea numărului. Pe platforma premium, în schimb, numărul se schimbă în 8.2.35, 8.3.36, 8.4.27 sau 8.5.12.

Mutarea pe o versiune de PHP aflată în suport rămâne ideea bună pe termen lung, pentru viteză și pentru compatibilitate. Pentru aceste două vulnerabilități, însă, nu e nevoie să te grăbești: scrie-ne și o facem împreună, cu testare. Ține minte și că aici izolarea este la nivel de cont: CloudLinux separă conturile între ele, dar site-urile din același cont împart același spațiu de securitate.

Mitigări dacă îți administrezi singur serverul

Actualizarea la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 este singura rezolvare completă. Măsurile de mai jos sunt pentru situația în care nu poți actualiza imediat: reduc expunerea pe anumite căi de atac, nu fac serverul sigur.

1. Dezactivează session upload progress

Setarea are context PHP_INI_PERDIR, deci ini_set() din cod nu funcționează. Trebuie pusă în configurație.

Într-un fișier .ini dedicat, de exemplu /etc/php/8.3/fpm/conf.d/99-cve-2026-109618.ini:

session.upload_progress.enabled = 0

Sau direct în pool-ul PHP-FPM:

php_admin_flag[session.upload_progress.enabled] = off

Pentru FrankenPHP, în Caddyfile:

{
	frankenphp {
		php_ini session.upload_progress.enabled 0
	}
}

Repornește PHP-FPM după modificare și verifică valoarea printr-o pagină phpinfo() servită prin web, nu din CLI. O comandă de tipul php-fpm8.3 -i | grep session.upload_progress.enabled citește altă configurație și ratează suprascrierile din pool.

2. Blochează cererile multipart pe site-urile care nu au nevoie de ele

Dacă un site nu primește încărcări de fișiere și nu are formulare multipart, poți respinge aceste cereri din webserver, înainte să ajungă la PHP.

nginx, în blocul http {}:

map $http_content_type $is_multipart {
    default     0;
    ~*multipart 1;
}

și în fiecare server {} care servește PHP:

if ($is_multipart) {
    return 403;
}

Dacă ai un error_page 403 care trimite înapoi în PHP, folosește return 444;.

Apache 2.4, în .htaccess sau în configurația site-ului:

<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

Caddy:

@multipart header_regexp Content-Type (?i)multipart
respond @multipart 403

Verifică rezultatul; comanda ar trebui să returneze 403:

curl -s -o /dev/null -w '%{http_code}\n' -F test=1 https://example.com/

Atenție: un site de WordPress pe care se încarcă imagini din administrare, un magazin cu upload de documente sau orice endpoint de upload rămân expuse dacă le lași deschise. Blocarea totală rupe funcționalitatea.

3. Regulă de WAF

O regulă care respinge cererile cu câmpul PHP_SESSION_UPLOAD_PROGRESS ajută doar dacă serverul de origine nu poate fi accesat direct, ocolind WAF-ul. Cloudflare a activat reguli gestionate pe toate planurile.

Ce nu ajută

  • file_uploads = Off — nu oprește procesarea corpului multipart.
  • Micșorarea post_max_size ca soluție în sine — PHP tot parsează cererea. Anunțul oficial o recomandă totuși ca mitigare parțială pentru CVE-2026-109618 (8M pe site-urile fără încărcări de fișiere, 32M dacă sunt necesare), împreună cu limite de dimensiune și de structură a cererii puse în webserver.
  • Middleware în aplicație — codul tău rulează după ce PHP a procesat deja cererea.
  • Oprirea site-ului prin dezactivarea handler-ului PHP — fișierele .php ajung să fie servite ca text, cu tot cu datele de conectare la baza de date. Dacă vrei să oprești un site, oprește-l din webserver.

După lansarea patch-ului

  1. Actualizează PHP și confirmă versiunea instalată (apt-cache policy), pentru că unele oglinzi de pachete rămân în urmă. Build-urile statice, cum e FrankenPHP, au nevoie de o versiune nouă a binarului.
  2. Repornește toate procesele PHP de lungă durată: PHP-FPM, mod_php, Octane, worker-ele de cozi. Un proces vechi rulează în continuare codul vulnerabil.
  3. Planifică ieșirea de pe PHP 8.1 și mai vechi. Acesta nu e ultimul CVE critic din PHP.
  4. Verifică dacă ai fost compromis: fișiere .php apărute în directoarele de upload sau de cache, utilizatori de administrare noi, cereri POST multipart neobișnuite în logurile de acces.

Surse

Mai multe din Găzduire