Vulnerabilitatea critică din PHP: ce înseamnă pentru site-ul firmei și ce schimbă, de fapt, WordPress sau Next.js

Pe scurt

Ce s-a întâmplat

PHP e limbajul în care sunt scrise WordPress și o bună parte din internet: îl folosesc 69,2% dintre site-urile la care se știe limbajul de pe server. În octombrie s-au găsit în el două erori de gestionare a memoriei, cu efect grav: un atacator putea rula propriul cod pe server, cu drepturile site-ului, fără să știe vreo parolă.

Cele două probleme au coduri separate. CVE-2026-109618 apare când PHP rămâne fără memorie în mijlocul citirii unei cereri, iar CVE-2026-109619 lasă în urmă date dintr-o cerere care sunt folosite, greșit, de următoarea. Pentru cititorul care nu e programator, partea importantă e alta: prima lovește înainte să ruleze codul site-ului. Parolele, formularele sau pluginurile de securitate din WordPress nu ajung să intervină.

Cât de răspândită e expunerea: echipa Unit 42 de la Palo Alto Networks a numărat peste 22,6 milioane de instalări expuse pe internet și potențial vulnerabile, pe 23 octombrie.

Cine e afectat

Pe scurt: orice site care rulează pe PHP, deci aproape orice site WordPress, magazin WooCommerce, PrestaShop sau OpenCart. Contează versiunea de PHP de pe server, nu versiunea WordPress.

Ce am măsurat pe site-urile românești

Am folosit aceeași listă ca în studiul despre butonul de retragere: site-urile declarate la Registrul Comerțului de firme active, care funcționează. Pe 29 octombrie, am deschis o dată prima pagină a fiecăruia, ca un vizitator, și am citit ce spune singur serverul. 2.843 de site-uri au răspuns.

Trei lucruri ies din tabel. Unu: aproape un site de firmă din două e pe WordPress. În lume, W3Techs îl găsește pe 39,5% dintre toate site-urile, măsurat altfel, deci cifrele nu se compară direct. Doi: cine actualizează, actualizează repede. Nouă din zece servere pe versiuni suportate aveau reparația în primele opt zile, ceea ce spune ceva bun despre firmele de găzduire. Trei: mai mult de jumătate dintre serverele care își arată versiunea stau pe PHP 7 sau chiar 5, pentru care proiectul PHP nu mai publică actualizări.

O versiune veche afișată nu înseamnă sigur un site vulnerabil: unele firme de găzduire aplică reparații și pe versiunile vechi, fără să schimbe numărul. Și invers, 89% dintre servere nu-și arată versiunea deloc. Detaliile, la metodă.

Ce ai de făcut

1. Întreabă firma de găzduire, în scris: „Pe ce versiune de PHP rulează site-ul meu și are reparația pentru CVE-2026-109618 și CVE-2026-109619?”. Dacă e găzduire administrată, de obicei au făcut-o deja.
2. Dacă ești pe PHP 8.1 sau mai vechi, cere trecerea pe o versiune suportată. Testează întâi site-ul pe o copie: temele și pluginurile vechi se pot strica la schimbarea versiunii.
3. Nu te baza pe setări în loc de actualizare. Proiectul PHP spune limpede, la fiecare versiune: „nu există atenuări complete, actualizarea e singura alegere sigură”.
4. Ascunde versiunea de PHP din antete (setarea expose_php = Off). Nu repară nimic, dar nu le mai spune roboților de scanare ce să încerce.
5. Actualizează și WordPress, tema și pluginurile. E alt risc decât PHP2Shell, dar e cel mai frecvent (mai jos).
6. Planifică PHP 8.2: suportul lui se încheie pe 31 decembrie 2026, potrivit aceluiași anunț.

WordPress sau Next.js: ce contează de fapt

După un incident ca acesta apare firesc întrebarea: n-ar fi mai bine pe altă tehnologie? Noi facem site-uri în Next.js și TypeScript, deci avem un interes să spunem „da”. Datele spun ceva mai nuanțat, așa că le punem pe toate pe masă.

Securitatea: unde se poate ataca

Codul care rulează la fiecare vizită

Un site WordPress își construiește pagina la fiecare vizită: serverul rulează PHP, citește baza de date și abia apoi trimite pagina. Fiecare vizită e deci o ușă spre cod care rulează pe server, iar PHP2Shell a lovit exact acolo.

Un site Next.js poate fi construit și altfel: paginile se generează o dată, la publicare, iar vizitatorul primește un fișier gata făcut. Dacă nu există cod care rulează pe server la fiecare vizită, o vulnerabilitate ca PHP2Shell nu are unde să lovească. Aici e avantajul real, și ține de arhitectură, nu de limbaj.

Dar și Next.js a avut probleme grave

