Pe scurt: Pentru PHP 8.1 și mai vechi, proiectul PHP nu mai oferă actualizări oficiale. Suportul pe termen lung, numit și suport extins, vine de la distribuții Linux, depozite ale unor furnizori terți sau servicii comerciale precum TuxCare ELS ori Zend/HeroDevs. El poate acoperi timpul până la upgrade dacă furnizorul confirmă în scris acoperirea pentru versiunea dumneavoastră. Nu înlocuiește însă nici upgrade-ul, nici întreținerea CMS-ului și a codului propriu.
De ce întrebarea apare tocmai acum
Pe 21 octombrie 2026 au apărut corecțiile PHP2Shell doar pentru ramurile acceptate 8.5, 8.4, 8.3 și 8.2. Pentru 7.4, 8.0 și 8.1, proiectul PHP a pus la dispoziție doar backporturi minime la nivel de sursă, adică corecții în codul sursă fără o lansare gata făcută. Conform presei de specialitate, sunt afectate aproape toate versiunile până la PHP 5.4.
Cât de mare este numărul îl arată o analiză CybelAngel: aproximativ 2,24 milioane de gazde PHP accesibile din internet, dintre care, conform CybelAngel, 59% pe versiuni fără o corecție oficială viitoare. Pentru multe companii, întrebarea despre suportul pe termen lung nu mai este astfel teoretică. Și devine mai mare: PHP 8.2 ajunge pe 31.12.2026 la sfârșitul suportului.
Ce are nevoie imediat un sistem vechi descrie PHP 8.1 și mai vechi: ce se aplică acum. Acest articol ajută la întrebarea pe termen mediu: ce cale rezistă până la upgrade și ce trebuie să ofere?
Suport extins PHP: căile pe scurt
| Cale | Ce oferă | Limite |
|---|---|---|
| Întreținerea pe termen lung a distribuției | Backporturi în pachete, atât timp cât versiunea distribuției este acceptată | doar pentru versiunea PHP pe care o aduce această distribuție |
| Depozit al unui furnizor terț | de ex. sury.org, conform rapoartelor cu build-uri de la 5.6 la 8.5 | nu este arhiva de securitate a distribuției, o chestiune de încredere |
| Suport comercial pe termen lung | pachete actualizate pentru versiuni expirate, de ex. TuxCare ELS, Zend/HeroDevs | faceți-vă confirmată acoperirea pentru fiecare versiune și CVE, costuri curente |
| Construire proprie din backporturi sursă | build-uri proprii din corecțiile proiectului PHP | laborios, necesar din nou la fiecare vulnerabilitate |
Despre ofertele comerciale: TuxCare descrie pe site-ul său corecții CVE pentru versiuni expirate de la PHP 5.2 la 8.x, livrate prin gestionarul de pachete existent, pentru Windows și distribuțiile Linux uzuale. O indicație de pe aceeași pagină raportează corecții PHP2Shell pentru versiuni PHP expirate. Conform documentației cPanel, TuxCare promite pentru vulnerabilitățile de la CVSS 7 în sus corecții în 14 zile de la publicare; pe serverele cPanel, pentru aceasta domeniile sunt mutate de la ea-php la alt-php. Despre Zend/HeroDevs nu aveam la dispoziție nicio declarație privind acoperirea PHP2Shell.
Indicații despre calea furnizorului terț oferă articolul Repository-ul sury.org.
Ce vă trebuie în scris de la furnizor
Suportul pe termen lung este o prestație de încredere. Cumpărați promisiunea că vulnerabilitățile viitoare vor fi închise. Faceți-vă de aceea răspunsurile confirmate în scris înainte de decizie:
- Ce versiuni PHP, sisteme de operare și nume de pachete sunt acoperite exact?
- Sunt CVE-2026-109618 și CVE-2026-109619 închise pentru versiunea dumneavoastră, cu ce nivel de pachet și de când?
- Cum se procedează cu CVE-2026-115560 și cu anunțurile ulterioare viitoare?
- Sunt incluse extensiile folosite de dumneavoastră sau doar nucleul PHP?
- Cum verificați singur că un patch a fost aplicat, de exemplu prin changelog-ul pachetului?
- Cât timp durează acoperirea pentru versiunea dumneavoastră și cum este anunțat un sfârșit?
- Ce se întâmplă cu pachetele instalate când contractul se încheie?
Răspunsurile care trimit doar în general la „toate vulnerabilitățile de securitate” nu sunt suficiente. Pentru auditori, asigurători și propria documentație contează atribuirea concretă a versiunii, pachetului și CVE.
Limitele: ce nu rezolvă suportul pe termen lung
Suportul pe termen lung menține runtime-ul PHP la zi. Tot ce se află deasupra rămâne sarcina dumneavoastră. Și tocmai acolo se află, la sistemele vechi, de obicei problema mai mare.
- Aplicația se depășește în continuare: Un CMS sau un magazin care are nevoie de PHP 8.1 nu mai este adesea nici el în versiunea actuală.
- Biblioteci și extensii: Pachetele Composer și pluginurile nu mai primesc adesea actualizări pentru versiunile PHP vechi.
- Nu înlocuiește repornirea și verificarea: Și pachetele actualizate acționează abia după repornirea tuturor proceselor PHP și nu elimină programele malițioase introduse înainte.
- Datoria tehnică crește: Cu cât puntea este mai lungă, cu atât saltul la migrarea ulterioară este mai mare.
- Dovezile devin mai laborioase: Auditorii, clienții și asigurătorii întreabă tot mai des despre nivelul de patch. O versiune PHP expirată cu patchuri de la un furnizor terț se poate dovedi, dar cere mai multe explicații decât o versiune acceptată.
Când este totuși suportul pe termen lung alegerea potrivită? Tipice sunt trei situații: o aplicație de specialitate al cărei producător nu aprobă încă versiuni PHP mai noi; un sistem vechi a cărui înlocuire este deja hotărâtă și care trebuie să mai ruleze doar câteva luni; sau o bază de cod mare a cărei trecere trebuie planificată cu grijă. În toate trei cazurile, suportul pe termen lung cumpără timp pentru o soluție ordonată. Nu este o soluție pentru sisteme de care nu vrea să se mai ocupe nimeni.
Dacă un sistem vechi a rulat neprotejat în internet între 17 și 21 octombrie, clarificați mai întâi dacă este compromis. Suportul pe termen lung pentru un sistem deja infectat nu protejează nimic.
Un plan de ieșire face parte din decizie
Suportul pe termen lung este o decizie bună atunci când se încheie cu o dată. Stabiliți până când aplicația trebuie să ruleze pe o versiune acceptată, cine răspunde de migrare și ce obiective intermediare se aplică. Cât timp sunt întreținute oficial ramurile PHP explică Ciclul de lansare al PHP.
Dacă pentru sistemul dumneavoastră merită mai degrabă un upgrade sau un backport cântărește articolul Upgrade PHP sau backport?.
Cum ajută PHP SOS concret?
- Evaluarea situației: Verificăm versiunea, sursa pachetului și nivelul de patch ale sistemelor dumneavoastră vechi și dacă prezintă urme ale unui atac.
- Verificarea ofertelor: Comparăm angajamentele scrise ale unui furnizor de suport pe termen lung cu inventarul dumneavoastră real.
- Securizarea punții: Până la upgrade aplicăm măsurile provizorii de la php.net și restrângem accesibilitatea.
- Implementarea ieșirii: Prin migrarea de la PHP 8.1 și mai vechi planificăm și testăm trecerea la o versiune acceptată.
Întrebări frecvente
Ce este suportul extins PHP?
Prin aceasta se înțeleg ofertele care continuă să furnizeze corecții de securitate versiunilor PHP după sfârșitul suportului oficial. Pot fi distribuții Linux, depozite ale unor furnizori terți sau servicii comerciale precum TuxCare ELS ori Zend/HeroDevs.
Acoperă suportul comercial pe termen lung PHP2Shell?
TuxCare indică pe site-ul său că a pus la dispoziție corecții PHP2Shell pentru versiunile PHP expirate. Pentru versiunea, pachetul și sistemul de operare concrete ale dumneavoastră ar trebui totuși să vă faceți confirmat în scris și să verificați în changelog.
Este suportul pe termen lung o alternativă la upgrade?
Doar pe timp limitat. Menține runtime-ul PHP actualizat, dar nu CMS-ul, extensiile și codul propriu, care sunt adesea și ele depășite. O dată de ieșire aparține de aceea oricărei decizii pentru suport pe termen lung.
Ce se întâmplă când contractul de suport pe termen lung se încheie?
Conform documentației cPanel despre TuxCare, pachetele instalate continuă să ruleze, dar nu mai primesc actualizări noi de securitate. Sistemul se află atunci din nou în aceeași situație ca înainte, doar mai târziu.
Se aplică subiectul și la PHP 8.2?
Da, curând. PHP 8.2 primește cu 8.2.35 încă corecția PHP2Shell, dar ajunge pe 31.12.2026 la sfârșitul suportului. Cine operează 8.2 ar trebui să planifice schimbarea acum.