PHP2Shell: patch lansat, ce trebuie sa actualizezi acum

Actualizat pe 21 octombrie 2026, ora 19:10 ora Romaniei: patch-ul a fost lansat. PHP a lansat versiunile 8.5.12, 8.4.27, 8.3.36 si 8.2.35, care repara cele doua vulnerabilitati critice numite PHP2Shell. Ele permit oricui, fara autentificare, sa execute cod pe server. Daca ai un site WordPress, un magazin online PrestaShop sau WooCommerce, o aplicatie Laravel sau un program de gestiune in PHP, trebuie sa actualizezi.

Echipa PHP a fost clara: actualizarea este singura solutie completa. Masurile temporare reduc riscul, dar nu il elimina.

In acest articol iti explic ce afecteaza cele doua brese, cine este expus, cum actualizezi pe server, in Docker si pe gazduire partajata si ce faci daca nu poti actualiza imediat. Cu comenzi gata de copiat.

Ce este PHP2Shell, pe intelesul tuturor

PHP2Shell este porecla data de cercetatori celor doua vulnerabilitati din nucleul PHP: CVE-2026-109618 si CVE-2026-109619. Echipa de securitate PHP le-a clasificat drept critice, cu un scor de 9.2 din 10 pe scala CVSS v4.0.

Diferenta fata de bresele obisnuite este locul unde se afla. Nu sunt intr-un plugin, intr-o tema sau intr-un framework: sunt in interpretorul PHP, adica in programul care ruleaza tot restul.

De aceea problema este atat de larga: afecteaza orice aplicatie construita pe PHP, chiar daca propriul ei cod este perfect actualizat.

Ce inseamna "executare de cod de la distanta"

O vulnerabilitate RCE (Remote Code Execution) permite unui atacator sa ruleze instructiuni alese de el pe server, fara sa aiba acces. Cu permisiunile procesului PHP poate, de exemplu:

• sa citeasca fisierele de configurare, ca wp-config.php, .env din Laravel sau parameters.php din PrestaShop, cu parolele bazei de date;
• sa descarce baza de date cu clienti, comenzi si date personale;
• sa incarce un web shell, adica un fisier PHP ascuns care ii lasa o usa deschisa si dupa actualizare;
• sa foloseasca serverul pentru alte atacuri, spam sau minare de criptomonede.

Porecla PHP2Shell se citeste asa: trimiti o cerere catre site si obtii un shell, adica controlul serverului.

Ce afecteaza cele doua brese PHP2Shell

Ambele tin de felul in care PHP pregateste si curata datele fiecarei cereri web. Iata ce fac, fara detaliile utile doar celor care vor sa le exploateze.

CVE-2026-109618: corupere cand se termina memoria

Cand o cerere epuizeaza memoria disponibila pentru PHP, interpretorul se opreste brusc. Se poate intampla in timp ce datele interne ale cererii sunt pregatite doar pe jumatate.

In faza de curatare, PHP trateaza acele date incomplete ca si cum ar fi valide. Un atacator care stie sa provoace aceasta situatie poate ajunge sa execute cod. Codul avertismentului pe GitHub: GHSA-w8hw-w9fx-j79w.

CVE-2026-109619: starea cererii anterioare ramane in memorie

Un proces PHP-FPM sau Apache serveste multe cereri, una dupa alta. In anumite cazuri, unele informatii ale unei cereri supravietuiesc chiar si dupa ce memoria care le continea a fost eliberata.

Cererea urmatoare, gestionata de acelasi proces, le poate folosi inainte sa fie resetate. Este o eroare de tip "use after free", printre cele mai exploatate. Codul avertismentului pe GitHub: GHSA-6wmf-4rv5-p3rp.

Cine este expus la PHP2Shell

Potrivit anuntului oficial, este expusa orice instalare PHP care raspunde la cereri web:

• PHP-FPM (configuratia cea mai comuna cu Nginx si in containerele Docker);
• Apache cu mod_php;
• php-cgi;
• FrankenPHP;
• LiteSpeed (foarte raspandit pe gazduirile partajate).

Nu este nevoie de autentificare: ajunge o cerere catre site. Riscul cel mai mare este pe Apache cu mod_php, unde a fost demonstrat un atac care porneste inainte chiar sa ruleze codul aplicatiei. Asa ca niciun plugin de securitate WordPress nu il poate opri.

