AI a dezgropat un bug de 20 de ani din PHP. Acum rulează cod pe serverul tău. Aplică patch-ul azi.

Pe 21 octombrie, proiectul PHP a lansat simultan patru versiuni — 8.5.12, 8.4.27, 8.3.36 și 8.2.35 — pentru a remedia două vulnerabilități critice, fiecare cu scor CVSS 9,2: CVE-2026-109618 și CVE-2026-109619. Împreună, acestea sunt cunoscute sub numele de php2shell. Oricare dintre ele permite unui atacator neautentificat să execute cod pe un server care nu face altceva decât să servească PHP. Nu este implicat niciun bug de aplicație. O pagină simplă „Hello World” pe o versiune vulnerabilă este suficientă.

Ambele vulnerabilități se află în zonele PHP pe care aproape fiecare cerere le atinge: gestionarea memoriei și tratarea erorilor. CVE-2026-109618 corupe memoria în modul în care PHP face curățenie după ce rămâne fără memorie la jumătatea procesării unei cereri. CVE-2026-109619 este un use-after-free, unde starea internă dintr-o cerere persistă în cererea următoare gestionată de același worker. Wiz Research le-a descoperit cu ajutorul unor agenți AI, le-a raportat privat în august, iar fix-ul a ajuns pe 21 octombrie într-un release coordonat cu distribuțiile și vendorii. Wiz spune că sunt afectate toate versiunile PHP începând cu 5.4, adică aproximativ ultimul deceniu al limbajului. PHP rulează o mare parte din web, deci numărul serverelor expuse este enorm.

Cine este de fapt expus

Echipa PHP evaluează Apache cu mod_php ca prezentând cel mai mare risc. Acolo, o singură cerere neautentificată poate declanșa exploit-ul înainte ca oricare din codul tău să ruleze, deci niciuna dintre apărările tale — middleware de autentificare, validare a input-ului, verificări în aplicație — nu mai are șansa să intervină. Execuția completă de cod la distanță a fost demonstrată pe mod_php cu setări implicite față de containere fresh de WordPress, Drupal și Joomla.

PHP-FPM nu este nici el sigur. RCE prin bug-ul de stare depășită a fost validat pe FPM, deși acea cale necesită o operațiune potrivită în aplicația care rulează pentru a fi exploatată. php-cgi, FrankenPHP și LiteSpeed sunt toate în scope. Dacă servește PHP prin HTTP, tratează-l ca vulnerabil până când l-ai patch-uit și repornit.

Un punct pentru echipele de mobil, deoarece expunerea este ușor de trecut cu vederea: în proiectele noastre native de iOS și Android, aplicația în sine este curată, dar comunică cu un API, iar acel API este foarte des în PHP. Un backend neactualizat îți pune utilizatorii în pericol chiar dacă nimic de pe dispozitiv nu este greșit. Verifică serverul din spatele aplicației, nu doar aplicația.

Ce am face mai întâi

Din experiența noastră cu PHP și lucrul cu Docker, greșeala pe care o vedem sub presiune este să patch-uiești lucrul greșit. Doi pași contează mai mult decât restul.

1. Găsește fiecare PHP pe care îl rulezi, nu doar cel evident. Se ascunde în stivele cPanel și Plesk, în dispozitivele vendorilor, pe site-uri vechi ale clienților pe care nimeni nu le-a atins de doi ani, în imaginile CI și containerele de bază. Ghidurile CISA recomandă să faci mai întâi un inventar, deoarece PHP este adesea îngropat în alte programe și nu poți patch-ui ceea ce nu ai găsit.
2. Aplică patch-ul, repornește, apoi verifică versiunea raportată de procesul care rulează. Un pachet nou pe disc nu face nimic până când nu înlocuiești workerii care rulează. Am văzut echipe care au „aplicat patch-ul” și au rămas exploatabile zile întregi pentru că PHP-FPM nu a fost niciodată repornit efectiv.

Containerele înrăutățesc această capcană. Rularea unui upgrade în interiorul unui container activ nu este un fix, deoarece următorul deploy din imaginea veche readuce direct build-ul vulnerabil. Reconstruiește pe o imagine de bază patch-uită, împinge-o și rotește workerii. Apoi accesează serverul și confirmă că versiunea pe care o aștepți este cea care răspunde.

Dacă nu poți aplica patch-ul azi

Echipa PHP este directă: doar actualizarea este un fix complet, iar setările temporare nu fac decât să reducă anumiți vectori de atac. Cele care merită aplicate sunt memory_limit=-1 impus acolo unde aplicația nu îl poate suprascrie, folosind php_admin_value în pool-ul FPM sau configurația Apache, apoi session.upload_progress.enabled=0 și un post_max_size conservator. Dacă folosești Cloudflare, regula WAF gestionată pentru aceste CVE-uri este deja activă, iar câștigarea de timp cu o regulă edge în timp ce workerii sunt patch-uiți este exact tipul de lucru pe care îl configurăm pentru clienți în timpul unui incident. O rezervă: acea regulă se bazează pe numele implicit al câmpului upload-progress, deci dacă ai redenumit session.upload_progress.name, nu te va acoperi.

Ceea ce ar trebui să te îngrijoreze mai mult decât acest bug

Iată ce mă îngrijorează cu adevărat la php2shell. Aceste bug-uri s-au aflat în codul sursă timp de aproximativ douăzeci de ani. Nimeni nu le-a weaponizat pentru că transformarea unui lanț de corupere a memoriei într-un exploit fiabil pentru fiecare versiune PHP, set de extensii și layout de heap era o muncă lentă, specializată, genul care durează luni. Wiz a folosit modele AI de frontieră pentru a face acea adaptare, și a durat câteva săptămâni în schimb.

În timpul angajamentelor noastre de pentesting pentru studiouri de gaming, partea dificilă era rareori identificarea unui cod path suspect. Era dovedirea unui exploit real, repetabil, înainte ca cineva să plătească pentru a-l remedia. Acea economie s-a schimbat. Atacatorii beneficiază de aceeași accelerare, ceea ce înseamnă că distanța dintre publicarea unui patch și scanarea în masă continuă să se reducă. Cloudflare a raportat tentative de sondare în jurul momentului lansării, iar un proof of concept circulă deja.

Deci concluzia sinceră este incomodă: cadența de patch-uri este acum postura ta de securitate. Dacă nu poți găsi și actualiza un runtime critic pe toată infrastructura ta într-o zi, aceea este vulnerabilitatea reală, iar php2shell nu va fi ultimul lucru care o va testa.

Dacă menținerea PHP patch-uit, repornit și verificat pe staging, producție și o grămadă de site-uri mai vechi ale clienților sună familiar, hai să vorbim.