PHP2Shell: două vulnerabilități critice în PHP permit preluarea serverelor fără autentificare. Actualizează la 8.2.35, 8.3.36, 8.4.27 sau 8.5.12

Echipa PHP a lansat pe 21 octombrie 2026 versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Ele corectează două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, prin care un atacator poate rula cod pe server fără să fie autentificat. Ambele au scorul 9,2 din 10 pe scala CVSS v4.0. Problema e în interpretorul PHP, nu într-o aplicație anume, deci sunt expuse și site-urile WordPress, Drupal, Joomla sau magazinele online care rulează pe o versiune veche.

Lansarea era programată la 14:00 UTC (17:00, ora României), dar a venit cu câteva minute mai devreme, la 13:52 UTC. Detaliile scăpaseră deja pe 20 octombrie, înainte de publicarea coordonată, iar lanțul de atac circulă sub numele „PHP2Shell”. În aceeași dimineață au apărut și primele atacuri.

Ce versiuni trebuie instalate

Conform analizei Wiz Research, citată de Patchstack, cel puțin una dintre cele două probleme afectează toate versiunile de la PHP 5.4 încoace. Cine rulează încă PHP 7.x sau 5.x pe un server public are acum un motiv urgent să treacă la o ramură suportată.

Cum funcționează cele două atacuri

CVE-2026-109618 („RCE via OOM corruption”) pornește de la felul în care PHP iese dintr-o cerere când rămâne fără memorie. Cu o cerere de tip multipart (cea folosită la formularele cu fișiere) construită special, atacatorul împinge procesul în eroarea de memorie insuficientă chiar în timp ce PHP pregătește cererea. Memoria rămâne într-o stare invalidă, iar codul care închide cererea o folosește apoi. Avizul oficial confirmă execuția de cod de la distanță pe Apache cu mod_php, cu limitele implicite. Pentru PHP-FPM și FrankenPHP, analiza codului sugerează că sunt vulnerabile, dar nu s-a demonstrat încă un atac complet.

CVE-2026-109619 („RCE via stale global state”) exploatează date rămase de la o cerere anterioară în același proces PHP: stări de eroare, de sesiune sau ale extensiilor care indică spre memorie deja eliberată. Dacă o cerere e întreruptă de o eroare fatală, de lipsa memoriei sau de depășirea timpului de execuție, iar următoarea cerere ajunge în același proces, aceste date pot fi folosite pentru a rula cod. Execuția de cod e confirmată pe mod_php, iar pe PHP-FPM a fost validată prin mecanismul care afișează progresul încărcării fișierelor (session upload progress).

Ambele atacuri sunt marcate ca având complexitate ridicată, iar reușita depinde de configurația serverului. Asta nu le face mai puțin periculoase: cercetătorii de la Wiz au demonstrat execuție de cod fără autentificare pe imaginile de container recente cu WordPress, Drupal și Joomla. Au arătat și că pot citi memoria proceselor PHP, unde se pot afla parole, tokenuri de autentificare și chei API, chiar fără să ruleze cod.

Atacuri deja în desfășurare

Pe 21 octombrie dimineața, înainte de apariția corecturilor, Cloudflare a anunțat că vede primele atacuri și a activat reguli de protecție în firewall-ul său pentru aplicații web. Firme de hosting au raportat la Patchstack mai multe incidente de exploatare activă, iar câteva site-uri au fost oprite preventiv, între ele portalurile guvernamentale olandeze DigiD și MijnOverheid. Pe de altă parte, la 13:57 UTC, telemetria proprie Patchstack arăta doar scanări, fără compromiteri confirmate.

Expunerea e uriașă. PHP rulează pe 69,3% dintre site-urile al căror limbaj de server e cunoscut, potrivit W3Techs, iar 27% dintre acestea folosesc încă PHP 7 și aproape 8% PHP 5. Cercetătorul Silas Cutler, citat de Tenable, estimează peste 1,3 milioane de servere expuse pe internet care ar putea fi vulnerabile. Intră aici și blogurile, magazinele online și site-urile de firme mici construite pe WordPress, foarte răspândite și în România.