PHP folosit doar din linia de comanda, fara sa serveasca pagini web, nu apare printre configuratiile la risc. Dar aproape toate site-urile intra intr-unul dintre cazurile de mai sus.

Versiuni corectate: la ce PHP actualizezi

Ramura	Versiune vulnerabila	Versiune corectata	Suport
PHP 8.5	8.5.11 si mai vechi	8.5.12	Activ pana la 31.12.2027
PHP 8.4	8.4.26 si mai vechi	8.4.27	Activ pana la 31.12.2026
PHP 8.3	8.3.35 si mai vechi	8.3.36	Doar securitate pana la 31.12.2027
PHP 8.2	8.2.34 si mai vechi	8.2.35	Doar securitate pana la 31.12.2026

Atentie la PHP 8.2: suportul se termina pe 31 decembrie 2026. Daca actualizezi acum, gandeste-te deja la trecerea pe 8.3 sau 8.4.

PHP 8.1, 8.0 si 7.4: ce faci

Aceste ramuri nu mai primesc versiuni oficiale. Echipa de securitate a publicat insa corectii minime pentru PHP 7.4, 8.0 si 8.1 in depozitul GitHub al PHP, pentru cine compileaza din sursa.

Unele distributii Linux si furnizori cu suport extins integreaza aceste corectii in pachetele lor. Daca serverul sau gazduirea ta foloseste una dintre aceste versiuni, intreaba furnizorul daca a aplicat deja patch-ul.

Raman totusi versiuni nesuportate: urmatoarea bresa s-ar putea sa nu aiba nicio corectie. Este momentul sa migrezi.

Nu este un caz rar. Firma Mallory a numarat pe Shodan aproximativ 884.000 de servere expuse pe internet care declara PHP 8.1 sau mai vechi. In proiectele de mentenanta pe care le urmaresc vad des gazduiri partajate blocate de ani de zile pe PHP 7.4.

Cum actualizezi PHP: ce faci acum

Mai intai fa un backup complet al fisierelor si al bazei de date. Apoi actualizeaza incepand cu serviciile publice cele mai sensibile: magazine online, programe de gestiune online, API-uri.

1. Verifica versiunea PHP pe care o folosesti

• Server Linux cu SSH: php -v. Versiunea folosita de site poate fi diferita de cea din linia de comanda. Pentru pachete pe Debian sau Ubuntu: dpkg -l | grep -E "php[0-9.]+-(fpm|cli|common)"
• Containere Docker (Coolify, Dokploy, Portainer): docker ps --format "{{.Names}} {{.Image}}" pentru lista, apoi docker exec NUME_CONTAINER php -v.
• WordPress: Unelte > Sanatatea site-ului > Informatii > Server.
• PrestaShop: Parametri avansati > Informatii.
• Laravel: php artisan about, sectiunea Environment.

2. Pe Debian si Ubuntu

Distributiile Linux au primit patch-ul in avans, deci pachetele actualizate ar trebui sa fie deja disponibile. Actualizeaza si reporneste PHP-FPM:

sudo apt update && sudo apt install --only-upgrade "php8.4-*" && sudo systemctl restart php8.4-fpm

Inlocuieste 8.4 cu ramura ta.

Distributiile aplica des corectia fara sa schimbe numarul versiunii (backport). Asa ca nu te baza doar pe php -v: verifica anuntul de securitate al distributiei tale.

Daca folosesti depozitul Remi (rpms.remirepo.net, raspandit pe CentOS, AlmaLinux si Rocky): azi nu va avea actualizari. PHP recomanda trecerea la pachetele distributiei sau compilarea din sursa.

3. Cu Docker si Coolify

Aici e un lucru important. In momentul in care scriu, imaginile oficiale php de pe Docker Hub nu sunt inca actualizate: exista versiunile candidat 8.5.12RC1 si 8.4.27RC1, iar pentru 8.3 si 8.2 versiunile corectate nu au aparut inca.

Pana apar, aplica masurile din sectiunea urmatoare. Imediat ce imaginile sunt disponibile:

• daca folosesti un tag de ramura ca php:8.4-fpm, reconstruieste descarcand imaginea noua: docker build --pull --no-cache -t nume-app .
• daca ai fixat versiunea exacta, ca php:8.4.26-fpm, schimb-o manual in php:8.4.27-fpm, altfel reconstruiesti aceeasi versiune vulnerabila.

