Pe scurt: Pentru vulnerabilitatea PHP2Shell din PHP 8.1 nu există nicio actualizare oficială. Proiectul PHP livrează pentru 7.4, 8.0 și 8.1 doar backporturi minime în codul sursă, nu versiuni gata făcute. Cine operează aceste versiuni are nevoie de un backport confirmat de furnizorul său sau de măsuri provizorii și ar trebui să planifice acum trecerea la o versiune susținută.
Există o actualizare împotriva vulnerabilității PHP 8.1?
Nu din partea proiectului PHP. La 21 octombrie 2026 au apărut corecții oficiale doar pentru ramurile susținute: 8.5.12, 8.4.27, 8.3.36 și 8.2.35. PHP 8.1 și versiunile mai vechi nu mai primesc actualizări oficiale.
Sunt afectate totuși. Potrivit presei de specialitate, versiunile vulnerabile merg aproape fără întrerupere până înapoi la PHP 5.4. Cine operează o astfel de versiune accesibilă public are, așadar, o vulnerabilitate critică, cu CVSS v4.0 9.2, fără patch gata făcut.
Pentru multe companii este o surpriză, deoarece asemenea sisteme rulează adesea stabil și neobservat de ani de zile. Faptul că o versiune nu mai primește actualizări nu se observă în viața de zi cu zi, până când apare o vulnerabilitate precum PHP2Shell. Backporturile din codul sursă pentru 7.4, 8.0 și 8.1 sunt o excepție și nu o reluare a întreținerii obișnuite.
Ce înseamnă backporturile din codul sursă
Pentru 7.4, 8.0 și 8.1 există backporturi minime în codul sursă. Acestea sunt corecții în codul sursă, transferate pe aceste ramuri mai vechi. Nu sunt o versiune oficială cu număr de versiune, pachet testat și changelog.
Practic înseamnă: cineva trebuie să preia backportul, să reconstruiască PHP din el, să testeze și să distribuie. Acest lucru se poate întâmpla pe trei căi:
- Distribuția dumneavoastră preia corecția în pachetele sale, de exemplu în cadrul unei întrețineri pe termen lung.
- Furnizorul dumneavoastră de hosting construiește pachete PHP proprii și aplică backportul.
- Dumneavoastră înșivă sau un prestator de servicii construiți PHP din surse. Este solicitant și trebuie repetat la fiecare vulnerabilitate ulterioară.
Dacă sistemul dumneavoastră a primit un backport verificați în changelogul pachetului:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # familia RHEL
Numele pachetelor diferă în funcție de distribuție și de sursa de pachete. Dacă lipsește o intrare, întrebați furnizorul. Cum funcționează verificarea în detaliu găsiți la Cum verificați corect versiunea PHP și starea patchului.
Protejarea vechiului server până la migrare
Cât timp nu rulează niciun backport confirmat, se aplică măsurile provizorii de la php.net: memory_limit=-1 care nu poate fi suprascris, cu limită de memorie prin cgroup, post_max_size de 8M sau 32M cu upload_max_filesize sub aceasta și session.upload_progress.enabled=0 în configurația serverului, apoi reporniți toți workerii. Ele nu sunt o protecție completă. Detalii la Măsuri imediate dacă nu puteți încă aplica patchul.
La acestea se adaugă măsuri care reduc accesibilitatea: zone de administrare doar prin VPN sau adrese IP aprobate, oprirea site-urilor nenecesare, limitarea strictă a accesurilor la server. BSI recomandă scoaterea temporară din rețea a serverelor fără actualizare. Pentru o aplicație veche, greu de migrat, o soluție izolată poate fi răspunsul mai onest decât o funcționare în internetul deschis.
Dacă un server cu PHP 8.1 sau mai vechi a rulat fără protecție în rețea din 17 octombrie, luați asta în serios: BSI se aștepta la o exploatare rapidă, la scară largă. Salvați logurile începând cu 20 octombrie și puneți-l la verificare pentru urme înainte de a migra.
Planificarea migrării: la ce versiune?
Ținta este o versiune pe care o susține proiectul PHP și pe care o acceptă aplicația dumneavoastră. PHP 8.2 închide vulnerabilitatea de la 8.2.35, dar ajunge la 31.12.2026 la sfârșitul suportului. Cine migrează acum ar trebui, de aceea, să meargă pe cât posibil la 8.3 sau mai nou, dacă aplicația permite. Starea actuală o indică php.net pe pagina versiunilor susținute.
Ce versiune PHP suportă CMS-ul sau magazinul dumneavoastră verificați conform cerințelor de sistem ale producătorului, de exemplu pe wordpress.org, shopware.com sau typo3.org. Adesea trebuie actualizată mai întâi aplicația însăși, înainte ca PHP să poată fi schimbat. Un caz tipic sunt magazinele mai vechi, pe care le descriem pe pagina Shopware 5. Contextul consecințelor versiunilor învechite îl găsiți la PHP End of Life: riscurile versiunilor învechite.
| Pas | Conținut |
|---|---|
| Inventar | versiune PHP, aplicație, extensii, adaptări proprii |
| Cerințe | versiuni PHP susținute conform producătorului |
| Mediu de test | copie cu noua versiune PHP, analiza jurnalului de erori |
| Trecerea | fereastră de mentenanță planificată, cale de întoarcere pregătită |
| Finalizare | verificarea valorilor provizorii, configurarea supravegherii |
Cum ajută PHP SOS concret?
Prin migrarea de la PHP 8.1 și versiuni mai vechi vă ducem de la versiunea veche la una susținută:
- Protejare imediată: verificarea stării backportului, setarea măsurilor provizorii, reducerea accesibilității.
- Verificarea urmelor: salvarea logurilor începând cu 20 octombrie și analizarea lor pentru anomalii.
- Pregătirea migrării: clarificarea compatibilității conform producătorului, construirea mediului de test, remedierea erorilor.
- Trecere și dovadă: aplicarea noii versiuni PHP, repornirea tuturor proceselor, documentarea stării.
Î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, inclusiv PHP 8.1. Proiectul PHP nu mai publică pentru 8.1 actualizări oficiale, ci doar backporturi minime în codul sursă.
Ce este un backport în codul sursă?
O corecție în codul sursă, transferată pe o ramură de versiune mai veche. Nu este o versiune gata făcută: cineva trebuie să o preia, să reconstruiască PHP, să testeze și să distribuie. Poate face acest lucru furnizorul distribuției dumneavoastră, furnizorul de hosting sau un prestator de servicii.
Este suficient să trec la PHP 8.2?
Pe termen scurt, PHP 8.2.35 închide vulnerabilitatea. PHP 8.2 ajunge însă la 31.12.2026 la sfârșitul suportului. Cine oricum migrează ar trebui, de aceea, să verifice dacă aplicația acceptă, potrivit producătorului, și 8.3 sau mai nou.
Magazinul meu rulează doar cu PHP 7.4. Ce fac?
Atunci sunt necesare două lucruri în paralel: protejarea serverului prin măsuri provizorii și izolare și aducerea aplicației la o versiune care suportă o versiune PHP susținută. Care este aceasta se află în cerințele de sistem ale producătorului.