PHP2Shell 2026: vulnerabilități critice în PHP, execuție de cod la distanță și ghid complet de protecție

1. Ce este PHP2Shell și de ce este atât de important?

PHP este unul dintre cele mai utilizate limbaje pentru aplicații web, inclusiv WordPress, WooCommerce, Laravel, Magento și numeroase panouri de administrare. În mod obișnuit, vulnerabilitățile unei aplicații apar în pluginuri, teme sau codul proiectului. PHP2Shell este diferit: defectele se află în runtime-ul PHP, adică în componenta care interpretează și execută codul PHP.

Prin urmare, un website cu aplicația și extensiile actualizate poate rămâne expus dacă rulează pe un PHP vulnerabil. De asemenea, schimbarea parolelor sau actualizarea unui plugin nu repară o problemă de corupere a memoriei din interpreter.

Atacul nu înseamnă că fiecare server vulnerabil poate fi compromis automat prin orice cerere. Exploatarea practică depinde de versiunea PHP, de SAPI-ul utilizat, de fluxul de procesare a cererilor, de configurația memoriei și de posibilitatea atacatorului de a influența starea procesului. Totuși, impactul potențial este suficient de grav încât actualizarea trebuie tratată ca prioritate operațională.

2. Identificatorii CVE și mecanismele tehnice

CVE-2026-109618: coruperea stării memoriei în condiții de out-of-memory

PHP utilizează mecanisme interne de întrerupere a execuției atunci când o alocare de memorie eșuează. În anumite trasee de procesare a unei cereri, o astfel de întrerupere poate surveni înainte ca unele structuri interne să fie complet inițializate. La închiderea cererii, rutina de curățare poate accesa acea stare invalidă. Consecințele posibile includ terminarea anormală a procesului și, în scenarii exploatabile, executarea de cod neautorizat.

Problema este legată de gestionarea internă a memoriei, nu de o simplă depășire benignă a limitei memory_limit. Reducerea limitei de memorie nu este, prin ea însăși, o soluție de securitate și poate produce efecte operaționale nedorite.

CVE-2026-109619: referințe către memorie deja eliberată

A doua vulnerabilitate implică păstrarea unor referințe către zone de memorie aferente unei cereri deja încheiate. Dacă un proces PHP reutilizează ulterior aceste referințe, poate apărea o condiție de tip use-after-free. În anumite circumstanțe, aceasta poate permite citirea datelor din memorie sau manipularea fluxului de execuție.

Caracterul persistent al unor procese PHP și modul în care sunt reutilizate resursele între cereri influențează expunerea. Nu toate arhitecturile sunt afectate identic, iar o evaluare corectă trebuie făcută pe configurația reală a serverului.

CVE-2026-115560: problemă asociată, dar distinctă

La 23 octombrie 2026 a fost semnalată și CVE-2026-115560, asociată funcționalității PHP de monitorizare a progresului încărcărilor de fișiere în sesiuni. Aceasta trebuie urmărită separat de cele două CVE-uri inițiale. Potrivit actualizării publicate de Cloudflare, problema putea afecta inclusiv versiunile care primiseră deja remedierile pentru primele două vulnerabilități, precum PHP 8.5.12. Verifică avizul oficial și disponibilitatea unui patch suplimentar pentru distribuția folosită; nu presupune că rezolvarea primelor două CVE-uri acoperă automat și această problemă.

3. Ce versiuni PHP sunt afectate?

Proiectul PHP a publicat versiuni de securitate la 21 octombrie 2026. Pentru ramurile oficiale vizate de cele două CVE-uri inițiale, pragurile de remediere sunt:

Important: tabelul indică versiunile upstream și nu poate substitui verificarea pachetelor furnizate de Red Hat, AlmaLinux, Rocky Linux, Ubuntu, Debian, cPanel, Plesk sau un furnizor de hosting. Distribuitorii pot aplica patch-uri prin backport și pot păstra numărul de versiune de bază. Pentru pachetele Enterprise, consultă avizul de securitate și versiunea exactă a pachetului instalat.

4. Ce servere și aplicații sunt expuse?

Suprafața de atac cuprinde serverele care procesează cereri HTTP neîncredere printr-o instalare PHP vulnerabilă. În această categorie pot intra website-uri WordPress, magazine WooCommerce, aplicații Laravel, interfețe administrative PHP, API-uri și aplicații PHP containerizate.

PHP-FPM versus Apache mod_php