Pe Coolify, dupa ce ai actualizat Dockerfile-ul, fa un nou deploy fortand reconstruirea fara cache. Apoi verifica cu docker exec NUME_CONTAINER php -v.

4. Pe gazduire partajata

Pe gazduirile partajate corectia o aplica furnizorul, si de obicei nu trebuie sa faci nimic din panou. In zilele urmatoare verifica daca versiunea minora s-a schimbat (de exemplu de la 8.3.35 la 8.3.36). Daca nu se schimba, deschide un tichet citand anuntul de securitate PHP din 21 octombrie.

Actualizarea PHP pe WordPress la gazduirea ta

Multi cauta cum sa actualizeze PHP la propria gazduire. Pe aproape toate gazduirile partajate functioneaza asa: din panou poti alege ramura PHP (de exemplu sa treci de la 7.4 la 8.3), dar patch-ul de securitate din interiorul ramurii il instaleaza furnizorul.

Asa ca, pentru PHP2Shell, pasul corect depinde de versiunea pe care o ai:

• Esti pe 8.2, 8.3, 8.4 sau 8.5: nu schimba nimic din panou. Verifica din Unelte > Sanatatea site-ului ca versiunea urca la cea corectata si, daca intarzie, scrie la suport.
• Esti pe 8.1 sau mai vechi: foloseste selectorul de versiune PHP din panou (de obicei se numeste "Versiune PHP", "Select PHP Version" sau "MultiPHP") ca sa treci cel putin la 8.3. Inainte fa un backup si un test.

Ce verifici dupa schimbarea versiunii pe WordPress

• Eroare 500 sau pagina alba: aproape mereu un plugin sau o tema veche incompatibila. Revino la versiunea anterioara din panou, apoi actualizeaza sau inlocuieste plugin-ul.
• Logul de erori: activeaza WP_DEBUG_LOG in wp-config.php si uita-te in wp-content/debug.log ca sa vezi ce plugin da probleme.
• Cache: goleste cache-ul plugin-ului si pe cel al gazduirii, altfel poti vedea in continuare paginile vechi.
• Functiile cheie: testeaza cosul, checkout-ul, formularele de contact si autentificarea. Sunt partile care se strica cel mai des.

Daca site-ul e prea vechi ca sa suporte PHP 8, e momentul sa te gandesti la un site nou in loc sa amani.

Daca nu poti actualiza imediat: masurile oficiale

Aceste masuri reduc riscul pe unele cai de atac, dar nu fac serverul sigur. Servesc doar ca sa acoperi orele pana la actualizare, de exemplu in containerele care asteapta imaginea noua.

Contra CVE-2026-109618 (memorie)

• Seteaza memory_limit=-1 intr-un loc pe care aplicatia nu il poate suprascrie, de exemplu cu php_admin_value in pool-ul FPM sau in configuratia Apache. Verifica sa nu existe pool, folder sau aplicatie care pune din nou o limita.
• Coboara post_max_size: 8M daca site-ul nu primeste upload-uri, 32M daca are nevoie, cu upload_max_filesize mai mic.
• Pune limite in serverul web sau in proxy: dimensiunea cererii, numarul de campuri, partile multipart, header-ele.
• Pentru ca PHP nu mai are limita de memorie, seteaza o limita de memorie pentru container (in Coolify, la resursele serviciului). Nu folosi RLIMIT_AS sau RLIMIT_DATA: pot provoca exact eroarea care deschide bresa.

Contra CVE-2026-109619 (stare reziduala)

• Seteaza session.upload_progress.enabled=0 in php.ini, in pool-ul FPM sau in configuratia serverului, nu cu ini_set() sau .user.ini. Apoi reporneste toate procesele PHP.
• Doar pe PHP 8.5: seteaza si fatal_error_backtraces=0 si reporneste.
• Corecteaza erorile fatale si timeout-urile pe care un vizitator le poate provoca. Sa le ascunzi cu display_errors sau cu @ nu ajuta.

Masurile intr-o singura linie pentru Docker

Pentru o imagine PHP oficiala poti adauga in Dockerfile aceasta linie, apoi faci deploy:

