PHP2Shell (CVE-2026-109618/109619): remediere pentru echipele IT

Pe 21 octombrie 2026, echipa PHP a publicat actualizări de urgență pentru două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, numite colectiv „PHP2Shell”. Ambele pot permite unui atacator neautentificat să execute cod pe serverul web, iar singura remediere completă este actualizarea la PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 (ori la pachetul corectat de furnizorul sistemului de operare). Informațiile de mai jos sunt valabile la 21 octombrie 2026 seara; situația evoluează rapid, iar apariția unui exploit public este așteptată în curând.

Pe scurt, fără termeni tehnici, pentru management: versiunea pe înțelesul tuturor

Ce s-a întâmplat

Problemele sunt în interpretorul PHP însuși, deci orice aplicație care rulează pe o versiune vulnerabilă este, în principiu, expusă.

• CVE-2026-109618 („RCE via OOM corruption”): atunci când PHP rămâne fără memorie în timpul procesării unei cereri, execuția poate fi întreruptă în timp ce datele interne ale cererii sunt inițializate doar parțial. La finalul cererii, rutina de curățare poate trata aceste date invalide ca fiind valide, ceea ce duce la coruperea memoriei.
• CVE-2026-109619 („RCE via stale global state”): o stare internă care aparține unei cereri poate supraviețui după ce memoria în care se afla a fost eliberată. O cerere ulterioară, procesată de același worker, poate folosi această stare învechită (o vulnerabilitate de tip use-after-free).

Echipa PHP evaluează ambele vulnerabilități ca fiind critice, cu un scor CVSS v4.0 de 9,2. Unii cercetători au comunicat scoruri mai mari, dar concluzia rămâne: actualizare imediată.

Detaliile s-au scurs pe 20 octombrie, înaintea dezvăluirii coordonate din 22 octombrie, iar echipa PHP a devansat corecturile cu o zi.

Impact

Un atacator poate rula cod pe serverul tău cu drepturile contului sub care funcționează PHP (de exemplu www-data), ceea ce poate însemna:

• citirea fișierelor de configurare, a parolelor de baze de date, a cheilor API și a tokenurilor;
• modificarea sau furtul datelor din aplicație;
• instalarea de webshell-uri și alte mecanisme de persistență;
• folosirea serverului ca punct de plecare pentru atacuri asupra restului rețelei firmei.

Cercetătorii au demonstrat și extragerea de date din memoria procesului PHP, deci informațiile sensibile pot fi expuse chiar și fără execuție de cod.

De ce mod_php este cel mai expus. Potrivit avizului oficial, configurația Apache cu mod_php este cea mai riscantă: exploatarea a fost validată în această configurație cu limitele implicite PHP, iar atacul se produce înainte ca aplicația propriu-zisă să ruleze vreo linie de cod. Cu alte cuvinte, nici o aplicație bine scrisă, nici un CMS actualizat nu te protejează. PHP-FPM, php-cgi, FrankenPHP și LiteSpeed sunt și ele afectate, în funcție de configurație; niciuna nu trebuie considerată sigură.

Sisteme posibil afectate

• servere web care rulează PHP prin PHP-FPM, Apache mod_php, php-cgi, FrankenPHP sau LiteSpeed (LSAPI);
• CMS-uri și aplicații populare construite pe PHP: WordPress, Drupal, Joomla, Magento, aplicații Laravel sau Symfony, Nextcloud, phpMyAdmin;
• paneluri de administrare și hosting care folosesc PHP intern;
• containere Docker construite pe imaginile oficiale php sau pe alte imagini care includ PHP;
• appliance-uri și produse comerciale care conțin PHP integrat (embedded), inclusiv software pentru Windows;
• servicii de shared hosting, unde actualizarea depinde de furnizor;
• versiuni vechi, ieșite din suport (PHP 8.1 și mai vechi), pentru care proiectul PHP nu mai publică actualizări obișnuite.

Ce trebuie făcut acum

1. Fă inventarul. Identifică toate instalările PHP ale firmei tale, începând cu cele expuse la internet: servere, containere, medii de test, paneluri de hosting și produse care includ PHP. Atenție: comanda php -v din linia de comandă nu indică neapărat versiunea care servește traficul web.
2. Actualizează la versiunile corectate: PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35. Dacă folosești pachetele distribuției Linux, aplică actualizarea de securitate a furnizorului; acestea pot păstra un număr de versiune mai vechi, cu corecturile incluse. După actualizare, repornește sau redistribuie workerii și verifică că rulează noua versiune.
3. Pentru PHP 8.1 și mai vechi, cere furnizorului (distribuție, vendor LTS) corecturile portate sau planifică migrarea la o versiune suportată. Evită „patch-urile” sau pluginurile neoficiale.
4. Dacă nu poți actualiza imediat:
   • activează reguli WAF dedicate (de exemplu, Cloudflare a publicat reguli inițiale pentru vectorii cunoscuți) și limitează la nivel de proxy dimensiunea și complexitatea cererilor;
   • aplică măsurile temporare de configurare din avizul oficial PHP, știind că acestea reduc riscul, dar nu îl elimină;
   • restricționează accesul public, pune serviciul în spatele unui VPN sau în mod de mentenanță; dacă nimic din acestea nu e posibil, ia în calcul scoaterea temporară a sistemului din funcțiune;
5. Monitorizează. Urmărește procese neobișnuite pornite de workerii PHP, reporniri neașteptate, erori repetate și trafic anormal.
6. Verifică semnele de compromitere. Caută fișiere noi sau modificate în directoarele web, webshell-uri, sarcini programate (cron) sau conturi noi. Păstrează jurnalele serverului web și ale PHP. Lipsa erorilor din loguri nu dovedește că sistemul e curat.
7. Rotește credențialele stocate pe serverele afectate (parole de baze de date, chei API, secrete) dacă există orice suspiciune de compromitere, având în vedere că memoria procesului putea fi expusă.

Legătura cu NIS2

Dacă firma ta este entitate esențială sau importantă în sensul NIS2, o compromitere de tip RCE pe un sistem expus la internet poate constitui un incident semnificativ care trebuie raportat la DNSC: o avertizare timpurie în cel mult 24 de ore de la constatare și o notificare a incidentului în cel mult 72 de ore. Pregătește de acum persoana de contact și informațiile de bază, ca să nu ratezi termenele.

Cronologie

• 20 octombrie 2026: detaliile vulnerabilităților sunt scurse public înaintea dezvăluirii coordonate; PHP anunță o versiune de securitate de urgență.
• 21 octombrie 2026, dimineața (UTC): Cloudflare raportează primele încercări de atac și publică reguli WAF; unele organizații își scot preventiv serviciile offline.
• 21 octombrie 2026, ~14:00 UTC: PHP publică versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35, plus avizele GHSA-w8hw-w9fx-j79w și GHSA-6wmf-4rv5-p3rp.
• 21 octombrie 2026: Rapid7 estimează apariția curând a unui exploit public; NCSC (Marea Britanie) cere organizațiilor să își inventarieze sistemele PHP, începând cu cele expuse la internet.

Surse

• PHP – anunț de securitate și versiuni: https://www.php.net/
• Avize GitHub php-src: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w și https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• Rapid7: https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
• Huntress: https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
• Qualys: https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities
• NCSC UK: https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• Help Net Security: https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
• Patchstack: https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/

---

Dacă nu știi câte sisteme PHP ai expuse, un inventar rapid al suprafeței de atac e primul pas; ClearSecurity poate ajuta cu asta.