Versiunea ta de PHP sau Node.js nu mai primește corecturi: ce înseamnă și ce opțiuni ai

PHP2Shell și vulnerabilitatea Node.js din octombrie 2026 au primit fix doar pe versiunile suportate. Ce înseamnă sfârșitul suportului și ce poți face, de la backport la migrare.

Pe 21 octombrie 2026 au apărut două actualizări de securitate importante pentru limbajele pe care rulează multe site-uri și aplicații de firmă. PHP a corectat două vulnerabilități critice, cunoscute ca PHP2Shell. Node.js a corectat, printre altele, o vulnerabilitate gravă în decodorul de compresie Brotli (CVE-2026-111497). Corecturile au venit însă doar pentru versiunile aflate încă în suport. Cine rulează o versiune mai veche a primit aceeași vulnerabilitate, dar fără fix.

Articolul explică, pentru proprietari și manageri, ce înseamnă o versiune „ieșită din suport”, de ce contează tocmai acum și ce opțiuni ai, de la cea mai rapidă la cea mai costisitoare.

Fiecare versiune majoră de PHP sau Node.js are un calendar public. O perioadă primește îmbunătățiri și corecturi, apoi o perioadă doar corecturi de securitate, iar la final ajunge la sfârșitul ciclului de viață (EOL, de la „end of life”). După această dată, echipa care întreține limbajul nu mai publică nimic pentru ea, nici măcar când apare o vulnerabilitate critică.

Pentru PHP, calendarul oficial arată astăzi așa:

• PHP 8.5: corecturi de securitate până la 31 decembrie 2029;
• PHP 8.4: până la 31 decembrie 2028;
• PHP 8.3: doar corecturi de securitate, până la 31 decembrie 2027;
• PHP 8.2: doar corecturi de securitate, până la 31 decembrie 2026;
• PHP 8.1: fără suport din 31 decembrie 2025;
• PHP 8.0: fără suport din 26 noiembrie 2023;
• PHP 7.4: fără suport din 28 noiembrie 2022;
• PHP 5.6: fără suport din 31 decembrie 2018.

Pentru Node.js, aplicațiile de producție ar trebui să ruleze o versiune cu suport pe termen lung (LTS):

• Node.js 18: fără suport din 30 aprilie 2025;
• Node.js 20: fără suport din 30 aprilie 2026;
• Node.js 22: suport până la 30 aprilie 2027;
• Node.js 24: suport până la 30 aprilie 2028;
• Node.js 26: devine LTS pe 28 octombrie 2026, cu suport până la 30 aprilie 2029.

Corecturile din 21 octombrie au fost publicate pentru PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35, iar pentru Node.js 26.12.1, 24.22.1 și 22.23.4. Echipa Node.js spune explicit că versiunile ieșite din suport sunt afectate la fiecare lansare de securitate, chiar dacă nu apar în anunț.

Problema nu e una teoretică. Potrivit datelor Modat citate de The Hacker News, din circa 4,38 milioane de servicii PHP expuse pe internet, aproximativ 79% rulau pe ramuri fără suport. VulnCheck a numărat peste 700.000 de servere încă pe PHP 3.x până la 7.3. DNSC notează că instalările ieșite din suport au riscul cel mai mare și recomandă corectarea lor prin backport-uri, izolarea și migrarea cu prioritate.

Întreabă furnizorul de hosting sau firma care îți administrează aplicația ce versiune rulează efectiv pe server, nu ce scrie într-un document vechi. Pe WordPress, versiunea PHP apare în Unelte → Sănătate site → Informații → Server. Pentru o aplicație Node.js, cine o administrează o vede imediat pe server sau în configurația de build. Merită să ceri răspunsul în scris, cu data verificării.

Dacă ești pe PHP 8.2–8.5 sau pe Node.js 22, 24 ori 26, ai noroc: instalezi versiunea corectată din aceeași ramură și repornești procesele. De obicei nu se schimbă nimic în cod. E o lucrare de ore, nu de zile, cu condiția să existe un backup și o verificare după.