Ce trebuie să faci

Dacă ai un site pe hosting partajat (cPanel, Plesk sau un panou similar): întreabă furnizorul dacă a instalat deja versiunea corectată. În WordPress, versiunea PHP se vede în Unelte → Sănătate site → Informații → Server. Dacă panoul de hosting îți permite să alegi versiunea PHP, treci pe o ramură suportată, ideal 8.3 sau 8.4, după ce verifici că temele și modulele sunt compatibile.

Dacă administrezi propriul server:

• Actualizează pachetele PHP. Pe Debian, corecturile sunt deja publicate în depozitele de securitate: 8.2.35-1~deb12u1 pentru Debian 12 (bookworm) și 8.4.27-1~deb13u1 pentru Debian 13 (trixie). Pe alte distribuții, verifică avizul furnizorului, pentru că pachetele pot păstra un număr de versiune mai vechi chiar dacă includ corectura.
• Repornește procesele PHP (php-fpm sau Apache, dacă folosești mod_php). Codul nou nu se încarcă în procesele deja pornite.
• Verifică versiunea care servește efectiv paginile, nu doar pe cea din linia de comandă. php -v poate arăta altă instalare decât cea folosită de site, mai ales pe serverele cu mai multe versiuni PHP.
• Inventariază tot ce rulează PHP: containere Docker, site-uri de test, aplicații care vin cu PHP inclus.

Dacă nu poți actualiza imediat, avizele oficiale recomandă câteva măsuri care reduc riscul, dar nu îl elimină:

• session.upload_progress.enabled=0, urmat de repornirea proceselor. Echipa PHP recomandă să rămână dezactivat și după actualizare, dacă nu ai nevoie de funcție.
• post_max_size și limitele de încărcare cât mai mici, plus limite de dimensiune a cererilor direct în serverul web sau în proxy.
• Pe PHP 8.5: fatal_error_backtraces=0.
• Blocarea cererilor multipart în serverul web, dacă aplicația nu primește fișiere.

Dezvoltatorii PHP insistă însă că setările nu înlocuiesc actualizarea. „Singura soluție este actualizarea PHP”, a spus Gina Peter Banyard, din echipa de bază PHP, citată de Tenable. Dacă bănuiești că serverul a fost deja atacat, tratează-l ca fiind compromis și schimbă parolele și cheile API stocate pe el, pentru că atacul poate citi memoria proceselor. Patchstack recomandă și să eviți „pluginurile de reparare” neoficiale sau bucățile de cod copiate de pe forumuri.

Pentru alte vulnerabilități critice din ultimele săptămâni, vezi Patch Tuesday din octombrie și cele trei zero-day din Ivanti Connect Secure.

Informațiile provin din anunțurile de pe php.net (20 și 21 octombrie 2026: scorul CVSS, versiunile corectate, sfârșitul suportului pentru PHP 8.2, PHP 8.6 RC4), avizele oficiale GHSA-w8hw-w9fx-j79w și GHSA-6wmf-4rv5-p3rp din depozitul php-src (mecanismul atacurilor, configurațiile confirmate, măsurile temporare), Patchstack (cronologia din 21 octombrie, cercetarea Wiz, site-urile olandeze oprite, recomandările de răspuns), Tenable (numele PHP2Shell, declarația Cloudflare, estimarea de 1,3 milioane de servere, declarația din echipa de bază PHP), Qualys (corecturile pentru PHP 7.4–8.1, diferența dintre php -v și instalarea folosită de site), Help Net Security (verificarea versiunii în WordPress), W3Techs (21 octombrie 2026: răspândirea PHP) și Debian Security Tracker (pachetele corectate pentru Debian).