# Ce este PHP2Shell? Vulnerabilitatea explicată simplu

> PHP2Shell explicat simplu: ce se ascunde în spatele celor două vulnerabilități critice PHP, ce servere sunt afectate și ce pași ar trebui să faceți acum.

Sursa: https://phpsos.de/ro/php2shell/was-ist-php2shell/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** PHP2Shell este numele pentru două vulnerabilități critice de securitate în PHP însuși, CVE-2026-109618 și CVE-2026-109619. Prin ele, atacatorii pot executa cod malițios pe servere web vulnerabile, fără autentificare. Remediul este doar actualizarea la o versiune PHP remediată, cu repornirea ulterioară a tuturor proceselor PHP.

## Ce este PHP2Shell?

PHP este limbajul de programare pe care rulează o mare parte dintre site-urile web: pagini de companii cu WordPress sau TYPO3, magazine online cu Shopware sau WooCommerce, portaluri interne și dezvoltări proprii. La 21 octombrie 2026, proiectul PHP a publicat actualizări de securitate pentru două vulnerabilități care au devenit cunoscute sub numele PHP2Shell.

Ambele vulnerabilități sunt evaluate cu CVSS v4.0 9.2, deci drept critice. Consecința este în ambele cazuri aceeași: execuția de cod malițios de la distanță, fără ca atacatorul să trebuiască să se autentifice. Specialiștii vorbesc despre „unauthenticated Remote Code Execution”. Cine poate executa cod pe server poate, în cel mai rău caz, să citească date, să monteze uși dosnice sau să folosească serverul pentru alte atacuri.

Important pentru înțelegere: vulnerabilitatea nu se află într-un anumit CMS sau plugin, ci în PHP. O actualizare a WordPress, Shopware sau TYPO3 nu o închide, așadar.

## De ce este vulnerabilitatea atât de gravă?

Trei puncte fac PHP2Shell deosebit de delicat din perspectiva autorităților de securitate:

- **Amploare:** Sunt afectate modurile uzuale de operare ale PHP, anume PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Palo Alto Networks (Unit 42) a numărat peste 22,6 milioane de instanțe expuse, potențial vulnerabile.
- **Fără autentificare:** Atacatorul nu are nevoie nici de parolă, nici de cont de utilizator.
- **Moment timpuriu:** La Apache cu mod_php a fost demonstrat, potrivit echipei PHP, un exploit înainte ca vreun cod de aplicație să ruleze. Funcțiile de protecție din interiorul site-ului nu mai acționează atunci.

BSI a emis nivelul de avertizare 3 (portocaliu). Recomandă actualizarea imediată și, dacă aceasta nu este posibilă imediat, scoaterea temporară din rețea a serverelor web afectate.

## Ce servere sunt afectate de PHP2Shell?

