Pe scurt: Cine mai rulează PHP 8.1 sau mai vechi nu mai primește de la proiectul PHP actualizări oficiale de securitate, nici pentru PHP2Shell. Un upgrade de la PHP 8.1 la o versiune susținută nu este, de aceea, o opțiune facultativă, ci soluția propriu-zisă. Verificăm aplicațiile dumneavoastră, testăm pe o copie, migrăm controlat și protejăm perioada până atunci.
De ce PHP 8.1 și versiunile mai vechi sunt acum un risc acut
Vulnerabilitățile PHP2Shell CVE-2026-109618 și CVE-2026-109619 permit execuția de cod fără autentificare. Ele sunt remediate în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Pentru PHP 8.1 și versiunile mai vechi nu mai există actualizări oficiale, ci doar backporturi minime în codul sursă pentru 7.4, 8.0 și 8.1. Potrivit presei de specialitate, sunt afectate aproape toate versiunile, până înapoi la PHP 5.4.
Unele distribuții și unii furnizori de hosting aplică propriile backporturi. Dacă sistemul dumneavoastră se numără printre ele trebuie să confirme furnizorul, pentru starea concretă a pachetelor dumneavoastră. Fără această confirmare, ar trebui să porniți de la premisa că serverul este deschis. Ce înseamnă asta în detaliu descrie PHP 8.1 și versiuni mai vechi: ce se aplică acum.
Upgrade de la PHP 8.1: ce versiune-țintă?
Ținta ar trebui să fie o versiune pe care proiectul PHP o susține încă și pe care aplicația dumneavoastră o acceptă. Starea actuală a suportului este publicată de php.net pe pagina versiunilor susținute. PHP 8.2 se încheie la 31.12.2026; o trecere la 8.2 ar fi, așadar, doar o etapă intermediară, cu un nou proiect în curând.
Ce versiune PHP acceptă CMS-ul sau sistemul dumneavoastră de magazin verificăm pe baza cerințelor de sistem ale producătorului, de exemplu pe wordpress.org, shopware.com sau typo3.org, și nu din memorie. Adesea trebuie actualizat mai întâi CMS-ul însuși. Magazinele vechi sunt un caz tipic, vezi Shopware 5: magazine vechi pe versiuni PHP vechi.
Cum ajută PHP SOS concret?
- Inventar și protejare: Inventariem toate aplicațiile, versiunea lor PHP, starea CMS-ului, extensiile și codul propriu. În paralel aplicăm măsurile provizorii conform php.net, pentru ca riscul să scadă până la migrare; detalii la WAF și patching virtual.
- Verificarea compatibilității: Confruntăm cerințele de sistem ale producătorilor, verificăm dependențele cu Composer și căutăm în codul propriu funcții învechite. Cum arată asta la dependențe descrie Cum verificați dependențele Composer pentru vulnerabilități.
- Test pe o copie: Aplicația rulează mai întâi într-un mediu de test cu noua versiune PHP. Erorile le remediem acolo sau le documentăm pentru agenția dumneavoastră.
- Trecerea cu cale de întoarcere: Trecerea în producție se face într-o fereastră de mentenanță agreată, cu backup actual și cu o cale de întoarcere stabilită.
- Controlul ulterior: După trecere verificăm jurnalele de erori și funcțiile centrale și eliminăm vechea versiune PHP dacă nu mai este necesară.
O privire inofensivă asupra versiunii PHP folosite de site-uri este posibilă pe multe sisteme prin pool-urile FPM aflate în execuție:
# afișează procesele master și pool-urile PHP-FPM în execuție
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# versiuni PHP instalate (Debian/Ubuntu)
ls /etc/php/
Un upgrade la o nouă versiune PHP nu elimină software-ul malițios introdus anterior. Dacă serverul a fost expus în rețea fără protecție din 17.10.2026, face parte din proces și o verificare a urmelor.
Obstacole tipice la upgrade
Majoritatea problemelor la schimbarea versiunii PHP sunt previzibile, dacă știți unde să căutați:
- Extensii învechite: Plugin-urile sau modulele care nu mai sunt întreținute nu rulează adesea pe versiuni PHP mai noi. Pentru ele este nevoie de un înlocuitor sau de o adaptare.
- Cod propriu: Funcțiile pe care PHP le-a marcat între timp ca învechite sau le-a eliminat duc la avertismente sau la întreruperi. Verificările de tip mai stricte scot la iveală erori vechi de programare.
- Dependențe: Bibliotecile integrate prin Composer cer uneori ele însele versiuni noi și atrag după sine alte modificări.
- Extensiile PHP de pe server: Nu orice extensie instalată sub versiunea veche există automat și pentru cea nouă.
- Cronjoburi și linie de comandă: Site-ul rulează deja pe noua versiune, dar sarcinile programate apelează încă vechea versiune PHP.
Cine verifică aceste puncte dinainte scurtează trecerea și evită surprizele în funcționarea reală.
Ce primiți și de ce avem nevoie
Primiți o privire de ansamblu asupra tuturor aplicațiilor, cu versiunea de pornire și cea țintă, un plan de migrare cu ordine și riscuri, un protocol de test, documentarea trecerii și o listă de puncte pe care agenția sau dezvoltatorul dumneavoastră trebuie încă să le rezolve.
De la dumneavoastră avem nevoie de:
- acces la server sau la panou și acces la backendurile CMS
- acces la codul sursă și la repository pentru dezvoltările proprii
- contact cu agenția sau dezvoltatorul care cunosc aplicația
- un mediu de test sau acordul de a crea unul
- fereastră de mentenanță și un interlocutor pentru recepție
Ce nu promitem
Nu promitem că orice aplicație veche rulează fără modificări pe o versiune PHP nouă. La sistemele fără dezvoltare ulterioară poate fi necesară o refacere mai mare sau o schimbare; spunem asta deschis, de îndată ce se conturează. Afirmațiile despre compatibilitate le sprijinim pe datele producătorilor. Iar măsurile provizorii nu sunt un substitut pentru migrare, ci doar acoperă perioada. Riscurile pe termen lung ale versiunilor învechite le descrie PHP End of Life: riscurile versiunilor învechite.
Întrebări frecvente
Este PHP 8.1 afectat de PHP2Shell?
Potrivit presei de specialitate, sunt afectate aproape toate versiunile, până înapoi la PHP 5.4. Pentru PHP 8.1 și versiunile mai vechi nu există actualizări oficiale din partea proiectului PHP, ci doar backporturi minime în codul sursă pentru 7.4, 8.0 și 8.1. Unele distribuții aplică propriile backporturi, iar acest lucru trebuie confirmat de furnizorul respectiv.
La ce versiune PHP ar trebui să fac upgrade?
La o versiune pe care proiectul PHP o susține încă activ și pe care aplicația dumneavoastră o acceptă conform cerințelor de sistem ale producătorului. PHP 8.2 ajunge la 31.12.2026 la sfârșitul suportului și este, de aceea, ca țintă doar condiționat potrivit.
Nu pot pur și simplu să schimb versiunea PHP din panoul de hosting?
Tehnic, adesea se poate cu un singur clic. Dacă aplicația mai funcționează după aceea depinde de versiunea CMS-ului, de extensii și de codul propriu. Fără test riscați căderi sau funcții defectuoase, de exemplu la finalizarea comenzii într-un magazin.
Ce fac dacă CMS-ul meu nu acceptă noua versiune PHP?
Atunci trebuie actualizat mai întâi CMS-ul, eventual la o nouă versiune majoră. La sistemele fără dezvoltare ulterioară poate fi necesară o schimbare. Până atunci protejăm serverul prin măsuri provizorii.