Vulnerabilitate PHP (php2shell): ce faci dacă ai site WordPress

CVE-2026-109618 și CVE-2026-109619 afectează PHP-ul pe care rulează orice site WordPress. Versiunile reparate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Actualizarea WordPress sau a pluginurilor nu repară problema. Iată ce verifici azi și ce îi ceri firmei de hosting.

Pe 20 octombrie 2026, proiectul PHP a anunțat o actualizare de securitate pentru două vulnerabilități critice, descoperite de cercetătorii de la Wiz și Calif și numite colectiv php2shell. Au primit identificatorii CVE-2026-109618 și CVE-2026-109619, fiecare cu scor CVSS de 9.2 din 10. Patch-urile au fost publicate pe 21 octombrie, la 13:30 UTC. Agenția americană CISA spune că vulnerabilitățile afectează „toate instalările PHP care servesc cereri web”.

WordPress rulează pe PHP. Dacă ai un site WordPress, un magazin WooCommerce sau orice site construit pe Laravel, Symfony ori Drupal, serverul tău e expus până când PHP-ul este actualizat. Răspunsul scurt: site-ul trebuie să ruleze PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 ori mai nou. Dacă nu îl administrezi tu, cere confirmarea scrisă de la firma de hosting sau de la developer. Update-ul WordPress nu te protejează.

Versiunile PHP afectate și versiunile reparate

Sursa: CERT-EU, Security Advisory 2026-018, și alerta CISA din 23 octombrie 2026.

Ce este vulnerabilitatea php2shell, pe scurt

PHP este limbajul care rulează pe server și construiește pagina pe care o vezi în browser. Potrivit Wiz, care a participat la descoperire, PHP stă în spatele a aproximativ 70% din site-urile lumii, inclusiv Wikipedia și WordPress.

Cele două probleme, pe baza descrierilor CERT-EU și NCSC:

Fundația PHP, organizația non-profit care întreține limbajul, explică de ce situația e atât de gravă: problemele „se află în părțile din PHP pe care aproape fiecare cerere le atinge: gestionarea memoriei și tratarea erorilor”. Nu e vorba de o funcție rar folosită pe care o poți dezactiva. Este codul prin care trece fiecare vizită pe site.

În practică, un atacator poate forța intenționat o situație de lipsă de memorie care corupe memoria procesului. În anumite condiții, asta duce la executare de cod de la distanță, fără autentificare. Nu are nevoie de cont de administrator, de parolă sau de un plugin vulnerabil. Potrivit echipei PHP, un exploit demonstrat arată că o singură cerere neautentificată poate declanșa atacul înainte să ruleze orice cod al aplicației. Pentru WordPress asta înseamnă că atacul are loc înainte să se încarce WordPress, tema sau vreun plugin.

Sunt expuse toate modurile obișnuite de a rula PHP: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Echipa PHP consideră mod_php configurația cu cel mai mare risc. Multe hostinguri partajate din România folosesc LiteSpeed sau PHP-FPM, deci niciun tip de găzduire nu e scutit.

Agenția americană NSA avertizează că vulnerabilitatea poate oferi „o cale directă către sistemul de fișiere sau baza de date a serverului”. Wiz a scris că, în condițiile potrivite, atacatorii pot prelua controlul serverelor afectate și pot fura date sensibile. Pentru un site WordPress asta înseamnă baza de date cu utilizatori, comenzi, adrese și emailuri, plus fișierul wp-config.php cu parolele de acces la baza de date.

De ce update-ul WordPress nu te protejează

Aici greșesc cei mai mulți proprietari de site-uri. Vulnerabilitatea este în PHP, nu în WordPress. WordPress este o aplicație scrisă în PHP. Interpretorul PHP care o rulează este instalat separat, pe server, și îl administrează de obicei firma de hosting.

BBC a transmis explicit recomandarea: dacă site-ul tău este administrat de o firmă de hosting sau de un developer, contactează-i și întreabă dacă patch-urile de securitate pentru PHP au fost aplicate. Problema trebuie rezolvată în PHP și nu poate fi rezolvată prin actualizarea WordPress sau a pluginurilor.