Vulnerabilitățile sunt remediate în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Stările mai vechi ale acestor ramuri sunt afectate. Pentru PHP 8.1 și versiunile mai vechi nu mai există actualizări oficiale; potrivit presei de specialitate, sunt afectate aproape toate versiunile, până înapoi la PHP 5.4. Prezentarea completă o găsiți pe pagina [Ce versiuni PHP sunt afectate?](https://phpsos.de/ro/php2shell/betroffene-php-versionen/).

O particularitate: distribuțiile Linux și furnizorii de hosting aplică uneori corecțiile ca backport. Atunci Plesk, de exemplu, afișează în continuare 8.2.34, deși eroarea este remediată. Decisive sunt starea pachetului și confirmarea furnizorului. Cum verificați asta explicăm la [Cum verificați corect versiunea PHP și starea patchului](https://phpsos.de/ro/php2shell/php-version-pruefen/).

## Ce este dovedit, ce este deschis?

**Dovedite** sunt cele două numere CVE, versiunile remediate și măsurile provizorii publicate de php.net. La 23 octombrie s-a adăugat o indicație privind o altă vulnerabilitate, CVE-2026-115560, care acționează doar la o configurație neobișnuită.

**Probabil** este că atacatorii caută în continuare activ servere fără patch. Potrivit rapoartelor din presă, o primă tentativă de atac a fost observată deja la 17 octombrie, deci înainte de publicarea patchurilor. Cloudflare a raportat tentative de atac și a implementat reguli de protecție, dar atrage atenția că regulile bazate doar pe datele cererii nu sunt suficiente.

**Deschis** este câte servere au fost deja atacate cu succes. Atacuri reușite confirmate, la scară largă, nu erau cunoscute inițial, potrivit BSI. Nu există Indicators of Compromise publicați și confirmați. Dacă un server a fost afectat se poate evalua, de aceea, doar printr-o analiză a comportamentului. Desfășurarea în timp o rezumă [cronologia de la 17 la 25 octombrie](https://phpsos.de/ro/ratgeber/php2shell-chronologie/).

## Ce ar trebui să facă acum companiile

1. **Clarificați cine este responsabil:** server propriu, server administrat (managed) sau furnizor de hosting.
2. **Actualizați PHP** la o versiune remediată sau la un backport confirmat.
3. **Reporniți toate procesele PHP.** Fișierele noi singure nu sunt suficiente cât timp procese vechi rulează în memorie.
4. **Salvați logurile,** și anume începând cu 20 octombrie. Presa de specialitate recomandă păstrarea acestor date.
5. **Verificați urmele.** Un patch nu elimină software-ul malițios deja introdus și nu dovedește că înainte nu s-a întâmplat nimic. Indicații în acest sens oferă pagina [Am fost deja compromis?](https://phpsos.de/ro/php2shell/bin-ich-gehackt-anzeichen/).

> **Important:**
> O actualizare închide ușa, dar nu face ordine. Dacă serverul dumneavoastră a fost accesibil între 17 octombrie și patch, o verificare a urmelor este o obligație, nu un extra.

## Cum ajută PHP SOS concret?

Prin [asistența de urgență PHP2Shell](https://phpsos.de/ro/leistungen/php2shell-soforthilfe/) preluăm pașii pe care multe companii nu îi pot acoperi pe termen scurt intern:

- **Inventar:** Stabilim versiunea PHP, modul de operare și starea pachetelor pentru fiecare server afectat.
- **Patch sau tranziție:** Aplicăm actualizarea sau, unde nu este încă posibil, setăm măsurile provizorii de la php.net și clarificăm dacă serverul trebuie scos temporar din rețea.
- **Repornire și dovadă:** Repornim toate procesele PHP și documentăm starea dinainte și de după.
- **Verificarea urmelor:** Salvăm logurile începând cu 20 octombrie și verificăm anomaliile, până când incidentul este încheiat și documentat.


## Întrebări frecvente

**Este PHP2Shell o vulnerabilitate WordPress?**  
Nu. Vulnerabilitățile se află în PHP, adică în limbajul de programare pe care rulează WordPress, Shopware, TYPO3 și multe alte sisteme. O actualizare a CMS-ului nu le închide, așadar. Decisivă este starea PHP de pe server.

**Trebuie să fac eu ceva ca client al unui furnizor de hosting?**  
La hostingul partajat, actualizarea PHP o aplică de regulă furnizorul de hosting. Ar trebui totuși să vă faceți confirmat în scris că versiunea PHP folosită de dumneavoastră a fost actualizată și repornită. Dacă înainte de patch s-a întâmplat ceva, actualizarea nu răspunde.

**De unde vine numele PHP2Shell?**  
Numele descrie consecința: prin PHP, un atacator poate obține, în cel mai rău caz, o linie de comandă, adică un shell, pe server. Denumirile oficiale sunt numerele CVE-2026-109618 și CVE-2026-109619.

**Înseamnă că site-ul meu a fost deja atacat dacă a fost scos offline?**  
Nu neapărat. Unii furnizori au scos site-uri din rețea preventiv, așa cum recomandă BSI (Oficiul Federal German pentru Securitatea Informațiilor) atunci când o actualizare nu este posibilă imediat. Este o măsură de protecție și nu o dovadă a unui atac.

## Surse

- [php.net: anunțuri de securitate](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Oficiul Federal German pentru Securitatea Informațiilor](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)