Vulnerabilități critice în PHP (CVE-2026-109618 și CVE-2026-109619): ce s-a întâmplat și ce aveți de făcut

La 21 octombrie 2026, proiectul PHP a publicat corecții pentru două defecte critice, iar CERT-EU a publicat în aceeași zi avizul 2026-018. Ambele sunt evaluate la 9,2 și ambele sunt descrise drept execuție de cod la distanță fără autentificare. Dacă aveți un site WordPress, un magazin online sau orice altă aplicație PHP, acest lucru vă privește, iar remedierea este o actualizare, nu o setare. Articolul explică ce se știe, cum pătrunde atacul și ce aveți de făcut. Stare la 22 octombrie 2026, pe baza versiunii 1.1 a avizului CERT-EU.

Ce s-a întâmplat

PHP a anunțat o versiune de securitate la 20 octombrie și a publicat corecțiile la 21 octombrie, la ora 13:30 UTC. CERT-EU și-a intitulat avizul „Vulnerabilități critice în PHP” și enumeră două CVE: CVE-2026-109618 și CVE-2026-109619, fiecare cu scorul 9,2. CERT-EU scrie, de asemenea, că detaliile tehnice sunt acum discutate public și că a început să circule primul cod de demonstrare a conceptului. Avizul nu confirmă atacuri reale, dar precizează că acest lucru face mai probabil ca atacatorii să exploateze deja defectele. Tratați situația ca pe o urgență.

Cine este afectat

Sunt afectate toate versiunile PHP mai vechi decât cea corectată dintr-o ramură susținută, precum și fiecare ramură ajunsă la sfârșitul suportului.

CERT-EU menționează PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Potrivit echipei PHP, mod_php prezintă cel mai mare risc. Pot fi afectate și produsele care înglobează PHP; CERT-EU trimite la o listă a NCSC-ului olandez la sfârșitul acestui articol. Contează orice instalare care servește cereri web, indiferent dacă are sau nu un formular de încărcare.

Cum ajunge atacatorul la primul defect

Nimeni nu trebuie să se autentifice. Potrivit CERT-EU, un exploit demonstrat arată că o singură cerere neautentificată poate declanșa atacul înainte de a rula vreun cod al aplicației. Este punctul pe care îl scapă cei mai mulți: nu contează dacă WordPress-ul dumneavoastră este la zi, dacă pluginurile sunt corectate sau dacă formularul de contact este protejat. Cererea ajunge mai întâi la motorul PHP.

Primul defect, CVE-2026-109618, funcționează astfel:

1. O cerere ajunge la o adresă servită de PHP. Fără autentificare, fără cont.
2. PHP începe să citească corpul cererii. CERT-EU dă ca exemplu analiza încărcărilor de fișiere prin formular.
3. PHP își impune memory_limit cu ajutorul longjmp(). Când limita este depășită, părăsește brusc ce făcea și încheie cererea.
4. Dacă acest lucru se întâmplă chiar în timpul pregătirii datelor interne ale cererii, acestea rămân construite doar pe jumătate.
5. Curățarea de după aceea tratează datele nevalide drept valide și eliberează memorie care nu a fost niciodată inițializată. Această memorie poate conține încă date din alocări anterioare, controlate de atacator.
6. De aici încolo, avizul descrie execuție de cod la distanță pe server.

Nu descriem în mod deliberat cum conduce atacatorul ultimul pas. Este suficient să știți că punctul de intrare nu este aplicația dumneavoastră și că tocmai de aceea nimic din interiorul aplicației nu îl poate opri.

Al doilea defect: o stare care supraviețuiește memoriei sale

CVE-2026-109619 este un mecanism diferit, cu același rezultat. PHP păstrează o stare internă pentru fiecare cerere. După anumite eșecuri, cum ar fi o eroare fatală, această stare poate rămâne, deși memoria de sub ea a fost eliberată. Următoarea cerere tratată de același proces de lucru poate folosi apoi această stare perimată înainte ca ea să fie resetată în modul obișnuit. Atacatorul are nevoie de două cereri care ajung la același proces de lucru; CERT-EU evaluează rezultatul la fel ca la primul defect: execuție de cod la distanță.

Ce aveți de făcut astăzi

