Vulnerabilitate critică în PHP (php2shell): ce înseamnă pentru proiectul tău online și ce trebuie să faci azi

Pe 21 octombrie 2026, echipa care dezvoltă limbajul PHP a lansat în regim de urgență patch-uri de securitate pentru două vulnerabilități critice. Dacă ai un site de prezentare, un magazin online sau o platformă dezvoltată pe WordPress, WooCommerce, PrestaShop, Magento, Drupal, Laravel sau PHP custom, șansele să fii direct vizat sunt foarte mari.

Vestea bună? Ca să știi dacă ești expus, ai nevoie de o singură informație: versiunea de PHP care rulează pe serverul tău. Mai jos îți arătăm exact unde o găsești, cum știi dacă ești în siguranță și ce trebuie să îi ceri furnizorului tău de hosting. Totul durează mai puțin de cinci minute.

Ce este PHP și de ce te afectează direct

PHP este limbajul de programare pe care stau construite aproape șapte din zece site-uri de pe internet. Ca utilizator, nu interacționezi direct cu el. El rulează în spate, pe server, și asamblează fiecare pagină pe care o vede un client atunci când îți accesează site-ul sau aplicația.

Dacă ar fi să facem o analogie auto: platforma ta (fie că e WordPress, Magento sau o aplicație custom) este caroseria și interiorul mașinii, iar PHP-ul este motorul. Iar săptămâna aceasta s-a descoperit un defect de fabricație la aproape toate motoarele produse din 2012 și până azi.

Ce s-a întâmplat, tradus în limbaj de business

Cercetătorii în securitate cibernetică au identificat două erori critice în modul în care PHP gestionează memoria serverului, înregistrate oficial sub codurile CVE-2026-109618 și CVE-2026-109619 și cunoscute în industrie drept „php2shell”.

Fără să intrăm în detalii de cod, iată de ce alerta a determinat agenții precum CISA (Cybersecurity and Infrastructure Security Agency) să emită avertismente imediate:

1. Poarta este larg deschisă. Un atacator nu mai trebuie să caute o temă neactualizată sau să spargă o parolă slabă. Poate trimite o simplă cerere (request) construită special către orice pagină a site-ului, iar serverul îi va executa comenzile. Odată intrat, poate modifica fișiere, poate descărca baza de date cu clienți sau poate instala backdoors, programe ascunse care îi păstrează accesul chiar și după ce repari vulnerabilitatea inițială.
2. Nicio platformă PHP nu este imună. Toate versiunile de PHP de la 5.4 și până la 8.5.11 sunt vulnerabile. Practic, orice proiect web bazat pe PHP care nu a primit update de server după data de 21 octombrie 2026 este expus.
3. Atacurile sunt deja în desfășurare. Detaliile tehnice ale vulnerabilității au „scăpat” pe internet pe 20 octombrie, cu o zi înainte de lansarea patch-ului. Conform datelor Amazon (AWS), primele tentative de exploatare au apărut încă din 17 octombrie. În dimineața zilei de 21 octombrie, boții scanau deja masiv internetul folosind scripturi de atac publice, gata făcute.

Cum verifici în 5 minute dacă ești expus

Tot ce trebuie să afli este versiunea exactă de PHP pe care rulează proiectul tău. Ai trei variante rapide:

1. 01

   Direct din WordPress, dacă folosești acest CMS

   Intră în panoul de administrare și mergi la Unelte (Tools) → Sănătate site (Site Health) → tab-ul Informații (Info) → secțiunea Server. Acolo vei găsi linia „Versiune PHP” (PHP Version).

2. 02

   Din panoul de control al găzduirii (cPanel / Plesk)

   În cPanel, caută opțiunea „Select PHP Version” sau „MultiPHP Manager”. În Plesk, intră la „PHP Settings”. Versiunea este afișată acolo, de obicei cu un meniu din care se poate schimba.

3. 03

   Întreabă direct echipa de suport a hostingului

   Dacă nu ai acces tehnic sau nu vrei să pierzi timpul prin meniuri, trimite-le un tichet folosind șablonul de mai jos. Este treaba lor să răspundă clar.

Cum interpretezi rezultatul

Dacă versiunea ta este 8.2.35, 8.3.36, 8.4.27, 8.5.12 (sau orice număr mai mare la final), poți închide acest articol. Serverul tău a fost deja actualizat și ești în siguranță.

Dacă vezi orice altă cifră, te afli în una dintre următoarele două situații:

• Rulezi PHP 8.2, 8.3, 8.4 sau 8.5, dar o sub-versiune mai veche (de exemplu 8.2.18). Ești foarte aproape de rezolvare. Furnizorul tău de hosting trebuie doar să aplice ultimul patch minor la nivel de server. Companiile de hosting serioase fac asta automat în câteva zile, dar nu merge pe presupuneri: deschide un tichet și cere confirmare.
• Rulezi PHP 8.1, 8.0, 7.4 sau mai vechi. Aici e adevărata problemă. Aceste versiuni au ajuns la End of Life (nu mai primesc suport oficial) și nu vor primi patch-uri pentru această vulnerabilitate. Singura soluție este migrarea proiectului pe minimum PHP 8.2.

Ce să îi scrii furnizorului de hosting

Dacă vrei un răspuns clar și rapid de la firma de găzduire, trimite-le acest mesaj pe mail sau în sistemul de tichete:

Măsuri care NU rezolvă această problemă

Când apar alerte de securitate, mulți proprietari de afaceri iau măsuri bine intenționate, dar care în acest caz specific sunt inutile:

• Actualizarea WordPress-ului, a temei sau a plugin-urilor. Este o practică excelentă în general, dar aici vulnerabilitatea se află sub nivelul lor.
• Instalarea unui plugin de securitate (Wordfence, Sucuri). Poate opri unele încercări cunoscute de atac, dar nu repară breșa din PHP.
• Activarea Cloudflare (WAF). Cloudflare a implementat deja reguli de filtrare pentru acest exploit, ceea ce oferă o plasă de siguranță bună. Totuși, un firewall este un scut, nu o reparație. Dacă un atacator cunoaște IP-ul direct al serverului tău, poate ocoli complet Cloudflare.
• Schimbarea parolelor. Atacul nu se bazează pe spargerea parolelor. Schimbă-le abia după ce ai actualizat PHP-ul, ca măsură de precauție.

Ce riști dacă ignori situația

Nu vorbim despre scenarii demne de filme cu hackeri, ci despre realitatea zilnică a firmelor care se trezesc cu infrastructura compromisă:

• Avertismentul roșu în Google și blocarea reclamelor. Atacatorii injectează adesea scripturi care redirecționează vizitatorii tăi către site-uri de phishing sau scam. Google detectează rapid comportamentul, îți blochează campaniile de Google Ads și afișează un ecran roșu de avertizare oricărui client care încearcă să intre pe site.
• Compromiterea datelor și amenzi GDPR. Baza de date (comenzi, adrese, numere de telefon, mesaje din formulare) poate fi copiată în câteva secunde. Conform legislației, o breșă care implică date cu caracter personal te obligă să notifici ANSPDCP în maximum 72 de ore de la constatare.
• Blocarea adreselor de email (blacklisting). Serverele sparte sunt folosite frecvent ca să trimită zeci de mii de emailuri de spam pe oră. Rezultatul? Domeniul tău intră pe listele negre internaționale, iar mailurile tale de business (oferte, facturi, confirmări) nu mai ajung la clienți.
• Suspendarea contului de găzduire. Când un site infectat începe să consume resurse masive sau să atace alte servere, firma de hosting îl oprește automat pentru a-și proteja restul rețelei.
• Costuri de devirusare de 10 ori mai mari decât prevenția. Un update de PHP asistat durează de la câteva minute la câteva ore. Curățarea unui proiect compromis, auditarea fișierelor linie cu linie și scoaterea domeniului de pe listele negre durează zile întregi și costă pe măsură.

Lecția de business: de ce „îl fac o dată și uit de el” nu mai funcționează în 2026

Timp de un deceniu, mentalitatea standard în piața din România a fost simplă: plătești o agenție sau un dezvoltator să-ți facă site-ul, achiți anual găzduirea și domeniul, și nu te mai atingi de el ani de zile. Cât timp se încarcă în browser, înseamnă că totul e în regulă. Din experiența noastră, aproximativ 90% dintre site-urile de companie funcționează după acest principiu.

Strategia asta a mers dintr-un singur motiv: în trecut, atacurile cibernetice presupuneau efort manual. Niciun hacker nu își pierdea timpul să spargă site-ul unui producător local, al unei clinici sau al unui distribuitor B2B.

Astăzi, regulile jocului s-au schimbat radical. Cu ajutorul automatizării și al uneltelor AI, distanța dintre momentul în care se descoperă o breșă (cum e cea din PHP) și momentul în care boții scanează milioane de servere pe oră se măsoară în minute.

În 2026, orice proiect digital se află într-una din două stări: ori are pe cineva care îl monitorizează activ, ori este o țintă sigură.

Întrebări frecvente

Am WordPress-ul și toate plugin-urile actualizate la zi. Sunt protejat? Nu. Vulnerabilitatea este în PHP (limbajul de pe server), nu în WordPress. Contează exclusiv versiunea de PHP instalată pe găzduirea ta.

Am un simplu site de prezentare, fără conturi de clienți și fără plăți online. Mă afectează? Da. Boții nu caută neapărat date de card. Pentru un atacator, serverul tău este o resursă gratuită pe care o poate folosi pentru a trimite spam, pentru a găzdui pagini de phishing sau pentru a lansa atacuri către alte rețele.

Ce înseamnă că „PHP 8.1 nu mai primește suport”? Fiecare versiune de software are un ciclu de viață. Suportul de securitate pentru PHP 8.1 s-a încheiat oficial la finalul anului 2025. Asta înseamnă că echipa PHP nu mai dezvoltă patch-uri gratuite pentru această versiune și că proiectele rămase pe 8.1 (sau mai vechi) trebuie migrate pe versiuni actuale: 8.2, 8.3, 8.4 sau 8.5.

Ce fac dacă bănuiesc că site-ul meu a fost deja compromis în ultimele zile? Dacă observi conturi noi de administrator pe care nu le recunoști, fișiere modificate recent pe server sau redirecționări dubioase, ordinea corectă de intervenție este: 1. izolarea problemei și actualizarea imediată a versiunii de PHP (altfel atacatorul intră la loc în timp ce tu cureți); 2. restaurarea unui backup curat, anterior datei de 17 octombrie 2026, sau auditarea și curățarea manuală a codului și a bazei de date, urmată de verificarea log-urilor de acces de pe server.

Surse de documentare: alertele oficiale publicate pe 21–22 octombrie 2026 de CISA, Google Cloud Security, Tenable și Codeable. Articolul va fi actualizat pe măsură ce apar informații noi.