Remedierea pentru PHP2Shell a fost lansată, însă, pentru majoritatea site-urilor care au nevoie de ea, nu există niciun buton pe care să apeși. Vulnerabilitățile se află chiar în PHP, motorul care rulează fiecare pagină WordPress, Joomla și Drupal, mai jos în infrastructură decât CMS-ul, pluginurile sale și pagina de autentificare. Actualizarea WordPress nu schimbă nimic. Interpretorul corectat trebuie să vină de la cel care administrează serverul: compania de găzduire, pachetul distribuției Linux sau imaginea containerului. Până când se întâmplă asta, site-ul rămâne în așteptare, indiferent ce face proprietarul.

Acesta este aspectul pe care titlurile de tipul „instalați acum actualizarea” îl trec cu vederea. Echipa PHP și-a făcut treaba. Instalarea remedierii pe un anumit server depinde de un lanț de distribuție care se mișcă în ritmul celei mai lente verigi, iar prima zi a arătat cât de mult diferă viteza acestora. Un proprietar care nu știe de unde provine versiunea de PHP folosită de site nu poate afla cât de expus este în continuare.

De ce actualizarea WordPress nu rezolvă problema

Pentru că erorile se află în interpretor, avertizarea PHP vizează toate instalările care procesează solicitări web, de la PHP-FPM și mod_php pentru Apache la php-cgi, FrankenPHP și LiteSpeed. The Hacker News notează că până și o pagină simplă cu mesajul „Hello World”, găzduită pe o versiune vulnerabilă, poate fi atacată. Cel mai grav scenariu implică mod_php, unde o singură solicitare de la o persoană fără cont poate declanșa atacul înainte să ruleze vreun cod al aplicației, astfel că niciun plugin de securitate și nicio pagină de autentificare nu îl detectează.

Wordfence, furnizor de soluții de securitate pentru WordPress, le-a transmis proprietarilor de site-uri, potrivit relatării The Verge, că remedierea nu poate fi instalată prin actualizări automate și că trebuie să afle cine răspunde de versiunea lor de PHP. Laravel Forge le-a spus același lucru propriilor clienți în legătură cu serverele sale: actualizările automate de securitate nu corectează PHP, iar actualizările nesupravegheate din Ubuntu preiau pachete doar din depozitul Ubuntu, nu și din sursele terțe de unde Forge instalează PHP.

Sursele acestor pachete nu au fost actualizate în același timp. În ziua lansării, serviciul de administrare a site-urilor mySites.guru a anunțat că EasyApache 4 de la cPanel avea versiuni remediate la câteva minute după publicarea avertizărilor, în timp ce PPA-ul lui Ondřej Surý, sursa de pachete Ubuntu de care se folosește chiar Laravel Forge, și depozitul Remi nu aveau încă versiuni corectate. InMotion Hosting a spus că serverele sale partajate și cele pentru WordPress așteptau versiunile CloudLinux. Dintre site-urile active monitorizate de mySites.guru, 0,08% raportau o versiune PHP corectată până la 13:52 UTC.

Numărul versiunii poate induce în eroare

Verificarea nu este la fel de simplă ca citirea unui număr. Ubuntu, Debian și Red Hat integrează remedierile de securitate în versiunile mai vechi fără să schimbe numărul versiunii originale, așa că un server Ubuntu 24.04 cu actualizările instalate raportează tot pachetul 8.3.6. The Hacker News, citând Debian, recomandă să cauți CVE-ul în jurnalul de modificări al pachetului, în loc să te bazezi pe numărul versiunii. mySites.guru atrage atenția asupra unei a doua capcane: binarul PHP care răspunde la comanda php -v în linia de comandă nu este adesea cel care servește paginile, așa că trebuie verificată versiunea raportată chiar de site.

Apoi, remedierea trebuie să fie încărcată în memorie. Atât avertizarea PHP, cât și Forge subliniază că trebuie repornite Apache, PHP-FPM și toate procesele care rulează continuu. Procesele din cozi și alte servicii de fundal continuă să folosească vechiul interpretor până când sunt repornite, chiar dacă fișierele de pe disc au fost actualizate.

Cine nu primește o remediere oficială

