PHP avertizează din nou după două breșe critice. Ce trebuie verificat pe servere

Un site WordPress poate afișa toate pluginurile actualizate și să funcționeze fără erori, deși serverul care îl găzduiește rămâne vulnerabil. În această săptămână, problema vine din PHP, limbajul care execută o parte importantă a aplicațiilor web. Două breșe critice au primit remedieri pe 21 octombrie. Vineri, 23 octombrie, dezvoltatorii PHP au publicat încă o informare despre o configurație rară prin care ar putea fi executat cod de la distanță.

Vulnerabilitățile principale, CVE-2026-109618 și CVE-2026-109619, au fost evaluate la 9,2 din 10 în sistemul CVSS 4.0. Atacul nu presupune neapărat un cont valid pe site. Pentru administratorii din România, prima verificare trebuie făcută la versiunea PHP care rulează efectiv pe server, nu doar la actualizările din panoul WordPress.

Proiectul PHP a cerut instalarea imediată a versiunilor corectate. Separat, autoritățile europene au recomandat identificarea aplicațiilor expuse public și colaborarea cu firmele de găzduire. Problema practică este că un site poate fi întreținut de o agenție web, în timp ce motorul PHP este actualizat de un alt furnizor. Între cei doi, responsabilitatea verificării riscă să rămână neclară.

Ce au corectat versiunile lansate pe 21 octombrie

Conform avertismentului tehnic CERT-EU, CVE-2026-109618 afectează gestionarea memoriei când o cerere este întreruptă pentru depășirea unei limite. Unele structuri interne pot rămâne neinițializate corespunzător, iar procesul de curățare a memoriei le poate trata ca valide. În anumite condiții, un atacator poate transforma comportamentul eronat în executare de cod.

CVE-2026-109619 privește datele păstrate între cererile web. O parte din starea internă a unei cereri poate supraviețui după eliberarea memoriei și poate fi folosită de o cerere ulterioară, înainte ca procesul să o inițializeze corect. Cele două probleme au cauze tehnice diferite, dar pot avea aceeași consecință pentru serverele vulnerabile.

Echipa PHP a publicat patru versiuni corectate: PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 și PHP 8.5.12. Sunt afectate versiunile anterioare în ramurile respective. PHP 8.1 și ramurile mai vechi nu mai primesc actualizări obișnuite direct de la proiect, însă unii furnizori de distribuții Linux oferă remedieri adaptate propriilor pachete. Prin urmare, numărul versiunii afișate nu spune întotdeauna dacă o corecție a fost aplicată printr-un pachet de suport extins.

Nu există o singură configurație de server pentru care ar conta aceste probleme. Avertismentul acoperă PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Autorii informării consideră mod_php deosebit de expus, după demonstrarea unui scenariu în care o singură cerere neautentificată poate declanșa exploatarea înainte ca aplicația să își execute propriul cod.

Un server care afișează o versiune vulnerabilă nu trebuie declarat automat compromis. Vulnerabilitatea și compromiterea sunt lucruri diferite. Există însă suficientă informație publică despre cele două breșe pentru ca administratorii să trateze instalarea remedierilor drept o operațiune urgentă, nu un upgrade opțional de mentenanță.

Ce s-a schimbat vineri, 23 octombrie

Anunțul PHP din 23 octombrie privește funcția session.upload_progress, folosită pentru urmărirea progresului încărcării fișierelor. Noua problemă va primi identificatorul CVE-2026-115560 într-un buletin complet, odată cu următoarea versiune obișnuită a PHP.

Condițiile sunt restrictive. Aplicația trebuie să configureze inițial gestionarea sesiunilor prin php_binary sau php_serialize, apoi să schimbe la execuție formatul în php înainte de a porni sesiunea. În plus, urmărirea încărcărilor trebuie să fie activă. Proiectul PHP consideră această combinație neobișnuită.

Recomandarea preventivă este setarea session.upload_progress.enabled=0 până la următoarea actualizare. Măsura figura deja printre recomandările pentru una dintre breșele din 21 octombrie. Administratorii care au aplicat-o atunci o pot păstra fără alte schimbări pentru acest caz particular.

Este important ca acest nou avertisment să nu fie confundat cu un anunț că actualizările din 21 octombrie au eșuat. Ele repară două vulnerabilități identificate separat. Informarea de vineri descrie o combinație specială de configurare și explică de ce o măsură temporară rămâne recomandată până la distribuirea altei remedieri.

În unele aplicații, dezactivarea funcției poate afecta afișarea progresului încărcărilor. De aceea modificarea trebuie făcută în configurația potrivită și testată. Pentru serviciile administrate de terți, solicitarea către furnizor trebuie să includă atât versiunea PHP instalată, cât și confirmarea că această setare a fost evaluată.

WordPress poate fi la zi, dar PHP să nu fie

Un site web are mai multe straturi. WordPress gestionează conținutul și extensiile, în timp ce PHP execută aplicația pe server. Actualizarea unui plugin nu schimbă codul motorului PHP și nici pachetul instalat în sistemul de operare.

Pe 21 octombrie, echipa oficială WordPress a precizat că nu este planificată o actualizare WordPress pentru remedierea acestor două vulnerabilități, deoarece nu sunt defecte ale WordPress. Recomandarea adresată proprietarilor de site-uri este verificarea serviciului de găzduire și actualizarea PHP cât mai repede.