Modul de integrare a PHP cu serverul web este relevant. Apache mod_php și PHP-FPM au fluxuri diferite de inițializare și închidere a cererilor. Red Hat notează că anumite căi de exploatare sunt mai dificile în configurațiile implicite PHP-FPM de pe RHEL 8 și ulterior, în timp ce configurațiile mod_php pot prezenta un risc mai ridicat. Această diferență nu înseamnă că PHP-FPM este imun și nu justifică amânarea actualizărilor.

Nginx, LiteSpeed, OpenLiteSpeed și panouri de control

Nginx transmite de regulă cererile PHP către PHP-FPM; LiteSpeed și OpenLiteSpeed pot folosi alte mecanisme de integrare. În toate cazurile, verificarea trebuie să urmărească binary-ul PHP care deservește efectiv fiecare domeniu, nu doar versiunea implicită afișată de terminal.

Panourile precum aaPanel, cPanel/WHM și Plesk pot administra mai multe versiuni PHP simultan. Este posibil ca PHP-ul CLI, PHP-ul unui website și PHP-ul intern al panoului să fie diferite. Plesk a publicat inclusiv un aviz separat pentru propriile componente PHP și pentru motorul interfeței sale.

WordPress și Laravel

Nu există o condiție care să impună existența unui plugin WordPress vulnerabil sau a unei dependențe Laravel vulnerabile. Dacă cererea ajunge la un runtime PHP afectat și sunt îndeplinite condițiile exploatării, aplicația poate deveni o cale de expunere. Actualizarea WordPress, Composer sau a extensiilor rămâne necesară pentru alte probleme de securitate, dar nu înlocuiește actualizarea PHP.

5. Cum verifici versiunile PHP pe un server Linux

Comenzile de mai jos sunt pentru inventariere și diagnostic. Nu încearcă exploatarea vulnerabilităților.

Versiunea PHP disponibilă în terminal

php -v
command -v php
php --ini
php -i | grep -E 'Server API|Loaded Configuration File|memory_limit|session.upload_progress'

Rezultatul php -v arată doar versiunea executabilului din PATH. Nu confirmă versiunea folosită de fiecare website.

Inventarierea serviciilor și proceselor PHP

ps aux | grep -E '[p]hp-fpm|[l]sphp|[h]ttpd|[a]pache2'
systemctl list-units --type=service --all | grep -Ei 'php|lsws|httpd|apache|nginx'

Distribuții RPM: AlmaLinux, Rocky Linux, RHEL

rpm -qa | grep -Ei '(^php|php-fpm|ea-php|alt-php)' | sort
dnf updateinfo list security 2>/dev/null | grep -i php

Pachetele PHP instalate prin aaPanel sau din surse independente pot să nu apară în lista RPM. Verifică și interfața panoului, directoarele instalării și procesele active.

Distribuții DEB: Ubuntu și Debian

dpkg -l | grep -E '^ii +php|^ii +libapache2-mod-php'
apt list --upgradable 2>/dev/null | grep -i php

Containere Docker

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.CreatedSince}}'

Inspectează versiunea PHP în fiecare container relevant, folosind docker exec NUME_CONTAINER php -v dacă executabilul există. Eticheta unei imagini Docker nu dovedește singură că imaginea locală a fost reconstruită cu patch-ul recent.

Verificarea setărilor PHP pentru upload progress

php -i | grep -Ei 'session.upload_progress.enabled|session.upload_progress.name|session.upload_progress.freq'
php --ini

Setările afișate de CLI pot fi diferite de cele ale PHP-FPM sau ale pool-ului unui domeniu. Verifică configurația web reală înainte de orice schimbare. Dezactivarea unei funcționalități poate reduce expunerea în anumite scenarii, dar nu trebuie tratată ca remediere universală.

6. Cum actualizezi în siguranță PHP

Pasul 1: inventar și backup

Notează versiunile și handler-ele PHP ale fiecărui domeniu, modulele încărcate, fișierele php.ini, configurațiile PHP-FPM, dependențele aplicațiilor și starea actuală a serviciilor. Creează un backup verificabil al fișierelor și bazelor de date și asigură-te că ai o procedură de revenire.

Pasul 2: actualizare din sursa corectă

Folosește depozitul oficial al distribuției sau mecanismul de actualizare al panoului care administrează instalarea PHP. Evită să înlocuiești manual binarele unei instalări gestionate de un panou: poți provoca incompatibilități cu extensiile, cu PHP-FPM sau cu actualizările ulterioare.

Pe sisteme RPM sau DEB, comenzile uzuale pentru consultarea actualizărilor sunt:

# AlmaLinux / Rocky Linux / RHEL: inspectează actualizările disponibile
sudo dnf check-update

