Pe scurt: PHP End of Life înseamnă că proiectul PHP nu mai livrează actualizări de securitate pentru acea ramură. PHP2Shell arată clar consecințele, deoarece pentru PHP 8.1 și mai vechi nu există remediere oficială, iar PHP 8.2 se încheie la 31.12.2026. Cine rulează astăzi pe o ramură veche ar trebui să planifice trecerea acum, nu abia la următoarea urgență.
Ce înseamnă PHP End of Life
Fiecare ramură PHP, de exemplu 8.2 sau 8.3, este întreținută de proiectul PHP doar pentru o perioadă limitată. Mai întâi există remedieri de erori și actualizări de securitate, apoi doar actualizări de securitate. După aceea, suportul se încheie complet. Perioadele actuale le publică php.net pe pagina versiunilor acceptate.
După sfârșitul suportului, software-ul continuă să ruleze. Dacă însă devine cunoscută o vulnerabilitate nouă, de la proiectul PHP nu mai vine niciun patch. Serverul rămâne vulnerabil până când altcineva face corecturi sau până când treceți la o ramură acceptată.
Pentru conducere și conducerea IT, aceasta este în primul rând o chestiune de planificare. O migrare poate fi pregătită în liniște. Sub presiunea timpului, după un anunț critic, devine scumpă și riscantă.
Ce arată PHP2Shell despre versiunile învechite
La 21.10.2026, proiectul PHP a publicat patchuri pentru două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619. Ambele permit executarea de cod malițios de la distanță, fără autentificare, și sunt evaluate cu CVSS v4.0 9,2. Potrivit presei de specialitate, sunt afectate aproape toate versiunile până la PHP 5.4.
| Ramură | Stare conform proiectului PHP | Remedierea PHP2Shell |
|---|---|---|
| PHP 8.5 | acceptată | 8.5.12 |
| PHP 8.4 | acceptată | 8.4.27 |
| PHP 8.3 | acceptată | 8.3.36 |
| PHP 8.2 | acceptată până la 31.12.2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | fără actualizări oficiale | doar backporturi minime la nivel de sursă |
| PHP 7.3 și mai vechi | fără actualizări oficiale | niciun backport de la proiectul PHP |
Pentru 8.1 și mai vechi rămâne astfel doar calea prin backporturi ale distribuțiilor sau ale furnizorilor de hosting. Acestea afișează adesea în continuare vechiul număr de versiune, deși sunt patchuite. Dacă un backport este aplicat poate confirma cu valoare obligatorie doar furnizorul. Detalii găsiți pe pagina PHP 8.1 și mai vechi: ce se aplică acum, iar prezentarea completă la Ce versiuni PHP sunt afectate?.
PHP 8.2 a primit încă remedierea PHP2Shell, dar atinge sfârșitul suportului la 31.12.2026. Cine migrează acum de la 8.1 ar trebui să țintească direct o ramură mai nouă.
Riscurile versiunilor PHP învechite, pe scurt
Riscul de securitate este în prim-plan, dar nu este singurul. Versiunile PHP învechite atrag după ele alte probleme:
- Fără patchuri pentru vulnerabilități noi: Orice slăbiciune viitoare rămâne deschisă sau depinde de backporturile unor terți.
- Biblioteci învechite: Pachetele actuale presupun ramuri PHP mai noi. Corecturile de securitate din biblioteci nu mai pot fi atunci aplicate, așa cum arată ghidul composer audit.
- Dependența de furnizor: Furnizorii de hosting taxează uneori suplimentar versiunile vechi sau opresc funcționarea lor. Termenul îl stabilește atunci furnizorul, nu dumneavoastră.
- Probleme de justificare: Față de asigurători, clienți sau în audituri, o versiune neacceptată este greu de justificat. Dacă de aici rezultă consecințe contractuale sau juridice, clarificați cu asigurătorul sau cu un avocat.
- Efort de migrare tot mai mare: Cu cât distanța față de versiunea actuală este mai mare, cu atât mai mult cod trebuie adaptat.
Cel mai des sunt afectate sistemele de magazin mai vechi și dezvoltările individuale neatinse de mult timp. Un exemplu tipic este Shopware 5, care rulează adesea încă pe ramuri PHP mai vechi.
Inventarul: ce versiuni PHP rulează la dumneavoastră?
Primul pas este o imagine completă. Pe multe servere rulează în paralel mai multe versiuni PHP, de exemplu pentru un site vechi pe care nu-l mai are nimeni în vedere. Aceste comenzi doar citesc:
# Versiunea din linia de comandă
php -v
# Versiuni instalate pe Debian/Ubuntu
ls /etc/php/
# Versiuni instalate în Plesk
ls /opt/plesk/php/ 2>/dev/null
# Procese PHP în execuție, cu versiunea în nume
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
Consemnați pentru fiecare site: domeniul, versiunea PHP, modul de operare, CMS-ul cu versiune, persoana responsabilă. Această listă este totodată baza planului dumneavoastră de urgență. La shared hosting, găsiți de regulă versiunile în meniul de client al furnizorului de hosting.
Planificarea migrării: cum procedați
O migrare la o ramură acceptată urmează, de regulă, aceiași pași, indiferent de sistem:
- Stabiliți ținta: alegeți o ramură care, conform php.net, este încă acceptată cât mai mult timp și care, conform cerințelor de sistem ale producătorului, se potrivește CMS-ului dumneavoastră.
- Verificați compatibilitatea: CMS, extensii, teme și codul propriu. Indicațiile se găsesc pe pagina oficială a producătorului respectiv.
- Configurați staging: o copie a site-ului cu noua versiune PHP, inclusiv baza de date.
- Testați: toate fluxurile importante, de la formularul de contact până la procesul de comandă, plus logul de erori pentru avertismente.
- Comutați și reporniți: schimbați versiunea, reporniți toate procesele PHP, verificați funcționarea și logul de erori.
Planificați realist. Un site mic cu un CMS actual este adesea comutat rapid. Un magazin crescut de-a lungul anilor, cu multe extensii și cod propriu, poate cere în schimb o adaptare a codului și a extensiilor, până la trecerea la o versiune majoră nouă a sistemului de magazin. Clarificați din timp cine decide intern, ce buget este disponibil și dacă trebuie implicați dezvoltatori externi.
Stabiliți, de asemenea, cum veți urmări în viitor sfârșiturile de suport. Un termen fix pe an, în care comparați lista site-urilor dumneavoastră cu indicațiile de pe php.net, împiedică reapariția aceluiași blocaj peste doi ani.
Până la comutare ar trebui să folosiți măsurile provizorii ale php.net, de exemplu session.upload_progress.enabled=0 în configurația serverului. Ele nu sunt o protecție completă, dar reduc riscul.
Cum ajută PHP SOS concret?
- Inventariem toate versiunile PHP, modurile de operare și aplicațiile de pe serverele dumneavoastră.
- Evaluăm riscul pentru fiecare site și stabilim împreună cu dumneavoastră ordinea și versiunea țintă.
- Aplicăm până la migrare măsuri provizorii și solicităm confirmări despre backporturi de la furnizor.
- Migrăm printr-un mediu de staging și documentăm testul și comutarea.
Procesul îl descrie serviciul PHP 8.1 și mai vechi: migrarea la o versiune acceptată.
Întrebări frecvente
Când se încheie suportul pentru PHP 8.2?
PHP 8.2 atinge la 31.12.2026 sfârșitul suportului din partea proiectului PHP. Remedierea PHP2Shell a primit-o ramura încă, în versiunea 8.2.35; pentru vulnerabilități ulterioare nu mai este de așteptat nicio actualizare oficială.
Primește PHP 8.1 un patch împotriva PHP2Shell?
De la proiectul PHP nu mai există actualizări oficiale pentru 8.1 și mai vechi. Există doar backporturi minime la nivel de sursă pentru 7.4, 8.0 și 8.1. Dacă și cum le aplică furnizorul dumneavoastră de hosting sau distribuția trebuie să aflați de la furnizor.
Este sigură o versiune PHP veche cu backporturi de la furnizorul de hosting?
Backporturile pot închide vulnerabilități concrete, dar nu înlocuiesc o ramură acceptată. Depind de furnizor, vin adesea mai târziu și nu acoperă orice vulnerabilitate. Ca soluție de durată sunt de aceea nepotrivite.
De unde știu dacă CMS-ul meu rulează cu o versiune PHP nouă?
Verificați cerințele de sistem pe pagina oficială a producătorului și testați într-un mediu de staging. Același lucru se aplică extensiilor și temelor, deoarece ele sunt adesea adevăratul punct îngust.