PHP2Shell: vulnerabilitatea PHP din octombrie 2026 și ce trebuie să faci cu site-ul tău

PHP2Shell este numele comun pentru două erori PHP (CVE-2026-109618 și CVE-2026-109619). Dezvoltatorii PHP au lansat remedierea pe 21 octombrie 2026. Eroarea se află în funcția PHP care urmărește încărcările (session.upload_progress) și permite rularea de cod pe server de la distanță, fără autentificare. Pentru un site WordPress, acesta e cel mai rău scenariu: cine o exploatează poate face tot ce poate face site-ul însuși.

A doua zi, pe 22 octombrie, am verificat peste 60 de site-uri pe care le întrețin sau la care am acces. Scriu mai jos ce am verificat, ce am găsit și ce poți face dacă și site-ul tău ar putea fi afectat.

Ce este PHP2Shell și pe cine afectează?

PHP este limbajul de programare pe care rulează WordPress. E instalat pe serverul găzduirii tale și îl actualizează firma de găzduire. De aceea actualizarea WordPress sau a modulelor nu repară această eroare. Trebuie actualizat PHP-ul care rulează pe server.

Versiunile oficiale remediate:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Pentru ramurile 8.1 și mai vechi, proiectul PHP nu mai lansează versiuni noi. Aceste versiuni nu mai au suport oficial de ani de zile.

De ce te poate induce în eroare numărul versiunii?

Aici apare problema. Multe găzduiri cu cPanel folosesc CloudLinux, iar CloudLinux a lansat remedierea pe 21 octombrie pentru toate ramurile PHP, păstrând numărul vechi de versiune, inclusiv pentru 8.1 și 7.4. Hostinger spune că și pe găzduirile sale administrate toate versiunile sunt protejate. Astfel, un PHP 8.1.34 poate fi remediat, iar un 8.3.35 poate fi neremediat.

Semnul sigur este data la care a fost compilat PHP-ul (build date). Dacă în rezultatul comenzii php -v apare „built: Oct 21 2026" sau o dată ulterioară, remedierea este inclusă.

În verificare am văzut ambele situații. Un site rula pe 8.3.35, ceea ce sună nou, dar build-ul era din 6 octombrie, deci neremediat. Altul rula pe 8.1.34, cu un build CloudLinux din 21 octombrie, deci protejat.

Ce am găsit pe cele peste 60 de site-uri?

• Majoritatea erau în regulă. Rulau fie versiunea oficială remediată, fie build-ul remediat al găzduirii.
• Două site-uri le-am trecut de pe 8.1 pe 8.3. Build-ul 8.1 era remediat, dar ramura nu mai are suport. Pe parcurs am aflat că selectorul PHP din CloudLinux păstrează setările (memorie, timp de execuție, dimensiune de încărcare) separat pentru fiecare versiune. După schimbare trebuie copiate, altfel site-ul pornește cu 128 MB memorie. La un magazin online, asta ar fi putut bloca și pagina de finalizare a comenzii.
• Un site l-am lăsat intenționat pe versiunea veche. Rulează un page builder și un modul de slider din 2019, care probabil dau erori pe un PHP mai nou. Acolo trebuie actualizate întâi modulele și abia apoi PHP-ul.
• Pe cinci site-uri am pus o atenuare temporară. Pe acestea găzduirea încă nu a lansat remedierea sau rulează un sistem atât de vechi încât nici nu o va face. În rădăcina site-ului am pus un fișier .user.ini care dezactivează urmărirea încărcărilor. Asta protejează doar împotriva uneia dintre cele două erori, și doar parțial.
• Câteva site-uri rulează pe găzduiri instituționale sau ieftine, cu PHP 7.4. Pentru ele nu există remediere. Am scris administratorilor și le-am explicat de ce e nevoie.
• La peste douăzeci de site-uri nu am acces la server. Acolo build-ul exact trebuie cerut de la găzduire sau de la client.

Ce să faci acum?

• Întreabă firma de găzduire. E suficient atât: „Pe ce versiune PHP rulează site-ul meu și include remedierea PHP2Shell din 21 octombrie 2026 (CVE-2026-109618, CVE-2026-109619)?"
• Dacă ești pe PHP 8.1 sau mai vechi, treci pe 8.3 sau 8.4. Înainte, verifică pe o copie dacă tema și modulele funcționează. La un magazin online testează și coșul, și finalizarea comenzii.
• Dacă găzduirea nu poate oferi remedierea, pune o atenuare temporară. În rădăcina site-ului e nevoie de un fișier .user.ini cu linia: session.upload_progress.enabled = 0. Nu înlocuiește remedierea, dar reduce suprafața de atac.
• Dacă găzduirea rulează un sistem vechi și nu poate actualiza, mută site-ul. Un server fără actualizări de securitate va fi la fel de expus și la următoarea eroare.

În panoul de administrare WordPress vezi versiunea PHP la Unelte → Sănătatea site-ului → Informații → Server. Data build-ului nu o vezi de acolo. Pentru ea ai nevoie de găzduire sau de acces SSH.

Pe scurt

PHP2Shell este o eroare a PHP-ului care rulează pe server, deci remedierea ține de găzduire. Numărul versiunii singur nu îți spune dacă ești protejat, data build-ului da. Dacă nu știi unde rulează site-ul tău și cine actualizează PHP-ul, trimite-mi adresa site-ului și mă uit.