1. Aflați ce versiune de PHP servește de fapt site-ul dumneavoastră. php -v în linia de comandă arată versiunea pentru linia de comandă, care poate diferi de cea folosită de serverul web. Verificați php-fpm -v, panoul furnizorului de găzduire sau o pagină care apelează phpinfo(). La găzduirea partajată, întrebați furnizorul.
2. Actualizați la o versiune corectată: 8.5.12, 8.4.27, 8.3.36 sau 8.2.35. Distribuțiile portează adesea corecțiile fără să schimbe numărul versiunii, așa că căutați numerele CVE în avizul de securitate al furnizorului dumneavoastră. În containere, reconstruiți imaginea pornind de la o imagine de bază actualizată. Echipa PHP notează că rpms.remirepo.net nu avea actualizări în ziua lansării și recomandă pachetele distribuției sau compilarea din codul sursă.
3. Reporniți fiecare proces de lucru PHP. O actualizare de pe disc nu schimbă procesele care rulează deja. Reporniți PHP-FPM sau serverul web, apoi verificați din nou versiunea care rulează.
4. Dacă nu puteți actualiza astăzi, izolați serverul de rețelele publice până când corecția este aplicată și verificată. CERT-EU este categoric: doar o actualizare remediază complet aceste defecte.
5. Dacă folosiți PHP 8.1 sau mai vechi, cereți furnizorului portarea corecției sau treceți la o ramură susținută. Aceste versiuni nu primesc actualizări obișnuite.

Soluții provizorii care reduc riscul, dar nu remediază defectul

CERT-EU enumeră măsuri care îngreunează un atac. Precizează clar că ele nu fac o instalare sigură. Folosiți-le cât pregătiți actualizarea, nu în locul ei.

• Împotriva CVE-2026-109618: setați memory_limit=-1 într-un mod pe care aplicațiile nu îl pot suprascrie, de exemplu cu php_admin_value în pool-ul FPM, și verificați că niciun pool, director sau intrare de aplicație nu setează din nou o limită finită. Setați un post_max_size mic (8M fără încărcări, 32M cu încărcări) și păstrați upload_max_filesize sub el. Limitați dimensiunea cererii, numărul de câmpuri, părțile cererilor compuse, numărul de antete și adâncimea de imbricare la nivelul serverului web sau al proxy-ului. Folosiți o limită de memorie a containerului sau cgroup ca graniță pentru disponibilitate, dar nu RLIMIT_AS sau RLIMIT_DATA, care pot declanșa eșecul vulnerabil de alocare.
• Împotriva CVE-2026-109619: setați session.upload_progress.enabled=0 în php.ini, în pool-ul FPM sau într-o configurare a serverului care se aplică înainte de analiza cererii (nu cu ini_set() sau .user.ini) și reporniți toate procesele de lucru. Pe PHP 8.5 setați și fatal_error_backtraces=0. Eliminați setările nevalide sau depășite per cerere care afișează mesaje de diagnosticare înainte de inițializare și remediați erorile fatale și depășirile de timp de execuție pe care le poate provoca un atacator.

Ce poate și ce nu poate face SilentShield aici

Nu este o problemă de boți și preferăm să spunem acest lucru deschis, decât să lăsăm o pagină de produs să sugereze altceva. Atacul lovește motorul PHP înainte ca cererea să fie văzută de ceva de-al nostru sau de orice CAPTCHA, plugin ori regulă de firewall din interiorul aplicației dumneavoastră. O protecție împotriva boților pusă pe un formular nu îl oprește și nimeni nu trebuie să vă spună că l-ar opri. Singura remediere completă este actualizarea PHP.

API-ul și panoul de control SilentShield nu sunt scrise în PHP. Pluginul WordPress și SDK-ul PHP rulează în propriul dumneavoastră PHP, așa că pentru ele actualizarea trebuie făcută pe serverul dumneavoastră. După ce ați actualizat, protecția obișnuită împotriva boților și a spamului din formulare este la fel de utilă ca înainte; doar că nu a fost niciodată răspunsul la această problemă.

Surse

• CERT-EU Security Advisory 2026-018: Vulnerabilități critice în PHP
• Anunțul PHP din 20 octombrie 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produse care înglobează PHP