Atenție totuși la PHP 8.2: primește fixul acum, dar iese din suport pe 31 decembrie 2026. Dacă oricum faci o intervenție, e mai ieftin să planifici de pe acum trecerea la 8.4 sau 8.5.

Pentru PHP 7.4, 8.0 și 8.1, echipa PHP a publicat corecturi minimale în cod sursă. Ele nu sunt versiuni gata de instalat: cineva trebuie să compileze PHP, să-l testeze și să-l întrețină. Unele distribuții Linux și furnizori de suport extins oferă pachete corectate pentru versiuni vechi. Pentru Node.js, proiectul trimite la parteneri comerciali din programul OpenJS pentru versiunile ieșite din suport.

E o soluție bună ca să câștigi timp, nu ca stare permanentă. Plătești pentru suport, iar data la care trebuie să migrezi doar se mută mai încolo.

Dacă aplicația nu poate fi corectată imediat, poate fi scoasă de pe internetul public: acces doar prin VPN sau dintr-o rețea internă, filtru de aplicație (WAF) în față, funcții nefolosite oprite. E o măsură recomandată de DNSC pentru sistemele critice care nu pot fi actualizate rapid. Nu repară nimic, doar reduce cine poate ajunge la vulnerabilitate.

Asta e soluția de durată pentru majoritatea firmelor. Pe scurt, înseamnă:

• Dependențe: bibliotecile folosite de aplicație trebuie aduse la versiuni compatibile cu noul PHP sau Node.js, iar unele au fost abandonate și trebuie înlocuite.
• Cod depreciat: funcții eliminate sau comportamente schimbate între versiuni, care trebuie rescrise local.
• Teste: verificarea fluxurilor importante (comenzi, facturi, autentificare, formulare) înainte și după, ideal pe o copie a aplicației.
• Mutarea în producție: cu backup, plan de revenire și o perioadă de urmărire după.

La un site WordPress întreținut constant, migrarea e adesea o schimbare în panoul hostingului plus teste. La o aplicație scrisă acum zece ani pentru PHP 5.6 sau 7.x, e un proiect de sine stătător, pentru că diferențele dintre versiuni s-au adunat.

Uneori codul e atât de vechi sau de încâlcit încât migrarea costă aproape cât o aplicație nouă. Atunci rescrierea poate fi varianta mai cinstită, mai ales dacă oricum vrei funcții noi. Dar e o decizie mare: costă mai mult, durează mai mult și are propriile riscuri. Nu o alegi pe panică, ci după o evaluare a codului.

Trei întrebări simple ajută la alegere:

1. Cât de expusă e aplicația? Un site public cu formulare și conturi de clienți e mai urgent decât un instrument intern folosit din birou.
2. Cât de departe e versiunea ta de una suportată? De la 8.1 la 8.4 e un pas mic; de la 5.6 la 8.4 e un drum lung.
3. Cât mai vrei să trăiască aplicația? Dacă o înlocuiești oricum peste câteva luni, izolarea și un backport pot fi suficiente. Dacă e coloana vertebrală a firmei, migrarea e o investiție.

În practică, ordinea rezonabilă e: izolezi sau corectezi ce e expus acum, apoi planifici migrarea cu un buget și un calendar clar, înainte de următoarea vulnerabilitate.

La ME Digital facem exact acest traseu pentru firme: evaluăm codul, aplicăm corecturile disponibile, izolăm ce nu poate aștepta și migrăm aplicațiile vechi pe versiuni suportate, prin serviciile de securitate și actualizări. Dacă nu știi pe ce versiune rulează aplicația ta, scrie-ne și verificăm împreună.

• PHP, versiunile suportate
• PHP, versiunile ieșite din suport
• PHP, anunțul de securitate din 21 octombrie 2026
• Node.js, calendarul versiunilor
• Node.js, versiunile anterioare și suportul
• Node.js, lansările de securitate din octombrie 2026
• The Hacker News, expunerea serverelor PHP (datele Modat și VulnCheck)
• DNSC, Alertă: vulnerabilități critice în PHP