PHP a lansat patch-urile: actualizați acum la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35

Azi-dimineață vă scriam că echipa PHP pregătea, pentru după-amiaza zilei de 21 octombrie, actualizări de urgență pentru două vulnerabilități critice (articolul inițial). Corecturile au apărut, iar detaliile confirmă că situația e serioasă: ambele vulnerabilități pot permite executarea de cod de la distanță fără autentificare, adică un atacator poate rula comenzi pe server fără să aibă vreun cont pe site. Recomandarea oficială este una singură: actualizați imediat.

#Ce versiuni trebuie instalate

Pe 21 octombrie 2026, la ora programată (14:00 UTC, adică 17:00 ora României), echipa PHP a publicat patru versiuni noi:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Dacă serverul rulează orice versiune din ramurile 8.2, 8.3, 8.4 sau 8.5 mai veche decât acestea, este vulnerabil. Echipa PHP precizează că distribuțiile Linux și furnizorii de suport pe termen lung (LTS) au primit corecturile în avans, așa că pachetele actualizate ar trebui să apară rapid și în depozitele lor.

PHP 8.1 și versiunile mai vechi nu mai primesc actualizări de la proiectul PHP. Din cauza gravității problemei, echipa PHP a publicat totuși corecturi minimale în cod sursă pentru PHP 7.4, 8.0 și 8.1, utile celor care își compilează singuri PHP. Pentru serverele obișnuite, soluția rămâne un furnizor care oferă patch-uri pentru versiuni vechi sau, mai sigur, trecerea la o versiune cu suport. Atenție și la PHP 8.2: primește această corectură, dar iese din suport pe 31 decembrie 2026.

#Ce înseamnă cele două vulnerabilități

Ambele au primit scorul 9,2 din 10 (CVSS v4.0):

• CVE-2026-109618, cod executat după o eroare de memorie. Când PHP rămâne fără memorie în timpul unei cereri, prelucrarea se poate opri cu datele interne doar pe jumătate pregătite. La curățarea de după cerere, aceste date incomplete sunt tratate ca valide, iar asta poate fi exploatată.
• CVE-2026-109619, date rămase de la o cerere anterioară. Anumite informații interne ale unei cereri pot rămâne în memorie după ce zona respectivă a fost eliberată. Următoarea cerere preluată de același proces PHP le poate folosi înainte să fie resetate.

Sunt afectate toate instalările PHP care servesc pagini web: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Echipa PHP consideră că riscul cel mai mare îl are mod_php, pentru care există deja un exploit demonstrat: o cerere fără autentificare poate declanșa atacul înainte ca aplicația (WordPress, magazinul online etc.) să ruleze vreo linie de cod. Așadar, un site bine întreținut, cu toate pluginurile la zi, nu este protejat dacă PHP-ul de dedesubt nu e actualizat.

#Dacă nu poți actualiza chiar acum

Echipa PHP spune clar că nu există măsuri care să înlocuiască actualizarea. Măsurile de mai jos doar reduc expunerea la anumite variante de atac și sunt utile pentru câteva ore, până la actualizare. Se aplică din configurația serverului (php.ini, pool-ul FPM sau configurația Apache), nu din aplicație:

1. Dezactivează urmărirea progresului la upload: session.upload_progress.enabled=0, apoi repornește toate procesele PHP. Nu te baza pe ini_set() sau pe fișierele .user.ini, fiindcă se aplică prea târziu.
2. Pe PHP 8.5, setează fatal_error_backtraces=0 și repornește procesele.
3. Limitează dimensiunea cererilor: post_max_size = 8M pentru site-urile fără upload de fișiere, respectiv 32M dacă e nevoie de upload, cu upload_max_filesize sub această valoare. Ajută și limitele puse la nivel de server web sau proxy.
4. Elimină setările invalide sau învechite care generează avertismente la fiecare cerere. Ascunderea erorilor (display_errors, @) nu rezolvă nimic.

Echipa PHP mai propune memory_limit=-1, dar doar împreună cu o limită de memorie la nivel de container sau cgroup. Fără ea, un singur proces poate consuma toată memoria serverului, așa că nu aplica această setare fără un administrator care să înțeleagă efectele.

#Pașii concreți pentru firme

1. Verifică versiunea de PHP a site-ului. În cPanel: Software → MultiPHP Manager (sau Select PHP Version). Dacă site-ul e administrat de o agenție sau de un programator, cere-le o confirmare scrisă că PHP-ul a fost actualizat la una dintre versiunile de mai sus.
2. Actualizează din pachetele oficiale. Pe serverele cu cPanel, versiunile noi vin prin pachetele EasyApache (ea-php). Pe Debian/Ubuntu (apt) și pe RHEL/AlmaLinux/Rocky (dnf), instalează actualizările de securitate ale distribuției imediat ce apar. După actualizare, repornește PHP-FPM sau Apache, altfel procesele vechi rulează în continuare codul vulnerabil.
3. Nu uita serverele „ascunse”: aplicații interne, intranet, CRM-uri, panouri de administrare, imagini Docker cu PHP. Orice instalare PHP care răspunde la cereri web intră în calcul, chiar dacă nu e accesibilă de pe internet.
4. Pentru site-urile pe PHP 8.1 sau mai vechi, planifică acum migrarea. Până atunci, asigură-te că furnizorul de găzduire aplică patch-uri pentru versiunea veche.
5. Urmărește logurile în zilele următoare. Acum, când detaliile sunt publice, scanările automate apar repede. Fișierele .php noi în directoarele de upload, conturile de administrator necunoscute sau traficul neobișnuit sunt semne care trebuie verificate.

#Concluzia noastră

De data asta, avertismentul primit cu o zi înainte s-a confirmat pe deplin: vorbim de execuție de cod fără autentificare, într-o componentă folosită de majoritatea site-urilor. Actualizarea durează de obicei câteva minute, iar o compromitere poate însemna zile de recuperare și date ale clienților expuse. Dacă nu știi sigur cine se ocupă de PHP-ul de pe serverele firmei, echipa Activ.NET te poate ajuta cu verificarea și actualizarea, prin serviciul de administrare servere.

Surse: PHP.net, anunțul de securitate din 21 octombrie 2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp