PHP2Shell: două defecte critice în PHP permit executarea de cod pe server; ce faci astăzi

Publicat pe 21 octombrie 2026 · Echipa mitza.es

Pe 21 octombrie 2026, echipa PHP a publicat o actualizare de securitate de urgență pentru a corecta două vulnerabilități critice de execuție de cod la distanță, identificate ca CVE-2026-109618 și CVE-2026-109619 și cunoscute drept „PHP2Shell”. Centrul Național pentru Securitate Cibernetică din Regatul Unit (NCSC) a avertizat că acestea pot permite unui atacator să execute comenzi pe orice server web care folosește PHP. Dacă ai un site în WordPress, PrestaShop, Joomla, Magento sau orice altă dezvoltare în PHP, te privește.

Ce s-a întâmplat

Pe 20 octombrie, detalii despre cele două vulnerabilități au apărut pe internet înainte de divulgarea coordonată, iar firma de securitate watchTowr a confirmat că defectele sunt reale. După scurgere, echipa PHP a devansat publicarea patch-urilor pentru miercuri, 21 octombrie. Pe pagina sa, php.net afișează acum un anunț de securitate despre vulnerabilități critice de execuție de cod la distanță și cere actualizarea.

Ce sunt cele două defecte, pe înțelesul tuturor

• CVE-2026-109618: un defect de corupere a memoriei care apare atunci când PHP rămâne fără memorie în timp ce datele interne ale unei cereri sunt pregătite doar parțial. Curățarea de după aceea tratează aceste date drept valide și, în anumite condiții, poate fi exploatată.
• CVE-2026-109619: starea internă a unei cereri poate supraviețui după eliberarea memoriei sale, iar o cerere ulterioară, deservită de același proces, o poate folosi înainte să fie resetată.

Echipa de securitate PHP le atribuie un scor de 9,2 din 10 în CVSS v4.0. Potrivit NCSC, coruperea memoriei ar permite executarea de cod fără autentificare. Cu alte cuvinte, nu ai nevoie de o parolă și nici de un plugin vulnerabil: defectul se află chiar în motorul PHP.

Cine este afectat

NCSC afirmă că organizațiile care folosesc orice versiune de PHP sunt afectate, iar versiunile vechi sunt cele care îngrijorează cel mai mult. PHP precizează că sunt expuse toate instalările care servesc cereri web, inclusiv PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Potrivit Huntress, există un exploit pentru mod_php în care o singură cerere neautentificată poate declanșa atacul înainte de a rula codul aplicației.

Asta include WordPress, Drupal, Joomla, Magento, PrestaShop și orice dezvoltare PHP la comandă, pentru că defectul se află sub toate acestea. Actualizarea WordPress-ului sau a pluginurilor nu îl rezolvă: trebuie actualizat PHP.

Versiunile corectate și ce se întâmplă cu cele vechi

• PHP 8.5: versiunea 8.5.12.
• PHP 8.4: versiunea 8.4.27.
• PHP 8.3: versiunea 8.3.36.
• PHP 8.2: versiunea 8.2.35.

Pentru 7.4, 8.0 și 8.1, echipa PHP a publicat doar corecturi minime ale codului sursă: sunt ramuri fără suport oficial, așa că, dacă folosești una dintre ele, trebuie să te consulți cu furnizorul tău sau, și mai bine, să treci la o ramură cu suport. Distribuțiile Linux și furnizorii de suport pe termen lung au primit patch-urile înainte de publicare, așa că merită să verifici pachetele lor. La găzduirea partajată, furnizorul de hosting este cel care trebuie să le aplice.

Este deja exploatată?

Sursele nu sunt de acord, așa că, prin prudență, mai bine presupui că da. Huntress a spus că, până în dimineața zilei de 21 octombrie, nu observase exploatare activă la clienții săi. Totuși, directorul tehnic al Cloudflare a afirmat că vedeau atacuri timpurii, watchTowr spune că a reprodus unul dintre defecte, iar cod de exploatare public circulă, deși neverificat. Când o vulnerabilitate critică devine publică și există un exploit, încercările automate de atac încep de obicei în câteva ore.

Ce faci astăzi: lista pentru o firmă mică cu site în PHP

1. Află ce versiune de PHP folosești. O găsești în panoul furnizorului de hosting și, în WordPress, la „Instrumente, Sănătatea site-ului, fila Informații, secțiunea Server”.
2. Întreabă-ți furnizorul de hosting dacă a aplicat deja patch-urile sau actualizează tu la 8.5.12, 8.4.27, 8.3.36 ori 8.2.35 din panou, dacă îți permite. Cere confirmarea în scris.
3. Fă o copie de siguranță înainte să schimbi ceva și testează site-ul după aceea: o schimbare de versiune poate strica pluginurile vechi. Dacă nu ai un sistem de copii de siguranță de încredere, ai ghidul nostru de backup pentru companii.
4. Dacă folosești PHP 8.1 sau o versiune mai veche, planifică migrarea la o ramură cu suport; între timp, nu lăsa serverul respectiv expus fără o protecție suplimentară.
5. Ia în calcul un firewall pentru aplicații web (WAF). Cloudflare a lansat reguli pentru vectorii de atac cunoscuți, disponibile chiar și în planul gratuit, dar acoperă doar traficul care trece prin el și sunt o măsură temporară de atenuare, nu o soluție.
6. Urmărește semnele de compromitere: fișiere noi sau modificate în directorul web, sarcini programate necunoscute, utilizatori noi sau procese ale serverului web care lansează comenzi ciudate.

Și setările din php.ini?

Unele publicații au propus modificarea unor setări de configurare ca măsură de atenuare. Responsabilii PHP o descurajează ca soluție: potrivit Help Net Security, dezvoltatoarea principală Gina Peter Banyard a afirmat că singura atenuare este aplicarea patch-ului sau actualizarea PHP, iar un alt responsabil a exclus că setările de configurare ar fi suficiente. Folosește-le, cel mult, ca măsură de ultim moment cât timp actualizezi.

Dacă nu poți actualiza astăzi

NCSC recomandă inventarierea sistemelor cu PHP, începând cu cele expuse la internet, monitorizarea furnizorilor al căror software include PHP și aplicarea atenuărilor temporare indicate de echipa PHP. Dacă nu este posibil, sfătuiește să iei în calcul deconectarea sistemului până când poate fi atenuat riscul și, dacă nu poți nici actualiza, nici deconecta, să-l evaluezi în căutare de indicii de compromitere. Ai avertizarea completă a NCSC pe site-ul lor.

De ce aduce asta din nou mentenanța în discuție

Defectele de acest tip se rezolvă la fel: cineva trebuie să afle, să testeze și să actualizeze rapid. Site-urile pe care nu le întreține nimeni sunt cele care plătesc prețul, așa cum am văzut cu defectele critice din WordPress din această vară și cu pluginurile exploatate în octombrie. Dacă nu ai pe nimeni care să se ocupe de asta, o mentenanță web continuă sau un audit de securitate web îți spun în ce stare se află site-ul tău înainte să descopere un atacator.