RUN printf "memory_limit=-1\npost_max_size=8M\nupload_max_filesize=6M\nsession.upload_progress.enabled=0\n" > /usr/local/etc/php/conf.d/zz-php2shell.ini

Pe PHP 8.5 adauga fatal_error_backtraces=0. Si nu uita limita de memorie a containerului.

Cum iti dai seama daca cineva a incercat deja sa exploateze PHP2Shell

Acum ca detaliile sunt publice, atacurile automate pot porni repede. In 2024, cu CVE-2024-4577, Akamai a inregistrat primele incercari in mai putin de 24 de ore.

Semnul cel mai tipic al unui atac reusit este un proces PHP care porneste programe pe care nu ar trebui sa le porneasca. Un worker php-fpm sau apache2 care lanseaza sh, bash, curl, wget, python sau nc este aproape mereu un semn rau.

Trei verificari rapide pe serverele Linux:

• Procesele copil ale PHP: ps -eo pid,ppid,user,etime,cmd --forest | grep -A3 -E "php-fpm|php-cgi|apache2"
• Fisiere PHP modificate recent: find /var/www -type f -name "*.php" -mtime -2. Un fisier cu nume ciudat in uploads sau tmp trebuie verificat imediat.
• Cron-ul utilizatorului web: sudo crontab -l -u www-data nu ar trebui sa contina nimic pus de altcineva decat tine.

Pentru supraveghere continua exista si process-watcher de Florian Roth, gratuit, care inregistreaza fiecare program pornit de un proces PHP.

Daca gasesti ceva suspect: izoleaza serverul, salveaza logurile inainte sa atingi altceva si cauta web shell-uri, fisiere noi, cron-uri si utilizatori noi. Actualizarea PHP nu sterge un web shell deja incarcat.

Cronologia PHP2Shell

• 20 octombrie, dimineata: o postare pe Hacker News anunta existenta celor doua brese, apoi este stearsa.
• 20 octombrie, cateva ore mai tarziu: cercetatorii de la watchTowr confirma ca sunt reale si sub embargo.
• 20 octombrie, ora 22:33 ora Romaniei: PHP publica anuntul preliminar, cu lansarea fixata a doua zi.
• 21 octombrie, ora 17:00 ora Romaniei: apar 8.5.12, 8.4.27, 8.3.36 si 8.2.35, cu anuntul de securitate complet.

In 2012 s-a intamplat ceva asemanator cu CVE-2012-1823: primul patch de urgenta putea fi ocolit si a fost nevoie de un al doilea. Asa ca actualizeaza imediat, dar urmareste php.net in zilele urmatoare.

Lista rapida de verificare contra PHP2Shell

• Imediat: backup, verificarea versiunilor PHP, actualizarea serviciilor publice la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35.
• Pe containerele Docker: masurile temporare azi, reconstruirea imediat ce apar imaginile oficiale.
• Pe gazduirile partajate: verifica daca versiunea minora urca, altfel tichet.
• In urmatoarele 48 de ore: verificarea proceselor PHP, a fisierelor modificate si a cron-urilor.
• In lunile urmatoare: migrarea de pe 8.1 si mai vechi, si un plan de iesire de pe 8.2 inainte de sfarsitul anului.

Concluzie

PHP2Shell este una dintre cele mai serioase brese din ultimii ani pentru cine lucreaza cu PHP: este in nucleu, nu cere autentificare si loveste configuratiile cele mai raspandite. Corectia exista si este simplu de aplicat acolo unde administrezi tu serverul.

Punctul slab sunt site-urile pe care nu le urmareste nimeni: gazduiri partajate niciodata verificate, versiuni vechi, containere cu versiunea fixata. Acolo o actualizare de zece minute poate evita un site compromis.

Daca nu stii pe ce versiune de PHP ruleaza site-urile tale sau ai un site pe o versiune nesuportata, pot face eu verificarea si actualizarea. Scrie-mi si iti spun in aceeasi zi ce trebuie facut. Vezi si celelalte servicii de asistenta si dezvoltare.

Surse: anuntul de securitate si lansarile pe php.net; ChangeLog PHP 8; avertismentele GitHub GHSA-w8hw-w9fx-j79w si GHSA-6wmf-4rv5-p3rp; analize de la Huntress si The Hacker News.