Versiunile corectate sunt PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35 și remediază CVE-2026-109618 și CVE-2026-109619, ambele evaluate cu 9,2 pe scara CVSS v4.0. Pentru PHP 8.1 și versiunile mai vechi, proiectul PHP nu oferă nimic în afară de remedieri minime integrate în codul sursă pentru versiunile 7.4, 8.0 și 8.1, destinate celor care compilează singuri PHP. Unii furnizori acoperă această lacună: InMotion spune că cPanel a integrat remedieri în pachetele sale pentru versiunile 7.4–8.1, iar CloudLinux corectează toate versiunile pe care le distribuie, în timp ce CentOS 7 nu va primi nicio remediere.

Numărul celor afectați nu este mic. În ziua dinaintea lansării, 22,7% dintre site-urile Joomla și WordPress active monitorizate de mySites.guru foloseau PHP 8.1 sau o versiune mai veche, iar 16,6% încă rulau PHP 7 sau o versiune anterioară. Compania atribuie o parte a problemei chiar WordPress, care recomandă PHP 8.3, dar încă listează versiunea 7.4, retrasă de mult, ca fiind compatibilă. PHP 8.2 a primit această remediere, însă suportul său de securitate se încheie la 31 decembrie 2026.

Ce blochează setarea temporară

Soluția provizorie care a circulat înainte de lansare, setarea session.upload_progress.enabled=0, este reală, dar rezolvă doar o parte a problemei. PHP spune că aceasta blochează căile confirmate prin sesiune care duc la CVE-2026-109619, nu și alte variante, și trebuie configurată în php.ini sau în setările serverului ori ale grupului de procese, după care trebuie repornite toate procesele. În PHP 8.5, setarea fatal_error_backtraces=0 închide încă o cale confirmată. Niciuna dintre acestea nu afectează CVE-2026-109618, pentru care PHP recomandă o setare memory_limit=-1 care nu poate fi suprascrisă, o valoare mică pentru post_max_size și limite pentru dimensiunea solicitărilor, configurate la nivelul serverului web sau al proxy-ului. PHP spune explicit că nu există măsuri de atenuare complete. InMotion precizează că WordPress, Joomla, Drupal, Magento și PrestaShop nu folosesc urmărirea progresului încărcărilor, așa că dezactivarea acesteia nu le afectează funcționarea.

Cloudflare a activat reguli de firewall pentru toate abonamentele, pe care directorul său tehnologic, Dane Knecht, le-a numit o soluție temporară. După cum observă mySites.guru, acestea ajută doar dacă serverul din spatele lor refuză traficul care ocolește Cloudflare și ajunge direct la adresa sa IP.

Atacurile de până acum

watchTowr spune că honeypoturile sale au înregistrat tentative de exploatare a ambelor vulnerabilități în ziua lansării, iar Cloudflare a observat atacatori care și-au modificat payloadurile pentru a ocoli regulile sale. Nicio sursă nu a confirmat compromiterea cu succes a unui anumit server. Unii operatori au preferat să nu riște: The Hacker News relatează că BambooHR și-a scos serviciul offline și că serviciile publice olandeze, inclusiv DigiD, au fost oprite preventiv. CERT-ul UE și Centrul Național pentru Securitate Cibernetică din Regatul Unit au recomandat organizațiilor care nu pot instala remedierea să izoleze aplicațiile expuse sau să le scoată offline.

Vulnerabilitățile au fost descoperite de Wiz Research, Calif și echipa Codex Security de la OpenAI. Potrivit PHP Foundation, primele indicii ale vulnerabilității de memorie au apărut în timpul unui audit din 2024, însă remedierea a rămas blocată luni întregi, o întârziere pe care fundația a numit-o „un eșec structural”. Cercetătorii spun că modelele de inteligență artificială au ajutat la transformarea unor erori vechi de zece ani în exploituri funcționale în aproximativ o săptămână.

Pentru a livra această remediere, PHP a avut nevoie de un audit, luni de blocaj și o scurgere de informații. Pentru un site găzduit pe un server partajat, ultimul pas este să trimită o solicitare către serviciul de asistență.

Etichete: știri, Cloudflare, PHP, PHP2Shell, vulnerabilități, WordPress