21 octombrie 2026 | PHP | Securitate IT
Pe 21 octombrie 2026, echipa de securitate PHP a publicat actualizări pentru toate versiunile PHP încă acceptate. Acestea închid două vulnerabilități critice, devenite cunoscute sub numele PHP2Shell. BSI a emis un avertisment în acest sens și cere ca sistemele afectate să fie actualizate fără întârziere. Cine operează un server web cu PHP ar trebui să acționeze chiar astăzi. Acest lucru este valabil și pentru toți cei care operează „doar” un WordPress, Nextcloud sau Joomla, deoarece aceste aplicații rulează pe PHP.
Acest articol rezumă ce s-a întâmplat, ce versiuni PHP sunt afectate, de ce versiune aveți acum nevoie și cum verificați în câteva minute dacă serverul dumneavoastră este securizat.
Cuprinsul acestui articol
- Ce s-a întâmplat? Desfășurarea în timp
- Cele două vulnerabilități PHP pe scurt
- Cine este afectat?
- Aceste versiuni PHP sunt sigure
- Cum verificați și actualizați serverul dumneavoastră
- PHP 8.1 și mai vechi: nicio actualizare oficială
- Măsuri provizorii și întrebarea „Scoatem serverul offline?”
- Întrebări frecvente
- Asistență din partea Biricon IT Services
Ce s-a întâmplat? Desfășurarea în timp
Echipa de securitate PHP a anunțat în prealabil publicarea corecțiilor, pentru ca furnizorii de hosting și administratorii să aibă timp să se pregătească. Publicarea în sine a avut loc pe 21 octombrie 2026. BSI și-a emis avertismentul (versiunea 1.1) în aceeași zi.
- 20 octombrie 2026: Avertizare prealabilă din partea echipei de securitate PHP că a doua zi vor apărea actualizări de securitate.
- 21 octombrie 2026, 14:00 UTC (ora 16:00 CEST): Sunt publicate patch-urile pentru PHP 8.5, 8.4, 8.3 și 8.2.
- 21 octombrie 2026: BSI avertizează cu privire la „vulnerabilitățile critice care amenință aplicațiile web din întreaga lume” și recomandă aplicarea fără întârziere a patch-urilor. Potrivit BSI, mari furnizori de hosting au scos în parte serverele offline, ca măsură de precauție.
Cele două vulnerabilități PHP pe scurt
Este vorba de două erori separate în nucleul PHP: CVE-2026-109618 și CVE-2026-109619. Potrivit echipei de securitate PHP, ambele pot duce la faptul că un atacator poate executa cod de program pe server fără a se autentifica (unauthenticated Remote Code Execution). Vulnerabilitățile sunt evaluate cu CVSS v4.0: 9,2 (critic).
| Caracteristică | Semnificație |
|---|---|
| Identificatori | CVE-2026-109618 și CVE-2026-109619 |
| Evaluare | CVSS v4.0: 9,2 — critic |
| Impact | Executarea de cod pe server (Remote Code Execution), fără autentificare |
| Cauza 1 | Memorie coruptă atunci când PHP nu mai primește memorie de lucru în timpul procesării (Out-of-Memory) |
| Cauza 2 | Stare globală depășită, rămasă în memorie între cereri |
| Deosebit de expus | Apache cu mod_php |
Potrivit evaluării BSI, la momentul publicării nu existau atacuri confirmate, dar existau indicii neconfirmate de încercări de exploatare. În cazul unor vulnerabilități critice într-un software atât de răspândit, experiența arată că trebuie să ne așteptăm ca atacatorii să analizeze corecțiile și să pregătească atacuri automatizate. Fereastra de timp pentru aplicarea patch-urilor este de aceea scurtă.
Cine este afectat?
Este afectat, în principiu, orice server pe care rulează PHP, indiferent de modul în care este conectat PHP: PHP-FPM, mod_php în Apache, php-cgi, FrankenPHP sau LiteSpeed. Riscul este cel mai mare, potrivit echipei de securitate PHP, la Apache cu mod_php.
BSI menționează explicit aplicații care se bazează pe PHP și pot fi de aceea afectate la rândul lor:
- Sisteme de gestionare a conținutului: WordPress, Drupal, TYPO3, Joomla
- Sisteme de magazin: Magento
- Stocare în cloud și de fișiere: Nextcloud
- Interfețe de firewall: pfSense, OPNsense
Aplicația însăși nu trebuie să fie defectă pentru aceasta. Vulnerabilitatea se află în PHP, de aceea o actualizare doar a WordPress, Nextcloud & Co. nu ajută. Trebuie actualizată versiunea PHP de pe server. La firewall-uri precum pfSense și OPNsense, versiunea PHP corectată vine prin actualizarea de firmware respectivă a producătorului.
Aceste versiuni PHP sunt sigure
Vulnerabilitățile sunt remediate în versiunile următoare. Tot ce este sub acestea este considerat vulnerabil.
| Ramura PHP | Cerută cel puțin | Observație |
|---|---|---|
| PHP 8.5 | 8.5.12 | ramura actuală |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Suportul se încheie la 31 decembrie 2026 |
| PHP 8.1 și mai vechi | nicio actualizare oficială, vezi jos | |
Cum verificați și actualizați serverul dumneavoastră
1. Stabiliți versiunea PHP instalată
În linia de comandă a serverului, php -v arată versiunea PHP pentru linia de comandă. Serverul web poate folosi o altă versiune PHP. Verificați de aceea și versiunea PHP-FPM, respectiv a modulului Apache, de exemplu cu php-fpm8.3 -v sau printr-o pagină care afișează phpinfo() (aceasta trebuie ștearsă imediat după aceea).
2. Aplicați actualizarea prin managerul de pachete
La Debian, Ubuntu, RHEL și derivate, versiunea corectată vine prin managerul de pachete obișnuit, de exemplu apt update && apt upgrade sau dnf upgrade. La surse terțe precum Sury PPA sau depozitul Remi, noile pachete apar de obicei în scurt timp.
apt changelog php8.3-fpm sau rpm -q --changelog php | grep CVE-2026-1096).
3. Reporniți serviciul PHP
O actualizare de pachet singură nu este suficientă: procesele PHP în execuție păstrează codul vechi în memorie. Reporniți PHP-FPM (systemctl restart php8.3-fpm) respectiv Apache (systemctl restart apache2) și verificați apoi dacă procesele au fost pornite după actualizare.
4. Site-uri găzduite
La shared hosting, actualizarea o face de regulă furnizorul. În meniul clientului se poate seta de obicei versiunea PHP pentru fiecare site. Alegeți acolo una dintre versiunile sigure menționate mai sus sau întrebați furnizorul despre stadiul patch-urilor. Potrivit BSI, unii furnizori au scos serverele din rețea ca măsură de precauție. Dacă site-ul dumneavoastră este scurt timp inaccesibil, aceasta poate fi cauza.
PHP 8.1 și mai vechi: nicio actualizare oficială
Pentru PHP 8.1 și mai vechi nu mai există actualizări oficiale de securitate. Operatorii unor astfel de sisteme au două posibilități:
- Treceți la o versiune acceptată (recomandat). Cu cât versiunea este mai veche, cu atât efortul de adaptare pentru aplicație și extensii este mai mare, de aceea trecerea ar trebui testată în prealabil.
- Portați înapoi corecțiile. Echipa de securitate PHP a pus corecțiile la dispoziție în ramuri de dezvoltare pe GitHub. Cine compilează PHP singur poate prelua aceste modificări în versiuni mai vechi. Aceasta este o soluție provizorie și necesită cunoștințe de specialitate.
Și PHP 8.2 este acceptat doar până la 31 decembrie 2026. Planificați de aceea acum trecerea la PHP 8.4 sau 8.5 și nu o amânați până la schimbarea anului.
Măsuri provizorii și întrebarea „Scoatem serverul offline?”
Echipa de securitate PHP a descris, odată cu anunțul, și măsuri provizorii de protecție. Acestea reduc riscul, dar nu închid complet vulnerabilitățile. Ele nu înlocuiesc actualizarea și sunt destinate doar să acopere timpul până la actualizare.
Dacă un server ar trebui scos din rețea până la actualizare depinde de importanța și de accesibilitatea lui. BSI arată că furnizorii mari au făcut acest pas. Ca regulă de bază:
- Server accesibil public, actualizare posibilă acum: aplicați imediat patch-ul, nu este necesară oprirea.
- Server accesibil public, actualizare imposibilă pe termen scurt: restricționați accesul (de exemplu prin firewall, doar pentru adrese cunoscute) sau opriți temporar serviciul, mai ales la
mod_php. - Server accesibil doar intern: aplicați patch-ul în scurt timp, urgența este mai mică.
Întrebări frecvente
Trebuie să actualizez WordPress, Joomla sau Nextcloud?
Nu din cauza acestei vulnerabilități. Ea se află în PHP, nu în aplicație. Actualizați versiunea PHP de pe server. O actualizare a aplicației este totuși utilă, independent de aceasta.
Cum îmi dau seama dacă cineva a exploatat deja vulnerabilitatea?
Este greu de dat un răspuns sigur. Sunt suspecte fișierele PHP necunoscute din directorul web, procesele neobișnuite rulate sub utilizatorul serverului web, conturile de utilizator sau cronjob-urile noi și traficul de ieșire neobișnuit. În cazul unei suspiciuni concrete, sistemul ar trebui verificat criminalistic și, la nevoie, reinstalat.
Este suficient un Web Application Firewall?
Un firewall poate bloca modelele de atac cunoscute, dar nu înlocuiește actualizarea. Mai multe despre interacțiunea mai multor straturi de protecție puteți citi în articolul nostru Securizarea Odoo 19: firewall, 2FA & Web RBL. Principiile se aplică oricărei aplicații web.
Este afectat Odoo?
Nu. Odoo este scris în Python și nu rulează pe PHP. Ar fi afectate doar aplicațiile PHP care rulează pe același server.
Unde găsesc informațiile oficiale?
Anunțul echipei de securitate PHP îl găsiți în arhivele de știri de pe php.net (intrarea din 20 octombrie 2026), iar versiunile la php.net/downloads. Avertizarea BSI poartă numărul 2026-297981-1032 și este publicată pe bsi.bund.de .
Asistență din partea Biricon IT Services
Dacă nu sunteți sigur ce versiune PHP rulează pe serverul dumneavoastră sau aveți nevoie de ajutor la aplicarea patch-urilor, vă sprijinim cu plăcere: la inventarierea tuturor sistemelor PHP, la instalarea actualizărilor, la trecerea la o versiune PHP suportată și la verificarea unei eventuale compromiteri. Ca furnizor de servicii IT administrăm servere, firewall-uri și aplicații web pentru întreprinderi mici și mijlocii.
Situație la: 21 octombrie 2026. Situația se poate schimba rapid; sunt determinante publicațiile echipei de securitate PHP și ale BSI.