Vulnerabilitățile PHP2Shell: actualizarea de securitate PHP din 21 octombrie 2026

Vulnerabilitățile PHP2Shell: actualizarea de securitate PHP din 21 octombrie 2026. Pe 20 octombrie 2026, echipa de securitate PHP a anunțat o actualizare pentru două vulnerabilități PHP critice, ambele cu scorul 9,2 în CVSS v4.0.

Corecțiile au apărut pe 21 octombrie în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Dacă site-ul dumneavoastră rulează pe o versiune mai veche, actualizarea trebuie făcută acum, nu la următoarea mentenanță.

Vulnerabilitățile PHP2Shell: actualizarea de securitate PHP din 21 octombrie 2026

Cele două probleme au primit identificatorii CVE-2026-109618 și CVE-2026-109619, iar în presa de securitate circulă sub numele „PHP2Shell”. Ambele permit, în anumite condiții, executarea de cod la distanță (RCE) de către un atacator care nu are niciun cont pe site.

Mai jos găsiți cronologia, cauzele tehnice explicate pe înțelesul unui proprietar de site, versiunile afectate și pașii de verificare pe găzduirea cu cPanel.

Ce a anunțat echipa PHP pe 20 octombrie 2026

Anunțul prealabil, semnat de Jakub Zelenka pe lista oficială php.announce, programa lansarea pentru miercuri, 21 octombrie 2026, la ora 14:00 UTC, adică 17:00 ora României. Textul preciza că echipa își rezervă dreptul de a publica mai devreme dacă detaliile devin publice sau dacă apar dovezi de exploatare activă.

Exact asta s-a întâmplat. Conform cronologiei publicate de PHP Foundation, lansarea fusese planificată inițial pentru 22 octombrie și a fost adusă cu o zi mai devreme, după ce identificatorii CVE au apărut pe forumuri și rețele sociale pe 20 octombrie, în jurul orei 15:00 UTC.

Pachetele corectate au ieșit în final înainte de ora anunțată. CERT-EU notează ora 13:30 UTC, iar CloudLinux consemnează publicarea avizului complet la 13:50 UTC.

Avizul CERT-EU 2026-018

Echipa de răspuns la incidente a instituțiilor europene a publicat avizul de securitate 2026-018, „Critical Vulnerabilities in PHP”, pe 21 octombrie, cu o actualizare (v1.1) în aceeași zi. Avizul leagă cele două vulnerabilități de CVE-2026-109618 și CVE-2026-109619 și avertizează asupra execuției de cod la distanță fără autentificare.

CERT-EU mai menționează că circulă public cod de tip proof of concept, ceea ce crește probabilitatea atacurilor. Recomandarea principală este actualizarea imediată, iar acolo unde nu se poate, izolarea aplicațiilor expuse la internet până la aplicarea și verificarea corecției.

Cum funcționează cele două vulnerabilități

Ambele probleme stau în gestionarea memoriei și a erorilor din nucleul PHP, cod prin care trece aproape fiecare cerere web. Asta explică de ce nu contează ce aplicație rulați: WordPress, Laravel, PrestaShop sau un script scris de mână sunt la fel de expuse.

CVE-2026-109618: corupere de memorie la epuizarea memoriei

Când o cerere depășește valoarea memory_limit, PHP o oprește brusc. Dacă oprirea are loc exact când datele interne ale cererii sunt inițializate doar pe jumătate, de exemplu în timpul procesării unui fișier încărcat, etapa de curățare tratează acele date ca fiind valide.

Rezultatul este eliberarea unei zone de memorie neinițializate, care poate conține date controlate de atacator. Pe Apache cu mod_php, PHP Foundation confirmă că execuția de cod a fost demonstrată cu setările implicite, printr-o singură cerere trimisă înainte să ruleze vreo linie din aplicație.

CVE-2026-109619: stare globală rămasă după o eroare fatală

O eroare fatală apărută într-un moment nepotrivit poate lăsa în urmă o referință spre memorie care aparținea cererii anterioare. Următoarea cerere servită de același proces (worker) poate folosi acea memorie deja eliberată, o eroare de tip use-after-free.

