PHP2Shell: ce riști dacă site-ul tău nu e întreținut
Două vulnerabilități critice în PHP permit preluarea serverului fără parolă. Ce versiuni sunt afectate, ce riști cu un site neîntreținut și ce verifici săptămâna asta.
· 9 min de citit
Pe 21 octombrie 2026, echipa care dezvoltă PHP a publicat în regim de urgență versiuni noi pentru două vulnerabilități critice. Prin ele, cineva de pe internet poate rula propriul cod pe serverul site-ului tău, fără parolă și fără cont. Potrivit W3Techs, PHP rulează pe aproximativ 7 din 10 site-uri, inclusiv pe toate site-urile WordPress și Joomla.
Vulnerabilitățile au primit numele PHP2Shell. Mai jos afli ce s-a întâmplat, zi cu zi, cum îți dai seama dacă site-ul tău e expus și ce riști concret dacă nu se ocupă nimeni de el. La final îți arătăm cum am tratat noi problema pe site-urile pe care le administrăm.
Pe scurt
Ce e: două vulnerabilități în PHP, CVE-2026-109618 și CVE-2026-109619, notate fiecare cu 9,2 din 10. Permit preluarea serverului fără autentificare.
Pe cine afectează: orice server care rulează PHP pentru un site, indiferent dacă e WordPress, un magazin online sau cod scris de la zero.
Remedierea: actualizarea PHP la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35. Setările temporare reduc riscul, dar nu îl elimină.
Urgența: primele tentative de atac au apărut înainte de anunțul oficial.
Versiunile vechi: PHP 8.1 și mai vechi nu mai primesc nicio versiune oficială.
Ce s-a întâmplat, zi cu zi
De obicei, o vulnerabilitate în PHP e anunțată abia după ce versiunea corectată e gata, ca administratorii să aibă timp să o instaleze. De data asta, ordinea s-a stricat.
Orele sunt ora României. Surse: anunțurile PHP din 20 și 21 octombrie 2026; Tenable, PHP2Shell FAQ, care citează Amazon Threat Intelligence.
17 octombrie: Amazon Threat Intelligence a înregistrat o tentativă de exploatare în rețeaua sa de servere-capcană, cu patru zile înainte de anunț.
20 octombrie: identificatorii vulnerabilităților au circulat pe Hacker News și pe rețelele sociale. Echipa PHP a anunțat o versiune de securitate pentru a doua zi. Inițial o planificase pentru 22 octombrie și a mutat-o mai devreme din cauza scurgerii.
21 octombrie, ora 17:00: au apărut PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Anunțul de securitate PHP are un mesaj fără echivoc: nu există o soluție temporară completă, singura variantă sigură e actualizarea.
După anunț: Amazon spune că PHP2Shell e „exploatat pe scară largă”, iar Cloudflare raportează primele atacuri.
Ce înseamnă, pe înțelesul tuturor
Un site PHP primește cereri de la vizitatori: „arată-mi pagina de servicii”, „trimite formularul de contact”. Serverul ține câteva procese PHP pornite permanent și le folosește pe rând pentru cereri.
Cele două defecte sunt în felul în care PHP își curăță memoria între cereri. Unul apare când PHP rămâne fără memorie în mijlocul unei cereri. Celălalt lasă în urmă informații dintr-o cerere terminată, pe care cererea următoare le folosește greșit. Un atacator trimite o cerere construită special, iar la final poate rula ce cod vrea pe server.
Două detalii fac situația gravă:
Nu contează ce aplicație ai. Problema e în PHP, nu în WordPress sau în codul site-ului. Echipa PHP spune că sunt expuse toate instalațiile care servesc pagini web: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Riscul cel mai mare îl are Apache cu mod_php.
Nu e nevoie de cont. Atacul nu cere parola de administrator. Potrivit Tenable, o variantă demonstrată funcționează cu o singură cerere trimisă înainte ca site-ul să ruleze vreo linie din propriul cod.
Câte site-uri rămân descoperite
O versiune corectată există doar pentru ramurile pe care echipa PHP le mai întreține: 8.2, 8.3, 8.4 și 8.5. Pentru restul, situația arată așa:
PHP 7.4, 8.0 și 8.1: echipa PHP a publicat doar modificările de cod, nu și o versiune gata de instalat. Pe acestea le poate folosi o distribuție Linux sau o firmă de găzduire, dacă vrea. Proprietarul site-ului nu are ce instala singur.
PHP 5.4 până la 7.3: nu există nicio corectură din partea proiectului PHP.
Estimare calculată de noi din statisticile W3Techs din 22 octombrie 2026, care măsoară doar site-urile la care versiunea PHP se poate detecta. Încadrarea versiunilor: anunțul PHP din 21 octombrie 2026.
Aproape jumătate din site-urile PHP rulează deci o versiune pentru care nu există o actualizare oficială pe care să o instalezi. Iar existența unei versiuni corectate nu înseamnă că cineva a și instalat-o. Ramura 8.2 mai primește actualizări doar până pe 31 decembrie 2026, deci și o parte din site-urile care sunt acum în regulă vor ajunge în aceeași situație peste câteva luni.
În cifre absolute, o estimare citată de Tenable vorbește de peste 1,3 milioane de servere expuse direct pe internet care ar putea fi vulnerabile. Mărimea site-ului nu contează: atacatorii folosesc programe care încearcă aceeași cerere pe orice server PHP găsesc, fără să se uite ce firmă e în spate.
Ce riști dacă nu se ocupă nimeni de site
1. Avertismentul Google
Un site spart e folosit des pentru pagini de spam sau redirecționări. Când Google observă asta, afișează sub rezultat mesajul „Acest site poate fi spart”. În pagina de ajutor despre acest mesaj, Google le recomandă oamenilor să nu intre pe site până nu dispare avertismentul. Mesajul nu dispare singur: trebuie să cureți site-ul, să închizi breșa și să ceri o reverificare din Google Search Console. Dacă n-ai acces la contul de Search Console al site-ului, vezi întâi cum obții acces ca proprietar.
2. Datele din formulare și obligațiile GDPR
Formularul de programare, cererile de ofertă, mesajele de contact: toate trec prin server. Cine controlează serverul le poate citi. Dacă se întâmplă asta, e o încălcare a securității datelor cu caracter personal. GDPR îți cere să o anunți la ANSPDCP în cel mult 72 de ore de când afli (articolul 33), cu excepția cazului în care e puțin probabil să existe un risc pentru oameni. Dacă riscul e mare, trebuie anunțate și persoanele ale căror date au fost expuse (articolul 34). Pentru un cabinet medical sau psihologic, unde formularul poate conține date despre sănătate, situația e serioasă.
3. Serverul tău, folosit împotriva altora
Un server preluat poate trimite spam în numele firmei, poate redirecționa vizitatorii spre site-uri de înșelătorii sau poate ataca alte servere. Pe găzduirea partajată, firma de hosting poate suspenda contul până la curățare.
4. Soluțiile temporare nu ajung
Echipa PHP a publicat câteva setări care reduc riscul, dar spune explicit că ele nu fac o instalare sigură. În plus, setările trebuie puse în configurația serverului, nu în codul site-ului, iar procesele PHP trebuie repornite. Pe găzduirea partajată, de multe ori nu ai acces la ele. Regulile de firewall pe care le-a adăugat Cloudflare ajută doar traficul care trece prin Cloudflare și sunt și ele o soluție de moment.
Checklist: verifică-ți site-ul săptămâna asta
Află ce versiune de PHP rulează. Întreabă agenția sau firma de găzduire. În panourile de tip cPanel apare de obicei la „Select PHP Version” sau „MultiPHP Manager”.
Compară cu lista: 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 sau mai nouă înseamnă că remedierea e instalată. Orice altceva înseamnă că nu e.
Dacă ești pe 8.1 sau mai vechi, cere un plan de trecere pe o versiune întreținută, cu termen. Probabil va trebui actualizat și codul site-ului.
Întreabă cine primește alertele de securitate și în cât timp a reacționat de data asta. Răspunsul spune mult despre ce se va întâmpla data viitoare.
Verifică backupul: există o copie în afara serverului? A încercat cineva vreodată să o restaureze?
Uită-te după semne de compromitere: pagini pe care nu le recunoști în rezultatele Google pentru numele site-ului, avertismente în browser, emailuri trimise în numele firmei pe care nu le-a trimis nimeni din firmă.
Întrebări frecvente
Am WordPress actualizat la zi. Sunt protejat?
Nu neapărat. PHP2Shell e în PHP, limbajul pe care rulează WordPress, nu în WordPress. Un WordPress la zi pe un PHP vechi rămâne expus. Actualizarea PHP o face cine administrează serverul, de obicei firma de găzduire.
Firma de găzduire actualizează PHP singură?
Depinde de tipul de găzduire. Pe găzduirea partajată, firma actualizează de obicei versiunile pe care le oferă, dar tu alegi ramura (de exemplu 7.4 sau 8.3). Dacă ai ales o ramură veche, rămâi pe ea. Pe un server virtual (VPS) administrat de tine sau de un freelancer, nu actualizează nimeni nimic automat.
Ajunge să pun Cloudflare în fața site-ului?
Nu. Cloudflare a adăugat reguli pentru atacurile cunoscute, inclusiv în planul gratuit, dar le numește o soluție de moment. Un atac nou, care nu se potrivește regulilor, ajunge la server. Actualizarea PHP rămâne necesară.
Site-ul meu e pe PHP 7.4. Ce fac?
Ai nevoie de un plan de migrare pe PHP 8.3 sau 8.4. Pentru 7.4 nu există o versiune oficială corectată, iar site-urile vechi au adesea cod sau pluginuri care nu merg pe PHP 8 fără modificări. Până atunci, cere-i firmei de găzduire să-ți confirme în scris dacă a aplicat o corectură proprie.
Cum îmi dau seama că site-ul a fost deja spart?
Nu întotdeauna se vede. Semnele frecvente sunt pagini necunoscute în Google, redirecționări spre alte site-uri doar pentru vizitatorii veniți din căutare, emailuri trimise fără știrea ta și mesaje de securitate în Search Console. Dacă bănuiești ceva, cere o verificare a fișierelor și a jurnalelor serverului, nu doar o actualizare.
Site-ul meu e mic și are câțiva vizitatori pe zi. Cine să-l atace?
Oricine scanează internetul. Atacurile de felul acesta sunt automate: un program încearcă aceeași cerere pe milioane de adrese, fără să aleagă. Prima tentativă de atac cu PHP2Shell a fost înregistrată pe un server-capcană al Amazon, adică pe un server fără niciun site cunoscut în spate.
Dacă site-ul a fost spart și aveam formular de contact, trebuie să anunț ANSPDCP?
Dacă datele din formulare au putut fi accesate și există un risc pentru oameni, da, în 72 de ore de când afli. Nu orice incident trebuie notificat, dar decizia trebuie luată și documentată. Pentru cazul tău concret, discută cu responsabilul cu protecția datelor sau cu un jurist.
Cum am lucrat noi în zilele astea
Și site-urile noastre rulează pe PHP, așa că PHP2Shell le privea și pe ele. Diferența a făcut-o felul în care sunt construite: fiecare site rulează izolat, pe servere administrate de noi, și toate pornesc de la aceeași rețetă tehnică. O schimbare făcută o dată ajunge pe toate, după ce o verificăm întâi pe copia de test a fiecărui site.
Pe 21 octombrie, la două-trei ore după anunțul oficial, toate site-urile pe care le administrăm aveau aplicată măsura temporară recomandată. Versiunea corectată a imaginii de server pe care o folosim a apărut în aceeași seară. A doua zi dimineață, până la ora 11:20, toate site-urile clienților noștri rulau PHP 8.4.27, iar aplicațiile noastre interne au urmat în următoarea jumătate de oră. Restul a rămas cum era: backup zilnic păstrat în afara serverului, monitorizare de la alt furnizor, din altă țară, și posibilitatea de a reveni la versiunea anterioară a site-ului dacă o actualizare nu merge.
Dacă vrei să știi cum stă site-ul tău, ne poți scrie și ne uităm. Ce include întreținerea la noi găsești pe pagina de servicii și pe cea de prețuri.