Un plugin de securitate precum Wordfence sau Sucuri nu schimbă asta. Pluginul rulează în interiorul WordPress, iar atacul se produce înainte ca WordPress să pornească. Pluginul poate ajuta la detectarea unei compromiteri, dar nu înlocuiește patch-ul. CISA notează că un firewall pentru aplicații web (WAF) aflat în fața serverului, cum e cel de la Cloudflare sau de la hosting, poate oferi o protecție parțială până la actualizare. Nici acesta nu înlocuiește patch-ul.

A treia vulnerabilitate: CVE-2026-115560

Pe 23 octombrie, PHP a anunțat o a treia vulnerabilitate de tip executare de cod de la distanță, CVE-2026-115560. Potrivit CERT-EU, ea afectează doar aplicațiile configurate neobișnuit, iar echipa PHP consideră riscul puțin probabil. Detaliile tehnice nu sunt publice încă.

PHP nu va publica un release de urgență pentru ea. Remedierea vine în următorul release de bugfix. Până atunci, protecția completă cere setarea session.upload_progress.enabled=0 și repornirea tuturor workerilor PHP. Aceeași setare ajută și împotriva CVE-2026-109619, deci merită aplicată oricum. Pe hostingul partajat, o poate aplica doar furnizorul.

Este vulnerabilitatea exploatată deja?

Încercările de exploatare sunt masive. Atacuri reușite confirmate nu fuseseră raportate până vineri, 23 octombrie 2026. CISA nu observase exploatare reușită la momentul publicării alertei, iar NCSC nu văzuse nicio compromitere reușită în primele 24 de ore. CERT-EU avertizează însă că detaliile tehnice se discută public și că circulă deja primele exploit-uri demonstrative (PoC), ceea ce crește probabilitatea ca atacatorii să exploateze deja vulnerabilitățile. Firma de securitate Hadrian spune însă că vede „exploatare la scară largă”, iar cifrele confirmă asta:

• Matthew Prince, CEO Cloudflare, a declarat că rețeaua companiei a văzut mii de încercări de exploatare în cele 10 ore dinaintea anunțului public, zeci de mii în primele 45 de minute după anunț, sute de mii în două ore și apoi milioane.
• Amazon Threat Intelligence a detectat o încercare de exploatare php2shell pe un honeypot, de la o adresă IP anonimizată, cu patru zile înainte de dezvăluirea publică. Nu e clar cum a obținut atacatorul informațiile.
• Dezvăluirea era sub embargo până pe 22 octombrie, ca site-urile să aibă timp de actualizare. Fundația PHP a observat însă că detaliile circulau deja pe forumuri și rețele sociale și a anticipat anunțul. Potrivit NCSC, asta a creat o fereastră de 12-14 ore în care atacatorii puteau căuta site-uri vulnerabile înainte să existe patch.

Salil Kanhere, cercetător la UNSW Sydney, avertizează că vor urma mai multe încercări de exploatare în săptămânile următoare, pe măsură ce detaliile tehnice devin publice. Experții citați de BBC subliniază că cele mai expuse sunt site-urile întreținute slab, în special ale firmelor mici fără resurse dedicate de securitate. Asta descrie majoritatea site-urilor WordPress din România.

Concluzia practică: lipsa atacurilor raportate nu înseamnă că site-ul tău nu a fost atins. Efectele unei compromiteri apar adesea după săptămâni.

Cine a fost afectat

Alerta din 21 octombrie a produs opriri preventive în toată lumea:

• Wikimedia a oprit o parte din sisteme ca măsură de precauție.
• Guvernul Finlandei, consiliul local din Edinburgh, câteva pagini BBC și site-ul agenției de securitate cibernetică a Olandei au fost scoase offline temporar.
• Universitatea din Geneva și-a oprit site-ul după apelul CERT-EU, echipa de răspuns la urgențe informatice a instituțiilor europene.
• Guvernul britanic a scos preventiv 32 de site-uri, niciunul dintre serviciile publice mari.
• Orange a suspendat la nivel global accesul la anumite servicii cât timp a aplicat patch-urile.
• În Japonia, SoftBank a suspendat temporar alertele de urgență pentru cutremure și tsunami.

