Echipa PHP publică patchuri de urgență pentru două vulnerabilități critice de execuție de cod la distanță - Serverele trebuie actualizate la 8.3.36/8.4.27/8.5.12 (sau echivalent backport) pentru a elimina riscul fără autentificare

Două vulnerabilități critice din PHP pot permite preluarea serverelor fără autentificare , iar remedierea nu ține de „ai PHP 8.3 în panou”, ci de versiunea exactă instalată și folosită efectiv de site, potrivit Mobilissimo . Actualizările de urgență au fost publicate de echipa PHP după ce mai multe site-uri guvernamentale europene au fost oprite preventiv, conform Reuters. Servicii publice din Franța, Olanda, Finlanda și Danemarca au fost afectate, iar unele instituții au ales să își scoată temporar paginile de pe internet până la instalarea corecțiilor. Miza operațională este directă: breșele permit rularea de cod de la distanță fără cont, parolă sau acces anterior la server. Versiunile PHP care trebuie instalate pentru remediere Nu este suficient să apară în interfață „PHP 8.2/8.3/8.4/8.5”. Contează „ultima cifră” a versiunii, iar prima versiune remediată diferă pe fiecare ramură: Ramura PHP Versiuni vulnerabile Prima versiune remediată PHP 8.5 sub 8.5.12 8.5.12 PHP 8.4 sub 8.4.27 8.4.27 PHP 8.3 sub 8.3.36 8.3.36 PHP 8.2 sub 8.2.35 8.2.35 PHP 8.1 sau mai vechi ramuri ieșite din suport upgrade sau corecție confirmată de furnizor Echipa PHP a publicat detaliile actualizărilor aici: php.net . Pentru ramurile vechi (PHP 8.1, 8.0, 7.4) sunt menționate corecții minimale, în special pentru cei care compilează PHP din sursă, însă recomandarea rămâne migrarea către o ramură suportată. Un detaliu important pentru companii: unele distribuții Linux și servicii cu suport pe termen lung (LTS) pot livra corecții prin „backport” (integrarea patch-ului fără schimbarea versiunii afișate ca număr). În acest caz, furnizorul trebuie să confirme explicit că a remediat CVE-2026-109618 și CVE-2026-109619 . De ce riscul este greu de „acoperit” din aplicație Cele două vulnerabilități au scor 9,2 din 10 și pot ajunge la executarea de comenzi pe server. Prima exploatează felul în care PHP gestionează lipsa memoriei în timpul procesării unei cereri (inclusiv scenarii cu upload), iar a doua poate expune date interne vechi către o cerere ulterioară. Sunt expuse instalările care servesc pagini web prin: PHP-FPM Apache cu mod_php php-cgi FrankenPHP LiteSpeed Configurațiile mod_php sunt descrise ca fiind cele mai riscante. PHP avertizează că atacul demonstrat poate fi declanșat înainte ca aplicația să înceapă să ruleze, ceea ce înseamnă că un plugin de securitate WordPress sau un firewall la nivel de aplicație poate să nu apuce să intervină. Ce ar trebui să verifice firmele cu site-uri WordPress Actualizarea WordPress, a temei și a pluginurilor nu repară PHP, pentru că PHP rulează la nivelul serverului. Pe WordPress, versiunea activă poate fi verificată din: Unelte → Sănătate site → Informații → Server → Versiune PHP Documentația WordPress despre ecranul „Sănătate site” este aici: wordpress.org . Publicația atrage atenția că nu trebuie folosită doar versiunea selectată în panoul de hosting: serverul poate avea mai multe versiuni PHP instalate, iar site-ul să ruleze pe un pool PHP-FPM mai vechi. Pentru găzduire shared sau managed, pașii recomandați sunt: verificarea versiunii utilizate efectiv de site, nu doar a celei „disponibile” în panou; confirmarea de la furnizor că patch-urile pentru cele două CVE-uri au fost instalate; verificarea dacă este necesară selectarea manuală a noii versiuni; backup complet înainte de schimbare; testarea formularelor, uploadurilor, comenzilor și panoului de administrare după actualizare. Dacă nu poți actualiza imediat: izolarea, nu „măsuri cosmetice” PHP indică faptul că nu există o metodă completă de protecție în afara update-ului. Limitarea uploadurilor, dezactivarea session.upload_progress și filtrarea cererilor mari pot reduce anumite căi de atac, dar nu securizează serverul și pot afecta funcționarea site-ului. Dacă actualizarea nu poate fi făcută imediat, CERT-EU recomandă izolarea aplicației de internet sau oprirea temporară; recomandarea este publicată în acest buletin: CERT-EU . După instalarea patch-ului, ar trebui verificate logurile, fișierele modificate recent, conturile administrative nou-create și procesele necunoscute; dacă există semne de compromitere, simplul update nu elimină codul malițios deja instalat. AI-ul scurtează fereastra dintre patch și atac Breșele au fost raportate după o cercetare realizată de Calif împreună cu OpenAI, folosind GPT-5.6 Sol, iar Wiz a identificat independent vulnerabilitățile cu sistemul Atlas și alte modele AI. Odată publicate patch-urile, aceeași automatizare poate accelera compararea codului și construirea rapidă a unui exploit, reducând timpul în care organizațiile mai pot reacționa înainte să apară atacuri la scară. În practică, întrebarea utilă pentru furnizorul de hosting nu este „am PHP 8.3?”, ci dacă site-ul rulează PHP 8.3.36 (sau pachetul echivalent cu patch) și dacă sunt remediate explicit CVE-2026-109618 și CVE-2026-109619 . Dacă furnizorul nu poate confirma, serverul trebuie tratat ca vulnerabil. [...]