Pe 21 octombrie 2026, echipa PHP a lansat o actualizare de securitate de urgență. Rezolvă două vulnerabilități care, puse împreună, au primit numele PHP2Shell — iar amândouă permit unui atacator să execute cod pe server fără să se autentifice.
Dacă site-ul tău rulează pe PHP, și majoritatea site-urilor din România rulează, articolul ăsta îți spune ce s-a întâmplat, cum afli dacă te privește și ce faci concret.
Ce s-a întâmplat, pe scurt
Două vulnerabilități separate, dar înrudite, descoperite în inima PHP-ului — în gestionarea memoriei și în tratarea erorilor, adică exact părțile prin care trece fiecare cerere:
- CVE-2026-109618 — execuție de cod prin coruperea memoriei la epuizarea ei (out-of-memory)
- CVE-2026-109619 — execuție de cod prin stare globală rămasă de la o cerere anterioară
Ambele au scor CVSS 9.2, din maximum 10. Reparația a venit în versiunile PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35.
De ce e gravă: o singură cerere, înainte de codul tău
Aici e diferența față de o vulnerabilitate obișnuită de plugin sau de temă.
La prima dintre ele, pe o configurație Apache cu mod_php, o cerere neautentificată poate declanșa problema înainte ca aplicația ta să ruleze ceva. Nu contează că ai WordPress bine întreținut, plugin-uri actualizate și parole bune — codul tău nici nu apucă să pornească. Echipa PHP consideră mod_php configurația cu riscul cel mai mare.
Execuția de cod a fost confirmată și pe PHP-FPM, prin căi care trec prin codul aplicației. Practic, orice instalare care servește cereri web e expusă: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed.
Cele două probleme, în cuvinte simple
Coruperea la epuizarea memoriei. PHP impune limita memory_limit întrerupând brutal cererea care o depășește. Dacă întreruperea pică în mijlocul unei operații — de exemplu în timp ce se analizează un fișier încărcat printr-un formular — rămân în urmă date interne pe jumătate construite. Curățenia de la finalul cererii le tratează apoi ca valide și eliberează memorie care n-a fost niciodată inițializată. Memoria aceea poate conține date puse acolo mai devreme de atacator.
Starea rămasă între cereri. O eroare fatală într-un moment prost poate lăsa stare internă care arată spre memorie deja eliberată. O cerere următoare, servită de același worker, o folosește înainte ca inițializarea normală s-o reseteze. De aici un use-after-free, confirmat, și execuție de cod demonstrată împotriva unei aplicații reale.
Cum afli ce versiune de PHP ai
Dacă ai acces SSH:
php -v
Dacă ai doar cPanel sau un panou de la găzduire, versiunea e de obicei la Select PHP Version sau PHP Manager. Dacă n-o găsești, întreabă-ți furnizorul direct: „ce versiune de PHP rulează contul meu și când aplicați patch-ul pentru CVE-2026-109618?"
Ești în regulă doar dacă ai 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 — sau mai nou. Orice altceva pe aceste ramuri e vulnerabil.
Dacă ești pe PHP 8.1 sau mai vechi
Aici e partea care privește multe site-uri din România, pentru că ramurile vechi sunt încă foarte răspândite pe găzduirile partajate.
PHP 8.1 și mai vechi sunt scoase din suport și nu primesc actualizări de la proiect. Dar, din cauza gravității, echipa de securitate PHP a publicat backport-uri minimale de sursă pentru 7.4, 8.0 și 8.1, pentru cine compilează singur sau n-are un furnizor care să livreze patch-uri. Multe distribuții Linux și furnizori cu suport pe termen lung livrează, la rândul lor, versiuni corectate.
Concret: dacă ești pe 7.4 sau 8.0, nu ești automat pierdut — dar depinzi complet de furnizorul tău. Întreabă-l. Iar dacă răspunsul e „nu facem nimic", ai primit și motivul pentru care merită să treci pe o versiune cu suport. Am scris separat despre ce înseamnă găzduirea partajată față de un VPS, fiindcă exact aici se vede diferența: pe partajat, patch-ul îl aplică altcineva, când vrea el.
Dacă nu poți actualiza chiar azi
CERT-EU e explicit: numai actualizarea rezolvă complet problema. Măsurile de mai jos reduc expunerea pe căile confirmate, dar nu fac instalarea sigură:
- pentru prima vulnerabilitate,
memory_limit=-1impus astfel încât aplicația să nu-l poată suprascrie, plus unpost_max_sizemic —8Macolo unde nu se încarcă fișiere; - pentru a doua,
session.upload_progress.enabled=0și repornirea tuturor worker-ilor; pe PHP 8.5, șifatal_error_backtraces=0.
Dacă nici atât nu se poate, recomandarea oficială e să izolezi aplicația de internet până aplici și verifici fix-ul. E dur, dar e preferabil unui server compromis.
Ce s-a mai întâmplat în jurul lansării
Divulgarea coordonată a mers bine până cu două zile înainte de termen. Pe 20 octombrie, cele două numere CVE au început să circule pe forumuri și rețele sociale — cu o oră greșită de lansare și cu un scor greșit, 10.0 în loc de 9.2. Fără detalii tehnice, dar suficient cât echipa PHP să-și devanseze anunțul și să mute lansarea cu o zi mai devreme.
Între timp, Amazon a raportat că rețeaua lor de capcane a înregistrat o tentativă de exploatare pe 17 octombrie — cu patru zile înainte de divulgarea publică. Cloudflare a raportat trafic de atac, inclusiv încercări de a-i ocoli protecțiile.
Traducere pentru un proprietar de site: nu e o problemă teoretică și nu mai e o cursă pe care o poți amâna.
Ce facem noi pentru site-urile pe care le întreținem
Pentru clienții cu abonament de mentenanță, actualizările de securitate de felul ăsta intră în pachet: verificăm versiunea, aplicăm patch-ul sau îl cerem furnizorului de găzduire, și confirmăm că site-ul merge după. Nu e ceva ce trebuie să ne ceri — e motivul pentru care există abonamentul.
Dacă site-ul tău nu e la nimeni în întreținere și nu știi de unde să începi, scrie-ne și verificăm împreună ce versiune ai și ce e de făcut. Dacă ajungi la concluzia că site-ul actual e prea vechi ca să mai merite întreținut, vorbim despre un site nou — dar mai întâi rezolvă patch-ul, că e urgent și e ieftin.
Restul a ce facem e aici.