Imediat ce un site Next.js rulează cod pe server (formulare, pagini personalizate, funcții de server), are și el ce ataca:

• React2Shell, decembrie 2025: o vulnerabilitate în componentele de server React, folosite de Next.js, cu nota maximă, 10 din 10, care permitea tot executarea de cod fără autentificare. Firmele de securitate au raportat atacuri în zilele de după anunț.
• CVE-2025-29927, martie 2025: o eroare prin care verificările de acces puteau fi ocolite (nota 9,1). Site-urile găzduite la Vercel erau protejate automat.

Deci nicio tehnologie nu e imună. Diferența practică e alta: cine actualizează și cât de repede.

Pluginurile, riscul cel mai mare la WordPress

Același raport spune că 46% dintre ele nu aveau reparație de la autor în momentul în care au devenit publice, iar timpul median până la primul atac a fost de cinci ore. WordPress în sine e bine întreținut; problema sunt pluginurile pe care le adună un site, fiecare scris de altcineva. Un site Next.js făcut la comandă nu are pluginuri de acest fel, dar are pachetele lui de cod, care trebuie și ele ținute la zi.

Viteza: nu câștigă tehnologia

Se spune des că Next.js e „mai rapid”. Am verificat în datele publice HTTP Archive, care adună măsurători de la vizitatori reali (Core Web Vitals, testul de viteză al Google), pe tehnologii:

Pe calculator, cele două sunt practic la egalitate. Pe telefon, site-urile WordPress trec testul mai des: 48,3% față de 35,7% în lume, 57,7% față de 44,4% în România. Datele nu spun de ce. O ipoteză la îndemână e că multe site-uri Next.js sunt aplicații care trimit mult JavaScript, greu de rulat pe un telefon obișnuit. Sigur e doar atât: tehnologia permite un site foarte rapid, dar nu îl garantează.

Ce face un site rapid, pe oricare dintre ele: puțin cod trimis în browser, imagini la dimensiunea potrivită, fonturi puține, scripturi de reclamă și urmărire încărcate doar când e nevoie. Site-ul nostru e făcut în Next.js tocmai ca să putem controla toate astea, nu pentru că Next.js le-ar face singur.

JavaScript și TypeScript

Next.js folosește JavaScript, de obicei cu TypeScript peste el. TypeScript adaugă tipuri: programul verifică, înainte de publicare, că fiecare bucată de cod primește genul de date la care se așteaptă. Asta prinde din start o categorie întreagă de greșeli (un câmp lipsă, un număr trimis ca text) care altfel apar abia la client.

Nu e însă o garanție de securitate. Și PHP modern are tipuri, iar React2Shell s-a petrecut în cod JavaScript. Avantajul real e altul: un singur limbaj pentru tot site-ul, verificat automat la fiecare modificare, deci mai puține surprize după publicare.

Când alegi una, când alegi cealaltă

Oricare ar fi alegerea, întrebarea importantă pentru o firmă rămâne aceeași: cine actualizează site-ul și serverul, și în cât timp după un anunț ca cel din 21 octombrie?

Metoda și limitele

• Ce am citit: antetul public X-Powered-By (unde unele servere își scriu versiunea PHP) și codul primei pagini (semnele WordPress: /wp-content/, /wp-includes/, generatorul; semnul Next.js: /_next/). O singură cerere pe site, fără scanare și fără încercări de atac.
• Versiunea afișată nu e o dovadă. Distribuțiile Linux și unele firme de găzduire repară fără să schimbe numărul, iar unele servere afișează versiunea unui intermediar. De aceea nu spunem câte site-uri sunt vulnerabile, ci doar ce versiuni anunță.
• 89% nu-și arată versiunea, deci procentele despre versiuni privesc doar 318 servere și nu pot fi extinse la toate.
• Lista de pornire: site-urile declarate la Registru de firme active, nu toate site-urile din România.
• Viteza vine din HTTP Archive, nu din măsurătoarea noastră, și compară toate site-urile care folosesc o tehnologie, fără să țină seama de cât de complexe sunt.

Cine a făcut și a plătit măsurătoarea: DEVICOM TECH SRL, firma care publică blogul și care face site-uri în Next.js. Programul l-am scris cu ajutorul unui asistent AI și l-am verificat pe site-uri reale.

Întrebări frecvente

Dacă vrei să mă uit eu

Îți spun gratuit pe ce rulează site-ul tău, ce versiune de PHP anunță și ce să-i ceri firmei de găzduire. Scrie-mi din pagina de contact, cu adresa site-ului.

Întrebări despre metodă sau despre cifre: mihai@devicom.ro. Nu publicăm rezultatele pe site-uri individuale, ca să nu numim firme. Alte surse folosite: alerta CISA, analiza Datadog, HTTP Archive.