PHP2Shell: dacă ai un site pe WordPress, vulnerabilitatea asta e în PHP-ul de sub el

Aproape orice site de firmă din România stă pe WordPress, de obicei la un hosting partajat cu cPanel. Dacă ești și tu acolo — sau ai o agenție care administrează zeci de astfel de site-uri — vestea de pe 21 octombrie te privește direct: PHP a scos un patch de urgență pentru două vulnerabilități numite împreună PHP2Shell, și afectează practic orice WordPress care nu a fost actualizat.

scor CVSS (Critic) — ambele vulnerabilități

9.2

toate versiunile PHP din ultimul deceniu

5.4 → 8.5.11

pluginuri sau linii din codul tău care trebuie să fie de vină

0

Ce s-a întâmplat, pe scurt

CVE-2026-109618 și CVE-2026-109619 sunt două erori în motorul PHP care, combinate, permit execuție de cod la distanță fără autentificare (RCE neautentificat). Un atacator rulează comenzi pe server fără să aibă cont, fără parolă și fără să-i pese ce temă sau pluginuri ai. Detaliile s-au scurs public pe 20 octombrie, înainte de dezvăluirea coordonată, iar încercări de exploatare se văd în sălbăticie încă de pe 17 octombrie.

De ce „WordPress-ul meu e la zi cu pluginurile” nu te ajută

Aici e capcana pe care o înțeleg greșit cei mai mulți. Când auzi „vulnerabilitate PHP”, te gândești la un plugin prost scris. Dar PHP2Shell nu e în plugin și nu e în WordPress — e în PHP-ul de sub ele, în motorul care citește cererea venită de la vizitator înainte ca WordPress să pornească măcar.

Unde e de fapt problema

Calea vulnerabilă e procesarea cererii HTTP de către PHP — de exemplu parsarea unui fișier trimis printr-un formular (multipart/form-data). Rulează înaintea WordPress-ului, a temei și a oricărui plugin de securitate.

Poți avea toate pluginurile la zi, un Wordfence configurat perfect și cod curat — și tot ești expus, dacă runtime-ul PHP de dedesubt n-are patch-ul. De-asta soluția e „actualizează PHP”, nu „actualizează pluginurile”.

Pe cine lovește, în realitate

Nu toate site-urile sunt la fel de expuse. Dacă administrezi mai multe, prioritizează în ordinea asta:

• Magazinele WooCommerce și site-urile cu conturi / plăți. Aici miza e maximă: date de card, date de clienți (PII), comenzi active. Și tot astea sunt scanate primele de atacatori.
• Site-urile pe hosting partajat vechi. Multe pachete de hosting din România încă rulează versiuni PHP ieșite din suport (8.1 sau mai vechi) fiindcă „merge și așa”. Acolo nici nu există un patch oficial.
• Serverele administrate de altcineva. Dacă un furnizor sau un admin extern îți ține site-ul, nu presupune că s-a ocupat — întreabă explicit dacă a actualizat PHP și a repornit serviciul.

Un site simplu de prezentare poate aștepta o oră. Un magazin, nu.

Verifică ce versiune de PHP ai

În cPanel caută secțiunea „Select PHP Version” (sau „MultiPHP Manager”). Dacă ai acces prin SSH:

php -v        # versiunea din linia de comandă
php-fpm -v    # versiunea folosită efectiv de site, dacă e pe FPM

Compară cu versiunile reparate. Ești sub ele? Ești vulnerabil.

Ramură PHP	Versiune cu patch	Stare
8.5	8.5.12	Suportată
8.4	8.4.27	Suportată
8.3	8.3.36	Suportată
8.2	8.2.35	Suportată (EOL 31 dec. 2026)
8.1 și mai vechi	doar backport de sursă	Scoasă din suport

Dacă ești pe 8.1 sau mai vechi, nu mai primești actualizări oficiale. La un hosting partajat, de multe ori e suficient să schimbi versiunea PHP pe una suportată din panou — dar fă-o după ce testezi că site-ul merge pe ea.

Ce faci acum

Pașii de urmat

1. Inventariază. Fiecare site, fiecare server, fiecare panou de administrare. Site-ul uitat e fix cel prin care intră cineva.
2. Actualizează PHP la versiunea reparată — din panoul de hosting sau prin managerul de pachete al serverului.
3. Repornește serviciul PHP (PHP-FPM / Apache). Pasul cel mai des uitat: dacă nu repornești, runtime-ul vechi rămâne în memorie și rămâi vulnerabil.
4. Pune un WAF în față (Cloudflare, de exemplu) — acoperire utilă cât aplici patch-ul, nu un înlocuitor.
5. Dacă nu poți actualiza acum, scoate site-ul offline temporar. Pentru un RCE de 9.2 deja exploatat, e preferabil unui site compromis.

Atenție: setările din config nu te salvează

Vor circula „soluții” gen memory_limit=-1 sau session.upload_progress.enabled=0. Proiectul PHP spune clar: niciuna nu rezolvă complet. Închid câteva căi și atât. Singura reparație reală e patch-ul pe runtime.

Dacă ai stat nepatch-uit, verifică dacă n-a intrat deja cineva

Fiind exploatat înainte de dezvăluire, merită să presupui că s-ar putea să fi fost atins. Semnele cele mai clare (după Datadog Security Labs și advisory-ul PHP):

• Un proces web care pornește un shell — apache2 sau php-fpm care lansează sh, bash, curl sau wget. Un server web nu face asta normal. E semnul cel mai sigur.
• Fișiere .php noi sau modificate recent în directoare de upload (wp-content/uploads) — locul clasic unde se lasă un backdoor.
• În log-ul PHP: Allowed memory size ... exhausted ... Unknown on line 0 — a murit la inițializarea cererii, înainte de orice script.

Dacă găsești un worker web care pornește shell-uri, tratează serverul ca fiind compromis: izolează-l, păstrează log-urile și reconstruiește-l — nu-l „curăța pe loc”.

De ce guwapi.com nu e în discuția asta

Conduc guwAPI, un mic studio software din București, iar site-urile pe care le construiesc nu rulează pe WordPress și nu au PHP pe server — sunt build-uri statice (Astro). Nu există niciun motor PHP care să aștepte o cerere ostilă, deci întreaga categorie de atac nu are ce ataca aici.

Nu spun asta ca să mă laud, ci fiindcă e o alegere de arhitectură cu o consecință concretă: când nu rulezi un runtime pe server, scapi din start de o clasă întreagă de vulnerabilități ca asta. Securitatea nu e un strat pus la final — e punctul de pornire.