Un site poate avea Drupal, WordPress sau Joomla actualizat și totuși să fie vulnerabil din cauza versiunii PHP pe care rulează. PHP2Shell desemnează două vulnerabilități critice în motorul PHP, cu un scor CVSS de 9,2, pentru care au fost publicate remedieri pe 21 octombrie 2026. Sursa: PHP Foundation.
Cum apare problema
Ambele vulnerabilități țin de gestionarea memoriei:
- CVE-2026-109618: epuizarea memoriei poate întrerupe PHP când structurile interne sunt doar parțial inițializate. Procesarea lor ulterioară poate corupe memoria.
- CVE-2026-109619: o cerere poate lăsa în urmă referințe către memorie eliberată, pe care o cerere ulterioară le folosește din nou.
În anumite condiții, un atacator fără cont poate executa cod cu drepturile procesului web sau poate accesa date sensibile din memorie. Problema este în PHP, deci poate afecta și aplicații proprii. Surse: avertizarea OOM, starea globală, PHP2Shell.
Poate oricine să atace un site cu ajutorul AI?
Serviciile AI publice au filtre și mecanisme menite să blocheze folosirea lor pentru atacuri informatice. Un utilizator fără pregătire IT sau un „vibe coder” nu dobândește automat capacitatea de a exploata PHP2Shell doar pentru că are acces la un chatbot. Exemplu: mecanismele de protecție Anthropic.
Dezvoltarea și adaptarea unei exploatări la un server concret implică înțelegerea PHP, a memoriei și a configurației țintei. Persoanele cu experiență pot combina această expertiză cu instrumente specializate, inclusiv sisteme AI personalizate. Totuși, un AI propriu nu este o condiție obligatorie, iar barierele serviciilor publice nu sunt o garanție absolută. Cercetarea Wiz.
Pentru proprietarul unui blog personal, existența vulnerabilității nu înseamnă automat că cineva îl urmărește. Un atac personalizat presupune motivație, timp și resurse; instituțiile guvernamentale și persoanele cu vizibilitate pot prezenta interes pentru astfel de operațiuni. Nu avem însă date care să arate că ele sunt principalele ținte PHP2Shell. Un site mic poate fi găsit și automat, de aceea actualizarea rămâne necesară.
Cum o remediezi
Actualizează PHP, apoi repornește serviciile și workerii care îl folosesc. Primele versiuni corectate sunt:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
Poți instala și versiuni ulterioare care includ remedierea. Pentru pachetele Linux cu patch-uri aplicate prin backport, verifică buletinul furnizorului. Sursa: PHP.
Pași în funcție de server
Atenție: fă aceste intervenții doar dacă ai experiență în administrarea serverelor. Actualizările și repornirile pot întrerupe site-urile găzduite. Pregătește un backup verificat și testează compatibilitatea. Dacă nu ești sigur, cere ajutorul administratorului sau furnizorului de hosting.
cPanel / WHM
În cPanel → MultiPHP Manager, selectează domeniul, alege o ramură PHP compatibilă și corectată, apoi apasă Apply. Alegerea „8.4” nu confirmă singură instalarea patch-ului: administratorul trebuie să verifice pachetul complet. În WHM → EasyApache 4 se gestionează instalările PHP; actualizează pachetele și repornește serviciile PHP relevante. Fără acces WHM, cere furnizorului confirmarea remedierii ambelor CVE-uri. Documentație: MultiPHP Manager, EasyApache 4.
Linux: Ubuntu / Debian și AlmaLinux
Pe Ubuntu/Debian, actualizează prin APT toate pachetele PHP instalate pentru ramura folosită, inclusiv extensiile. Repornește serviciul PHP-FPM corespunzător; dacă folosești Apache cu mod_php, repornește Apache. Numele pachetelor și serviciilor depind de instalare. Documentație Ubuntu.
Pentru pachetele standard AlmaLinux, furnizorul recomandă:
sudo dnf upgrade 'php*'sudo systemctl restart php-fpm
Cu mod_php, repornește httpd în locul PHP-FPM. Pentru instalări cu prefixe sau alte distribuții RHEL, adaptează comenzile după documentația furnizorului. Confirmă patch-ul din buletinul distribuției: versiunea de bază poate rămâne aceeași datorită backport-ului. Instrucțiuni AlmaLinux.
Docker și alte panouri de hosting
În Docker, alege o imagine care include remedierea, descarc-o sau reconstruiește imaginea proprie cu baza actualizată, apoi recreează containerele. Un simplu restart păstrează imaginea veche. Documentație: build, recrearea containerelor.
În Plesk, verifică versiunea atribuită domeniului în PHP Settings și cere administratorului actualizarea runtime-ului dacă versiunea corectată lipsește. Pe hosting administrat, solicită confirmarea aplicării patch-urilor pentru ambele CVE-uri. Documentație Plesk.
După intervenție, verifică PHP-ul folosit efectiv de serverul web, care poate diferi de cel din terminal, și testează autentificarea, formularele și uploadurile pe fiecare instanță.
Actualizarea CMS-ului singură nu actualizează PHP. Un WAF sau modificările temporare de configurare pot reduce unele riscuri, dar nu înlocuiesc patch-ul. Sursa: recomandările PHP2Shell.