Avizul PHP confirmă ca impact și scurgerea de date din memorie, iar cercetătorul care a raportat problema a demonstrat execuția de cod pe o aplicație reală, tot pe Apache cu mod_php.

Ce servere și ce versiuni sunt afectate

Conform avizului PHP preluat de CERT-EU, este expusă orice instalare care servește cereri web, indiferent de modul de rulare:

• PHP-FPM, configurația cea mai des întâlnită pe serverele actuale;
• Apache cu mod_php, considerată varianta cu riscul cel mai mare;
• php-cgi;
• FrankenPHP;
• LiteSpeed, folosit de multe firme de găzduire din România.

Pe ramurile întreținute oficial, versiunile corectate sunt:

1. PHP 8.5: actualizați la 8.5.12;
2. PHP 8.4: actualizați la 8.4.27;
3. PHP 8.3: actualizați la 8.3.36;
4. PHP 8.2: actualizați la 8.2.35 (ramura ajunge la sfârșitul suportului pe 31 decembrie 2026).

Pentru PHP 7.4, 8.0 și 8.1 nu există versiuni oficiale noi, dar echipa de securitate a publicat corecții minimale în codul sursă, pentru cine compilează singur. Tenable notează că, după analiza Calif, cel mai vechi cod afectat datează din PHP 5.4.0, deci ramurile 5.4 până la 7.3 rămân vulnerabile fără nicio corecție de la proiectul PHP.

Există atacuri reale?

Da, iar ele au început înainte de publicarea corecțiilor. Tenable citează Amazon Threat Intelligence, care a observat o primă tentativă pe 17 octombrie, cu patru zile înainte de anunț, în rețeaua sa de capcane MadPot.

Pe 21 octombrie au apărut tentative noi, cu încărcături care sugerează mai mulți atacatori, iar Cloudflare și watchTowr au raportat la rândul lor încercări de exploatare. Amazon recomandă ca investigarea jurnalelor să înceapă de la data de 17 octombrie.

Scorul de 10,0 care a circulat pe rețelele sociale înainte de lansare este greșit, după cum precizează PHP Foundation. Scorul oficial rămâne 9,2 pentru ambele vulnerabilități.

Cum verificați versiunea PHP a site-ului

Pe găzduirea partajată cu cPanel, deschideți MultiPHP Manager și vedeți ce versiune folosește fiecare domeniu. Pașii sunt descriși în ghidul nostru despre cum modificați versiunea PHP pentru un domeniu în cPanel.

Numărul de versiune afișat în cPanel nu spune însă tot. Pe serverele cu CloudLinux, pachetele pot primi corecția fără ca numărul să crească, așa că verificarea sigură se face în istoricul pachetului.

Dacă aveți acces SSH pe un server cu cPanel, comenzile de mai jos arată versiunea fiecărei instalări EasyApache și dacă pachetul conține corecția:

for v in /opt/cpanel/ea-php*/root/usr/bin/php; do
  echo "$v: $($v -r 'echo PHP_VERSION;')"
done

rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'

Pe un server Ubuntu sau Debian cu PHP din pachetele distribuției, verificarea și actualizarea arată așa:

php -v
sudo apt update && sudo apt list --upgradable | grep php
sudo apt upgrade
sudo systemctl restart php8.3-fpm

Pe serverul pe care găzduim goai.ro și site-urile proiectelor noastre, verificarea din 22 octombrie 2026 a arătat PHP 8.2.35, 8.3.36, 8.4.27 și 8.5.12, iar toate domeniile configurate rulează pe una dintre aceste ramuri.

Actualizarea pe servere cu cPanel și CloudLinux

CloudLinux a anunțat pe 21 octombrie că pachetele ea-php corectate, de la ea-php52 până la ea-php85, sunt disponibile pentru CloudLinux 7, 8, 9 și 10. Pachetele alt-php au ajuns în depozitele stabile pe 22 octombrie, la 01:25 UTC.