Site-uri guvernamentale din Franța, Olanda, Canada, Japonia și Germania au fost oprite temporar cât s-a aplicat patch-ul. Doar în Marea Britanie, NCSC a trimis 50.000 de alerte către organizații cu sisteme afectate.

NSA a cerut tuturor organizațiilor care folosesc PHP să își scoată sistemele offline dacă nu le pot actualiza imediat. Alerte similare au emis autoritățile din UE, Singapore și Australia.

Fundația PHP a publicat patch-urile miercuri, 21 octombrie, cu mesajul: „Toți utilizatorii PHP sunt sfătuiți insistent să actualizeze imediat.”

Checklist: ce faci azi dacă ai un site WordPress

Ordinea de mai jos urmează recomandările CISA, CERT-EU și NCSC, adaptate pentru un site WordPress de firmă.

1. Află ce versiune de PHP rulează site-ul

În panoul WordPress, mergi la Instrumente → Sănătatea site-ului → Informații → Server. Acolo apare versiunea PHP, de exemplu 8.3.x. Notează numărul complet, inclusiv ultima cifră.

În cPanel, versiunea apare la Select PHP Version sau MultiPHP Manager. În Plesk, la setările PHP ale domeniului.

2. Compară cu versiunile reparate

Contează ultima cifră, nu doar ramura. 8.3.36 e reparat, 8.3.35 nu. Site-ul este protejat împotriva primelor două vulnerabilități doar dacă rulează cel puțin:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

O excepție: distribuțiile Linux (Debian, Ubuntu, RHEL și altele) au primit patch-urile în avans și le pot livra în pachete proprii. Acestea păstrează uneori numărul vechi de versiune, deși includ reparația. Dacă versiunea afișată pare veche, nu trage concluzii singur. Cere confirmarea furnizorului (pasul 3).

Dacă site-ul rulează PHP 8.1, 8.0, 7.4 sau mai vechi, ești în cea mai riscantă situație. Aceste ramuri nu mai primesc release-uri oficiale. Echipa PHP a publicat, excepțional, backport-uri minimale de cod sursă pentru 7.4, 8.0 și 8.1, dar ele sunt pentru cine își compilează singur PHP. Unele distribuții și furnizori LTS oferă pachete cu reparația. Calea sigură este trecerea la PHP 8.2.35 sau mai nou. Cu PHP 8.2 sau 8.3, WordPress și majoritatea pluginurilor actuale funcționează fără probleme. Temele și pluginurile vechi, neactualizate de ani de zile, pot da erori, așa că testează întâi pe o copie de staging. CISA recomandă ca sistemele care rămân pe PHP 8.1 sau mai vechi să fie scoase offline până la actualizare.

3. Scrie-i firmei de hosting, chiar dacă versiunea pare bună

Pe hostingul partajat nu poți actualiza tu PHP. O poate face doar furnizorul. Trimite un mesaj scurt:

Bună ziua, vă rog să confirmați dacă pe serverul care găzduiește domeniul [domeniu.ro] au fost aplicate patch-urile PHP pentru CVE-2026-109618 și CVE-2026-109619 (PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 sau pachet de distribuție echivalent), la ce versiune exactă rulează PHP acum și dacă ați setat session.upload_progress.enabled=0 pentru CVE-2026-115560.

Cere răspuns în scris, cu versiunea exactă. Un răspuns de tipul „serverele noastre sunt sigure”, fără număr de versiune, nu e suficient.

Dacă ai VPS sau server dedicat administrat de tine, actualizarea e responsabilitatea ta. Ethical hackerul Ken Munro o compară cu un Windows Update. Fă întâi backup, apoi actualizează pachetele PHP din repository-ul distribuției și repornește PHP-FPM sau serverul web, ca toți workerii să încarce noua versiune. Atenție dacă folosești repository-ul rpms.remirepo.net: e întreținut de voluntari și nu a avut update în ziua lansării. Echipa PHP recomandă trecerea la pachetele distribuției sau compilarea din sursă.