În panoul WordPress, versiunea utilizată poate fi consultată la Tools, apoi Site Health, Info și Server. Dar o instalație care utilizează pachete Linux cu remedieri preluate în versiuni mai vechi poate necesita confirmare suplimentară din partea furnizorului. Același lucru este valabil pentru o aplicație găzduită pe mai multe servere, unde fiecare nod trebuie verificat.

În România, diferența de responsabilitate este ușor de trecut cu vederea. O agenție poate administra tema și pluginurile unui magazin online, iar firma de hosting gestionează sistemul de operare și serviciile PHP. Un raport de mentenanță trimis de prima nu confirmă automat că a doua a instalat versiunea corectată.

Organizațiile care au multe domenii sau subdomenii trebuie să inventarieze separat aplicațiile. Un portal vechi, un formular de programări sau o interfață administrativă accesibilă din internet poate utiliza o versiune PHP diferită de site-ul principal. În acest caz, verificarea unei singure pagini din panoul de administrare oferă o imagine incompletă.

Un alt caz apare la serviciile comerciale care includ PHP în fundal. Instituțiile europene au avertizat că există produse ce depind de PHP fără ca administratorul să îl vadă drept componentă separată. Pentru acestea trebuie consultate și anunțurile producătorului, nu doar interfața aplicației.

De ce agențiile europene au cerut acțiune imediată

Pe 21 octombrie, Comisia Europeană, ENISA, CERT-EU, Europol și rețeaua echipelor naționale de răspuns la incidente au publicat o declarație comună. Instituțiile recomandă identificarea aplicațiilor PHP, coordonarea cu furnizorii și instalarea rapidă a corecțiilor, cu prioritate pentru serviciile accesibile direct din internet.

CERT-EU a explicat că există măsuri temporare pentru anumite căi de exploatare, inclusiv limitarea unor tipuri de cereri și dezactivarea funcției de progres a încărcărilor. Totuși, buletinul avertizează explicit că numai actualizarea rezolvă complet cele două vulnerabilități critice. Unele ajustări pot reduce riscul unui scenariu fără să elimine toate variantele.

Dacă actualizarea nu poate fi aplicată imediat, organizațiile trebuie să ia în calcul izolarea aplicației expuse din internet până când remedierea a fost instalată și verificată. Decizia poate provoca întreruperi de serviciu, dar riscul trebuie evaluat în raport cu datele și funcțiile pe care le poate accesa serverul.

Reacția nu se încheie atunci când pachetul apare ca instalat. Procesele PHP sau serviciile web trebuie repornite, acolo unde actualizarea și configurația o cer, pentru ca instanțele active să folosească într-adevăr codul corectat. Într-un mediu cu mai multe servere, unele noduri pot rămâne pe o versiune veche dacă distribuirea nu este verificată pe fiecare dintre ele.

Același control trebuie aplicat jurnalelor de securitate. Instalarea unei corecții împiedică folosirea ulterioară a defectului cunoscut, dar nu îndepărtează automat modificări pe care un atacator le-ar fi putut efectua anterior. Asta nu dovedește că un incident a avut loc. Înseamnă doar că verificarea actualizărilor și verificarea posibilelor accesări neautorizate sunt două activități separate.

Ce confirmare ar trebui cerută furnizorului din România

O organizație nu are nevoie de un raport lung care să repete formularea avertismentului internațional. Are nevoie de un inventar și de câteva confirmări verificabile. Pentru fiecare site sau aplicație importantă trebuie identificată versiunea PHP care servește cererile, nu numai cea disponibilă pentru comenzi administrative.

Următorul pas este verificarea remedierii. Dacă serverul rulează pachete oficiale PHP, se compară versiunea cu cele publicate pe 21 octombrie. Dacă rulează pachete întreținute de distribuitor, furnizorul trebuie să confirme explicit că respectivele corecții au fost incluse. Pentru o versiune PHP încheiată oficial, se stabilește dacă există suport extins real sau dacă este necesară migrarea.

Trebuie verificat apoi dacă serviciile au fost repornite și dacă toate mediile folosesc același nivel de protecție. Pentru noul scenariu din 23 octombrie, administratorul trebuie să știe dacă aplicația schimbă dinamic modul de serializare a sesiunilor și dacă funcția session.upload_progress este activă.

Un furnizor poate comunica exact ce a instalat și când, dacă au rămas servicii neactualizate și ce măsuri compensatorii le protejează temporar. Afirmația că „site-ul este actualizat” nu oferă aceste informații. Nici afișarea normală a paginilor și nici absența unei alarme vizibile nu confirmă protecția serverului.

Pentru proprietarii de magazine online și platforme care prelucrează date personale, această diferență are consecințe directe. Dacă PHP este vulnerabil, atacul poate avea loc sub nivelul aplicației. Controlul pluginurilor, o parolă puternică sau autentificarea cu doi factori rămân utile, dar nu înlocuiesc corecția motorului care primește cererea web.

Următorul reper este versiunea PHP care va rezolva CVE-2026-115560. Până la apariția ei, verificarea configurației de sesiune trebuie păstrată în planul de mentenanță. Pentru vulnerabilitățile deja remediate pe 21 octombrie, testul relevant poate fi făcut acum: fiecare serviciu expus trebuie să aibă un pachet corectat, o repornire confirmată și o evidență a sistemelor care mai necesită intervenție.

Foto principală: tehnicieni lângă servere la centrul C3SL, Brazilia, fotografie de arhivă din 2022. Alexsandro Teixeira Ribeiro / Wikimedia Commons, CC BY-SA 4.0. Imagine ilustrativă a administrării infrastructurii, nu fotografie a unui incident PHP sau a unor servere din România.