Publicat 4 min de citit
Vulnerabilitățile PHP și Node.js: ce verifici la site-ul firmei tale
Ce au reparat actualizările din octombrie 2026, ce problemă PHP rămâne de urmărit și ce dovezi să ceri firmei care îți administrează site-ul.
Nick TaylorFondator, Pitstop Technologies
Ai văzut știrea, ai trimis-o persoanei care se ocupă de site și ai primit răspunsul „ne uităm”. Între timp, clienții continuă să facă programări sau să trimită comenzi. Ce ar trebui să verifici, concret?
Nu trebuie să devii specialist în securitate. Ai însă nevoie de un răspuns verificabil: ce sisteme folosești, dacă sunt afectate, cine intervine și cum confirmă că intervenția s-a încheiat. Pentru mine, acesta este unul dintre motivele serioase pentru care merită să existe mentenanță după lansare.
Informații verificate la 25 octombrie 2026. Actualizările PHP și Node.js din 21 octombrie rezolvă probleme diferite. Prezența unei versiuni vulnerabile nu demonstrează că un anumit site a fost atacat cu succes.
De la avertizare la verificare
Actualizarea se încheie în aplicația care rulează.
Bibliotecile pot fi actualizate, deși runtime-ul serverului este încă vechi.
Runtime-ul face parte din imaginea instalată.
$ node --version
$ php --versionFolosește comanda potrivită runtime-ului tău. Compară rezultatul cu versiunea de securitate aplicabilă.
Actualizarea bibliotecilor nu schimbă automat runtime-ul dintr-un container existent.
La PHP, actualizarea modulelor site-ului nu este suficientă
CVE-2026-109618 privește gestionarea lipsei de memorie, iar CVE-2026-109619, date interne rămase între cereri. Ambele pot permite executarea de cod fără autentificare. Pentru prima, atacul a fost demonstrat pe Apache mod_php înaintea codului aplicației; celelalte configurații trebuie evaluate. A doua presupune operații accesibile în cereri succesive prelucrate de același proces. Detaliile sunt în avertizările PHP din 21 octombrie despre memorie și starea internă păstrată între cereri.
Versiunile corectate pentru aceste două probleme sunt 8.2.35, 8.3.36, 8.4.27 și 8.5.12. Un furnizor poate integra remedierea într-un pachet propriu; verificarea trebuie făcută și după documentația lui, nu doar după numărul versiunii. Situația tehnică publicată de NCSC.
Dacă ai WordPress, faptul că extensiile sunt la zi nu confirmă și actualizarea PHP. Firma care întreține site-ul poate administra aplicația, iar furnizorul de găzduire, mediul în care rulează. Responsabilitatea trebuie clarificată între ei, fără ca tu să fii nevoit să ghicești cine a rămas cu problema.
La Node.js contează și ce prelucrează aplicația
CVE-2026-111497 afectează decodorul Brotli inclus în Node.js. Calea descrisă presupune ca aplicația să decomprime date Brotli controlate de un atacator, prin node:zlib. Urmările pot fi oprirea procesului, divulgarea datelor din memorie sau executarea de cod. Remedierile sunt în 22.23.4, 24.22.1 și 26.12.1. Actualizarea rezolvă și alte probleme: evaluarea Brotli nu înlocuiește instalarea ei. Anunțul Node.js din 21 octombrie.
Nu poți afla infrastructura unei firme doar fiindcă vezi JavaScript în browser. Pot exista procese separate pentru notificări, importuri sau prelucrarea comenzilor. Și ele trebuie incluse în verificare, chiar dacă pagina principală funcționează impecabil.
De ce contează data unei avertizări
În actualizarea din 23 octombrie, NCSC din Țările de Jos a precizat că exploatarea PHP este mai dificilă decât estimase inițial, iar incidentul posibil cunoscut în străinătate nu era confirmat. Recomandarea de actualizare a rămas. Evaluarea din 23 octombrie nu exclude însă posibilitatea unui atac.
Tot pe 23 octombrie, PHP a anunțat CVE-2026-115560, neremediată de versiunile de mai sus. Problema apare în configurații care urmăresc progresul încărcărilor și schimbă, în timpul execuției, gestionarul de serializare a sesiunii din php_binary sau php_serialize în php. PHP recomandă dezactivarea funcției de progres până la următoarea versiune corectivă; aplicațiile care nu schimbă gestionarul nu intră în această situație. Administratorul trebuie să verifice configurația. Precizările PHP din 23 octombrie.
Cinci lucruri pe care le poți cere furnizorului
- Un inventar și un responsabil. Include site-ul, portalul, procesele automate și serviciile administrate de alte firme. Pentru fiecare trebuie să fie clar cine poate interveni și cine îți confirmă rezultatul.
- Dovada versiunii care rulează. Cere versiunea instalată efectiv, situația pachetului furnizorului și data verificării. Un fișier modificat sau o actualizare disponibilă în panou nu demonstrează că serverul folosește deja remedierea.
- O intervenție pregătită. Stabiliți verificările de compatibilitate, copiile de siguranță recuperabile și modul de revenire dacă apar probleme. Serviciile expuse trebuie prioritizate. Orice măsură temporară are nevoie de un responsabil și limite explicate.
- Probe după intervenție. Administratorul verifică din nou versiunea și procesele active. Apoi testați ce contează pentru firmă: autentificare, formular, comandă, programare și notificările aferente. Păstrați rezultatele, nu doar mesajul „gata”.
- Verificarea activității neobișnuite. Fișierele, conturile, procesele sau conexiunile neașteptate cer investigație. Dacă apar indicii de incident, păstrați dovezile. Instalarea unei remedieri nu dovedește că efectele unui atac anterior au dispărut.
Un raport scurt, cu versiuni, responsabil și verificări, spune mai mult decât o promisiune vagă de securitate. Asta aș vrea să primesc dacă aș plăti pe cineva să aibă grijă de platforma firmei mele.
Spune-ne ce site sau aplicație folosești. Putem stabili ce trebuie verificat și ce intră într-un acord de mentenanță, cu responsabilități clare. O evaluare serioasă începe cu sistemul real, nu cu aspectul paginii principale.
