Situația actuală: PHP2Shell. Două vulnerabilități critice PHP (CVSS 9.2) permit cod malițios fără autentificare. Patchuri din 21.10.2026.Ce este de făcut acum →

Upgrade PHP sau backport? Decizia pentru sistemele vechi

Pentru versiunile PHP vechi există după PHP2Shell mai multe căi: backport al distribuției, sursă terță, patch din sursă, suport pe termen lung sau upgrade. Cât valorează fiecare cale și cât durează.

Stadiu 5 min de cititAjutoare de decizie

Pe scurt: Dacă upgrade-ul PHP sau backportul este alegerea corectă depinde de cât timp trebuie să mai ruleze sistemul dumneavoastră și de cât de bine este dovedit backportul. Un backport al propriei distribuții pe un sistem de operare suportat este o cale cu drepturi depline. Backporturile din sursă, sursele terțe și suportul comercial pe termen lung pentru PHP 8.1 și mai vechi sunt punți cu dată de expirare. Pe termen lung ajută doar trecerea la o versiune PHP pe care proiectul PHP o suportă încă oficial.

De ce întrebarea este presantă după PHP2Shell

La 21.10.2026, proiectul PHP a remediat PHP2Shell în versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Pentru PHP 8.1 și mai vechi nu mai există versiuni oficiale, ci doar backporturi minime din sursă pentru 7.4, 8.0 și 8.1. Potrivit presei de specialitate, sunt afectate aproape toate versiunile până la PHP 5.4.

Astfel, mulți operatori de sisteme vechi se confruntă cu aceeași întrebare: este suficient să petecești cumva breșa sau trebuie acum făcut upgrade-ul amânat de ani? Ce înseamnă practic un upgrade descrie oferta noastră de migrare de la PHP 8.1 și mai vechi. Ce se aplică fără actualizare oficială se află la PHP 8.1 și mai vechi: ce se aplică acum. Acest articol ajută la cântărirea dintre ele.

Ce tipuri de backporturi există

„Backport” este un termen colectiv. Se înțelege întotdeauna că o corecție dintr-o versiune mai nouă este preluată într-una mai veche. Cine face acest lucru și cât de bine este verificat diferă însă puternic.

  1. Backport al distribuției: Debian, Ubuntu, Red Hat și altele preiau corecții de securitate în pachetele PHP ale versiunilor lor suportate. Numărul de versiune rămâne adesea același; potrivit rapoartelor, de exemplu Ubuntu 24.04 afișează în continuare 8.3.6 după actualizare. Corecția este dovedită prin changelog-ul pachetului și prin avertizările de securitate ale distribuției.
  2. Sursă terță: Depozitul sury.org al lui Ondřej Surý a pus la dispoziție, potrivit rapoartelor, build-uri pentru toate ramurile de la 5.6 până la 8.5. Nu este arhiva de securitate a Debian. Detalii se află la Depozitul sury.org.
  3. Backport din sursă al proiectului PHP: Pentru 7.4, 8.0 și 8.1 există patchuri minime în codul sursă, dar nu versiuni gata făcute. Cine le folosește trebuie să construiască, să testeze și în viitor să întrețină singur PHP.
  4. Suport comercial pe termen lung: Furnizori precum TuxCare ELS sau Zend/HeroDevs oferă întreținere pentru versiuni vechi. Dacă și când acoperă PHP2Shell trebuie confirmat în scris; acest lucru nu era dovedit în sursele cunoscute. Mai multe la Suport pe termen lung pentru versiunile PHP vechi.

Upgrade PHP sau backport: comparația

Criteriu Upgrade la versiune suportată Backport (în funcție de tip)
Protecție împotriva PHP2Shell Da, cu 8.2.35, 8.3.36, 8.4.27 sau 8.5.12 Da, dacă este complet și dovedit
Viitoare actualizări de securitate Oficial până la sfârșitul suportului versiunii Doar cât timp furnizorul respectiv întreține
Dovadă Numărul de versiune plus repornire Changelog-ul pachetului cu numere CVE, confirmarea furnizorului
Efort acum Mediu până la mare, sunt necesare teste de compatibilitate Redus la distribuție, mare la construcție proprie
Efort mai târziu Redus până la următorul salt de versiune Crește cu fiecare breșă nouă
Risc pentru aplicație Incompatibilități cu codul vechi și extensiile Redus, comportamentul rămâne în mare parte același
Potrivire ca soluție permanentă Da Doar backportul distribuției, în cadrul unui sistem de operare suportat