4. Dacă nu poți actualiza imediat

Echipa PHP e clară: doar actualizarea repară complet vulnerabilitățile. Măsurile temporare reduc expunerea pe anumite căi de atac, dar nu fac instalarea sigură. CERT-EU le rezumă astfel:

Pentru CVE-2026-109618 (coruperea memoriei la OOM):

• memory_limit=-1, setat astfel încât aplicația să nu-l poată suprascrie, de exemplu cu php_admin_value în pool-ul FPM sau în configurația Apache. WordPress își ridică singur limita de memorie, deci setarea obișnuită nu ajunge. Verifică și că nicio altă setare nu reintroduce o limită finită.
• post_max_size mic: 8M dacă site-ul nu are upload de fișiere, 32M dacă are. upload_max_filesize trebuie să rămână sub post_max_size.
• limite la nivel de server web sau proxy pentru dimensiunea cererii, numărul de câmpuri, numărul de părți multipart, numărul de headere și adâncimea de imbricare;
• o limită de memorie la nivel de container sau cgroup, de preferat una care oprește doar workerul afectat. Nu folosi RLIMIT_AS sau RLIMIT_DATA, pentru că pot declanșa chiar eroarea vulnerabilă.

Pentru CVE-2026-109619 (starea globală rămasă după eliberare):

• session.upload_progress.enabled=0 în php.ini, în pool-ul FPM sau în configurația serverului, urmat de repornirea tuturor workerilor. ini_set() și fișierele .user.ini nu funcționează pentru asta.
• pe PHP 8.5, fatal_error_backtraces=0 și repornirea workerilor;
• eliminarea setărilor invalide sau depreciate care generează avertismente înainte de inițializare. Ascunderea avertismentelor cu error_reporting, display_errors sau @ nu ajută.
• repararea erorilor fatale și a timeout-urilor pe care un atacator le poate provoca, inclusiv în upload, import și callback-uri.

Pe hostingul partajat, aproape toate aceste setări sunt la nivel de server, deci le poate aplica doar furnizorul. Din WordPress sau din .user.ini nu le poți face efective.

Dacă nici atenuarea nu e posibilă, CERT-EU, NCSC și CISA recomandă același lucru: izolează site-ul de internet sau oprește-l temporar până la remediere. Pentru un magazin online e o decizie grea. Hadrian a rezumat-o așa: „Oprirea unui serviciu pentru câteva ore costă mult mai puțin decât un server compromis.” O breșă de date pe care trebuie s-o raportezi la ANSPDCP te costă mult mai mult decât o zi offline.

5. Verifică dacă site-ul a fost deja compromis

Atacurile au început înainte de anunțul public. Dacă site-ul a rulat nepatch-uit după 21 octombrie, verifică înainte sau imediat după update:

• utilizatori administratori noi pe care nu îi recunoști, în Utilizatori → Toți utilizatorii;
• **fișiere .php în wp-content/uploads**, unde în mod normal stau doar imagini și documente;
• fișiere modificate recent în rădăcina site-ului, în wp-includes sau în wp-admin;
• modificări în wp-config.php sau în .htaccess, cum sunt redirecturi spre alte domenii;
• task-uri cron necunoscute pe server sau în WordPress;
• trafic de ieșire neobișnuit sau emailuri trimise de pe server fără motiv;
• procese PHP care pornesc un shell sau descarcă unelte (de exemplu sh, bash, curl sau wget lansate de utilizatorul sub care rulează PHP-FPM ori serverul web). CISA indică exact acest tipar ca semn principal de exploatare și a publicat o regulă de detecție SIGMA pentru loguri. Don Smith, de la Sophos Counter Threat Unit, face aceeași recomandare.