# Ubuntu / Debian: actualizează indexul și inspectează pachetele
sudo apt update
apt list --upgradable

Aplică actualizarea conform avizului distribuției și verifică dacă versiunea instalată conține remedierea, inclusiv când aceasta a fost backportată.

Pasul 3: repornirea controlată a proceselor PHP

După actualizare, procesele PHP vechi pot rămâne în memorie până la repornire. Repornește controlat serviciul sau pool-ul PHP relevant, într-o fereastră de mentenanță, după identificarea numelui său exact. Nu presupune că toate serverele folosesc un serviciu numit php-fpm.

Pasul 4: verificare funcțională

• Confirmă versiunea PHP folosită efectiv de website, nu doar de CLI.
• Testează autentificarea, formularele, încărcările de fișiere, plățile și sarcinile cron.
• Verifică extensiile PHP, conexiunile la baze de date și integrarea Redis.
• Urmărește erorile 5xx și logurile PHP-FPM după repornire.
• Elimină fișierele temporare de diagnostic care ar putea dezvălui configurația serverului.

7. Ce rol au Cloudflare WAF, firewall-ul și limitarea cererilor?

Cloudflare a anunțat reguli WAF pentru încercările cunoscute de exploatare PHP2Shell. Acestea pot reduce riscul imediat și sunt utile în perioada dintre descoperirea unei probleme și instalarea patch-ului. Totuși, o regulă WAF filtrează modele de trafic cunoscute; nu repară structurile de memorie ale PHP și nu garantează blocarea tuturor variantelor de atac.

Pentru vulnerabilitatea asociată CVE-2026-115560, Cloudflare a precizat că protecția publicată depinde de folosirea numelui implicit al câmpului pentru progresul încărcării. Administratorii care au personalizat această setare trebuie să verifice separat acoperirea regulii.

Ca măsuri complementare, recomandăm:

• menținerea regulilor WAF administrate și monitorizarea evenimentelor blocate;
• limitarea accesului direct la IP-ul origin atunci când arhitectura permite;
• restricționarea endpoint-urilor de administrare și a upload-urilor neutilizate;
• rate limiting și limite rezonabile pentru dimensiunea cererilor;
• separarea aplicațiilor prin utilizatori, pool-uri PHP și permisiuni minime;
• actualizarea sistemului de operare și a componentelor de hosting.

Nu confunda mitigarea cu remedierea: patch-ul furnizorului rămâne măsura principală.

8. Cum identifici tentativele de exploatare și posibilele compromiteri?

F5 Labs a observat activitate de scanare legată de PHP2Shell înainte de divulgarea oficială, iar ulterior au apărut raportări privind exploatarea în atacuri reale. Nu orice cerere multipart sau eroare 500 reprezintă un atac; analiza trebuie să coreleze mai multe indicii.

Indicatori de investigat

• creșteri bruște ale cererilor POST și ale traficului către endpoint-uri PHP;
• cereri neobișnuit de mari, anomalii de upload și coduri HTTP 500/502/503;
• terminări repetate ale proceselor PHP, mesaje de tip segmentation fault sau out of memory;
• procese neașteptate lansate de utilizatorul serverului web;
• fișiere PHP necunoscute în directoare de upload sau modificări inexplicabile în aplicație;
• conexiuni externe neobișnuite inițiate de procesele PHP.

Comenzi de investigație, fără modificări

# Mesaje de kernel despre procese terminate sau erori de memorie
journalctl -k --since '2026-10-20' | grep -Ei 'segfault|out of memory|oom|php'

# Erori ale serviciilor PHP (adaptează numele serviciului)
journalctl --since '2026-10-20' | grep -Ei 'php-fpm|lsphp|segfault|child exited' | tail -100

# Fișiere PHP modificate recent în directorul aplicației
find /cale/catre/site -type f -name '*.php' -mtime -7 -print

# Procese și conexiuni de rețea
ps auxf
ss -tunap

Adaptează intervalul și calea website-ului. O modificare recentă poate fi legitimă, iar absența unui indicator din loguri nu demonstrează absența unei compromiteri. Dacă există suspiciuni serioase, păstrează probele și evită ștergerea prematură a jurnalelor.

9. Ce faci dacă serverul ar fi putut fi compromis?