Pe un VPS sau un server dedicat cu cPanel, administratorul rulează:

yum clean all
yum update "ea-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Repornirea serviciilor contează, fiindcă procesele PHP deja pornite păstrează în memorie codul vechi. Pe găzduirea partajată nu aveți acces la aceste comenzi, așa că întrebați furnizorul dacă a aplicat actualizarea și a repornit PHP.

Imunify360, prezent pe multe servere cu cPanel, a primit reguli de firewall pentru exploitul public începând cu setul 8.83, din 21 octombrie, 09:08 UTC. Setul 8.83 nu acoperă însă calea din CVE-2026-109618, iar pe LiteSpeed prima regulă doar înregistrează cererile, deci regulile reduc riscul fără să înlocuiască actualizarea.

Măsuri temporare, dacă nu puteți actualiza imediat

Echipa PHP spune explicit că doar actualizarea elimină complet problema. Măsurile de mai jos reduc expunerea până la actualizare și se aplică în php.ini sau în configurația pool-ului FPM, nu prin ini_set() sau .user.ini:

• pentru CVE-2026-109619: session.upload_progress.enabled=0, urmat de repornirea tuturor proceselor PHP;
• pe PHP 8.5, tot pentru CVE-2026-109619: fatal_error_backtraces=0;
• pentru CVE-2026-109618: memory_limit=-1, setat ca php_admin_value ca aplicațiile să nu îl poată suprascrie;
• post_max_size de 8M dacă site-ul nu primește fișiere sau 32M dacă primește, cu upload_max_filesize mai mic decât această valoare;
• limite de memorie la nivel de container sau cgroup, nu prin RLIMIT_AS sau RLIMIT_DATA, care pot declanșa chiar eroarea vulnerabilă.

Un exemplu pentru un pool PHP-FPM:

php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 16M

Atenție la memory_limit=-1: un script scăpat de sub control poate consuma toată memoria serverului, de aceea PHP recomandă limita prin container. Regulile WAF din Cloudflare sau din mod_security ajută doar pentru traficul care trece prin ele.

Ce verificați după actualizare

Dacă serverul a rulat o versiune vulnerabilă după 17 octombrie, merită verificat dacă nu cumva a fost deja compromis. O listă scurtă de verificări:

1. căutați în jurnalele de acces și de erori cereri POST neobișnuite de tip multipart, mai ales cele cu câmpul de progres al încărcării sesiunii;
2. urmăriți procesele PHP care se opresc repetat cu erori de memorie sau segmentation fault, semn posibil de încercări de exploatare;
3. verificați fișierele PHP noi sau modificate recent în directoarele de încărcări și în rădăcina site-ului;
4. schimbați parolele bazei de date și cheile din fișierele de configurare dacă găsiți orice urmă suspectă;
5. pe WordPress, rulați o scanare de malware și comparați nucleul cu versiunea oficială.

Dacă găsiți semne de compromitere, urmați pașii din ghidul despre ce faceți când site-ul este atacat. Restaurarea dintr-o copie de siguranță făcută înainte de 17 octombrie, urmată imediat de actualizarea PHP, este de multe ori calea cea mai curată.

De ce contează și pentru SEO

Un site compromis prin PHP2Shell poate primi pagini de spam injectate, redirecționări ascunse spre alte domenii sau cod care infectează vizitatorii. Google marchează astfel de site-uri cu avertismente în rezultate, iar Search Console afișează probleme de securitate care pot scoate pagini din index.

Recuperarea după un astfel de incident durează săptămâni, chiar după curățare. De aceea, versiunea PHP intră la noi în fiecare audit SEO și în verificările de SEO tehnic, alături de antetele de securitate pe care le puteți testa gratuit cu Security Headers Scanner.

Dacă nu știți pe ce versiune PHP rulează site-ul sau dacă furnizorul de găzduire nu vă răspunde, scrieți-ne și verificăm împreună serverul. Pentru actualizarea în siguranță a aplicației după schimbarea versiunii PHP, vedeți și ghidul despre actualizarea WordPress, a temelor și a pluginurilor.