Dacă găsești ceva suspect, nu șterge fișierele la întâmplare. Fă o copie a site-ului și a logurilor pentru analiză, apoi schimbă parolele pentru baza de date, FTP/SFTP, panoul de hosting și conturile de administrator, plus cheile din wp-config.php. Un backdoor rămas pe server face patch-ul inutil, pentru că atacatorul are deja acces.

6. Nu uita restul echipamentelor care rulează PHP

Daniel Stewart, de la LRQA, amintește că PHP nu există doar în site-uri. Îl găsești și în interfețele de administrare ale routerelor, load balancerelor, NAS-urilor și altor echipamente de rețea, care sunt adesea uitate în astfel de incidente. NCSC-NL, agenția olandeză, menține pe GitHub un inventar al produselor potențial afectate: github.com/NCSC-NL/php2shell. Aplică update-urile producătorilor pe măsură ce apar.

WordPress pe hosting administrat vs. hosting partajat ieftin

Ultimul rând e cel mai periculos și cel mai frecvent. Site-ul funcționează, nimeni nu se mai uită la el, iar PHP-ul de pe server a rămas la versiunea de acum trei ani. Ken Munro a spus-o direct: dacă îți administrezi singur site-ul, e responsabilitatea ta să te asiguri că patch-urile sunt aplicate.

Ce schimbă php2shell pentru firmele mici

Problemele nu sunt noi. Au stat nedescoperite în PHP mai bine de un deceniu și au fost găsite la jumătatea lui august 2026, cu ajutorul unor modele AI de analiză a codului. Kanhere a rezumat: bug-urile nu erau noi, s-a schimbat capacitatea noastră de a le găsi.

Aceeași capacitate o au și atacatorii. Paul Spain, CEO Gorilla Cyber Security, a avertizat că AI-ul poate face astfel de atacuri mai ușoare și mai rapide. Pentru un site WordPress de firmă, intervalul dintre publicarea unei vulnerabilități și primele atacuri automate nu se mai măsoară în săptămâni, ci în ore. Cifrele Cloudflare de mai sus o arată.

Sigi Goode, profesor la Australian National University, a observat că problema nu sunt site-urile oprite pentru actualizare: „Îngrijorarea mai mare sunt site-urile care nu sunt oprite azi. Sunt ținte clare.” Iar Don Smith, de la Sophos, a spus că provocarea imediată nu e instalarea patch-ului, ci găsirea fiecărui loc în care rulează PHP.

Practic, „site-ul merge, nu-l mai atingem” nu mai e o strategie. Un site are nevoie de cineva care să urmărească alertele, să aplice actualizările de server, nu doar de WordPress, și să verifice periodic dacă nu s-a strecurat nimic. Asta înseamnă mentenanță website reală.

Cum te putem ajuta

Dacă nu știi pe ce versiune de PHP rulează site-ul, nu ai primit răspuns de la hosting sau bănuiești că site-ul a fost compromis:

• Verificare și patch: identificăm versiunea PHP, aplicăm actualizarea sau o coordonăm cu furnizorul de hosting și confirmăm în scris rezultatul.
• Verificare de compromitere: căutăm backdoor-uri, utilizatori adăugați, fișiere modificate și redirecturi injectate. Detalii la audit de securitate.
• Reparație după incident: dacă site-ul a fost deja afectat, curățăm, restaurăm din backup și închidem accesul rămas. Vezi reparații website.

Scrie-ne la office@smetytech.com cu domeniul site-ului și numele firmei de hosting. Pentru incidentele php2shell răspundem cu prioritate.

Surse

• CISA (SUA), Critical Vulnerabilities in PHP Require Immediate Patching, publicat 21 octombrie 2026, actualizat 23 octombrie 2026
• PHP, anunțul oficial de securitate
• NCSC (Marea Britanie), Critical security issue affecting PHP, publicat 21 octombrie 2026, actualizat 23 octombrie 2026
• CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP, v1.2 din 23 octombrie 2026
• BBC News, What is PHP and why did it spark a global cyber-security scramble?
• The Guardian, What is PHP? The computer language flaw causing global website shutdowns
• NCSC-NL, inventar produse afectate php2shell