Rândul „Efort mai târziu” este cel mai important. PHP2Shell nu va fi ultima breșă. Fiecare lună pe o versiune fără suport oficial înseamnă că următoarea avertizare ridică din nou aceeași întrebare.

Ce versiune țintă la upgrade?

Potrivit php.net, pentru fiecare ramură PHP se aplică: doi ani de suport activ, apoi doi ani doar corecții de securitate. De aici rezultă aceste date de sfârșit pentru suportul de securitate:

Versiune Suport de securitate până la
PHP 8.2 31.12.2026
PHP 8.3 31.12.2027
PHP 8.4 31.12.2028
PHP 8.5 31.12.2029

Un upgrade la 8.2 este de aceea doar o scurtă stație intermediară. Cine oricum migrează ar trebui să vizeze o versiune cu orizont mai lung, dacă CMS-ul, magazinul online și extensiile o suportă. Verificați acest lucru în cerințele de sistem ale producătorului, nu din memorie. Cum funcționează ciclul de lansare explică Versiunile PHP și ciclul de lansare.

Important

Indiferent de cale: după instalare, toate procesele PHP trebuie repornite. Un backport care se află doar pe disc nu protejează cât timp workeri vechi rulează în memorie.

O ordine pragmatică pentru sistemele vechi

  1. Imediat: Aplicați măsurile provizorii conform php.net sau scoateți sistemul temporar din rețea, dacă nu este disponibilă nicio corecție dovedită.
  2. În zilele următoare: Instalați un backport dovedit, pe cât posibil din propria distribuție sau cu confirmarea scrisă a furnizorului.
  3. În paralel: Verificați compatibilitatea aplicației cu o versiune suportată și stabiliți un calendar.
  4. În lunile următoare: Upgrade la versiunea țintă, pregătit într-o copie de test, cu plan de revenire.

A vedea backportul ca punte, nu ca scop, este ideea decisivă.

Când nu aveți nevoie de un furnizor de servicii pentru asta

Dacă serverul dumneavoastră rulează pe un Debian, Ubuntu sau RHEL suportat, iar distribuția livrează backportul, este suficientă o actualizare obișnuită cu repornire și o privire în changelog. Un administrator experimentat reușește singur. Ajutorul merită la construcții proprii, surse terțe, versiuni foarte vechi sau o aplicație a cărei compatibilitate nu o mai cuprinde nimeni.

Cum ajută PHP SOS concret?

  • Verificăm ce versiuni PHP și surse de pachete rulează pe serverele dumneavoastră și dacă există o corecție dovedită.
  • Instalăm backporturi, repornim și documentăm dovada prin changelog.
  • Testăm aplicația dumneavoastră într-o copie față de versiunea țintă și numim incompatibilitățile.
  • Planificăm și însoțim upgrade-ul în cadrul migrării de la PHP 8.1 și mai vechi.

Concluzie

Backportul distribuției este o cale cu drepturi depline, toate celelalte backporturi sunt punți. Cine este blocat pe PHP 8.1 sau mai vechi ar trebui să folosească backportul pentru a câștiga timp pentru upgrade, nu pentru a-l amâna în continuare.

Întrebări frecvente

Este un backport la fel de sigur ca un upgrade?

Pentru breșa remediată concret, un backport poate fi echivalent, dacă este complet și dovedit. El remediază însă doar ceea ce a fost portat înapoi. Un upgrade la o versiune suportată aduce în plus toate viitoarele actualizări oficiale de securitate.

Cum recunosc că backportul meu acoperă PHP2Shell?

După changelog-ul pachetului: acolo ar trebui menționate numerele CVE CVE-2026-109618 și CVE-2026-109619. Sub Debian și Ubuntu arată apt-get changelog, în familia RHEL rpm -q --changelog. Numărul de versiune singur nu este o dovadă.

Cât timp mai primește PHP 8.2 actualizări de securitate?

Potrivit php.net, suportul de securitate pentru PHP 8.2 se încheie la 31.12.2026. Cine actualizează astăzi la 8.2 ar trebui deci să planifice imediat și pasul următor.

Merită suportul comercial pe termen lung pentru versiunile PHP vechi?

Poate fi o punte dacă un upgrade este imposibil pe termen scurt. Cereți confirmare în scris dacă și de când este acoperit PHP2Shell. În sursele cunoscute până acum acest lucru nu era dovedit.

Surse

Contact imediat

Fiecare oră contează. Scrieți-ne acum.

Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.

Ajutor imediat