1. Izolează controlat sistemul: restricționează accesul extern sau scoate temporar din trafic instanța afectată, ținând cont de continuitatea serviciului.
2. Păstrează dovezile: snapshot-uri, loguri web, jurnale PHP, evenimente WAF, lista proceselor și conexiunilor.
3. Identifică domeniul compromiterii: utilizatorii afectați, fișierele modificate, accesul la baze de date și cheile disponibile procesului PHP.
4. Actualizează PHP și celelalte componente pe o instanță verificată sau reconstruiește sistemul dintr-o sursă de încredere.
5. Rotește secretele expuse: parole, chei API, credențiale de baze de date, tokenuri și chei de acces, în funcție de evaluarea incidentului.
6. Restaurează și monitorizează: validează integritatea aplicației și urmărește eventuale tentative ulterioare.

În cazul unui incident confirmat, simpla actualizare PHP nu elimină automat eventualele mecanisme de persistență instalate de un atacator.

10. Întrebări frecvente despre PHP2Shell

PHP2Shell afectează toate website-urile WordPress?

Nu în mod automat. Expunerea depinde de versiunea și configurația PHP care deservește site-ul. WordPress nu trebuie să aibă un plugin vulnerabil pentru ca un defect din runtime să fie relevant.

Dacă folosesc Nginx și PHP-FPM sunt protejat?

Nu există o garanție generală. Unele căi de exploatare pot fi mai dificile în anumite configurații PHP-FPM, dar actualizarea runtime-ului rămâne necesară.

Cloudflare WAF rezolvă vulnerabilitatea?

Nu. WAF-ul poate bloca încercări cunoscute și poate reduce expunerea, însă remedierea defectului din PHP necesită un patch.

Este suficient să rulez php -v?

Nu. Comanda verifică PHP CLI. Pe același server pot exista versiuni separate pentru fiecare domeniu, pentru panoul de control și pentru containere.

PHP 8.4.27 este sigur în raport cu toate problemele PHP2Shell?

PHP 8.4.27 conține remedierea celor două CVE-uri inițiale. Totuși, vulnerabilitatea asociată CVE-2026-115560 a fost comunicată ulterior; urmărește patch-urile și avizele suplimentare pentru această problemă distinctă.

Un server fără PHP poate fi afectat?

Nu de aceste defecte din runtime-ul PHP dacă PHP nu este instalat și nici folosit pentru procesarea cererilor. Rămân relevante celelalte vulnerabilități ale infrastructurii.

11. Checklist pentru administratorii de servere

• ☐ Am inventariat toate versiunile PHP, inclusiv cele din panouri și containere.
• ☐ Am identificat SAPI-ul și pool-ul PHP pentru fiecare website.
• ☐ Am verificat avizele de securitate ale furnizorului și patch-urile backportate.
• ☐ Am instalat remedierea pentru CVE-2026-109618 și CVE-2026-109619.
• ☐ Am verificat separat starea CVE-2026-115560.
• ☐ Am repornit controlat procesele care utilizau binarele vechi.
• ☐ Am testat aplicațiile, upload-urile, joburile și extensiile PHP.
• ☐ Am verificat logurile pentru anomalii și evenimente suspecte.
• ☐ Am menținut protecțiile WAF și am restricționat accesul la origin.
• ☐ Am documentat modificările și planul de răspuns la incidente.

Concluzie: PHP2Shell arată de ce securitatea începe sub nivelul aplicației

PHP2Shell este un exemplu important de vulnerabilitate în care actualizarea codului aplicației nu este suficientă. Defectele din gestionarea memoriei PHP pot afecta mai multe website-uri găzduite pe aceeași infrastructură, chiar dacă acestea folosesc framework-uri și pluginuri diferite.

Prioritatea este identificarea instalărilor PHP reale, aplicarea patch-urilor furnizorului, verificarea funcționării serviciilor și monitorizarea semnelor de exploatare. WAF-ul, izolarea proceselor și restricțiile de acces sunt straturi suplimentare de apărare, nu alternative la actualizare.

LinuxPedia recomandă administratorilor să trateze PHP2Shell ca pe un incident de management al vulnerabilităților la nivel de infrastructură: inventar complet, remediere documentată, verificare și monitorizare continuă.

Surse oficiale și analiză tehnică

1. PHP Security Advisory – RCE via OOM corruption
2. PHP.net – PHP 8.4.27 Security Release
3. Red Hat – RHSB-2026-013 PHP2Shell
4. Cloudflare – Protecții WAF pentru PHP2Shell și actualizarea CVE-2026-115560
5. Docker – Impactul PHP2Shell asupra imaginilor container
6. F5 Labs – Observații privind tentativele de exploatare
7. Plesk – Versiuni afectate și remedieri

Notă editorială: informațiile reflectă avizele publice consultate la 30 octombrie 2026. Situația patch-urilor și a exploatărilor poate evolua; pentru decizii operaționale, verifică întotdeauna avizele actualizate ale furnizorului.