Pe scurt: O actualizare PHP pe Plesk este încheiată abia când fiecare versiune PHP instalată se află pe o stare corectată, toate serviciile PHP-FPM au fost repornite și puteți dovedi acest lucru prin starea pachetelor și prin ora de pornire a proceselor. Numărul de versiune afișat în panou nu este suficient, pentru că backporturile îl lasă adesea neschimbat.
Despre ce este vorba la PHP2Shell pe serverele Plesk
PHP2Shell desemnează două vulnerabilități critice în PHP însuși (CVE-2026-109618 și CVE-2026-109619, fiecare CVSS v4.0 9.2). Ele permit atacatorilor să execute cod pe server fără autentificare. Sunt afectate, printre altele, PHP-FPM și Apache cu mod_php, adică exact modurile de operare pe care Plesk le configurează pentru site-uri.
Pe 21.10.2026, proiectul PHP a publicat versiunile corectate 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Pentru PHP 8.1 și mai vechi nu mai există actualizări oficiale. Serverele Plesk au o particularitate: aici rulează adesea mai multe versiuni PHP una lângă alta, unele de la Plesk însuși, altele de la sistemul de operare. Fiecare are nevoie de propria verificare.
O actualizare din panou înlocuiește fișiere pe disc. Cât timp procese PHP vechi rulează în memorie, vulnerabilitatea rămâne deschisă. Fără repornirea tuturor workerilor, patchul nu este eficient.
Actualizare PHP Plesk: mai întâi inventarul
Înainte de a actualiza ceva, faceți o listă a tuturor handlerilor PHP și a domeniilor care îi folosesc. Puteți face acest lucru din panou (Tools & Settings, PHP Settings) sau din linia de comandă. Comenzile următoare nu modifică nimic, doar citesc.
# Toți handlerii PHP înregistrați, cu versiune și cale
plesk bin php_handler --list
# Versiunea fiecărei versiuni PHP instalate de Plesk (calea ca exemplu)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
Notați pentru fiecare handler: versiunea, modul de operare (FPM, FastCGI, modul Apache) și numărul de domenii. Handlerii fără domenii nu sunt o dezlegare. Ei pot fi atribuiți mai târziu sau pot rula pe subdomenii de test.
Verificați starea pachetelor, nu afișajul
Plesk afișează numărul de versiune pe care îl raportează PHP însuși. Dacă Plesk sau distribuția livrează corecția ca backport, acolo poate rămâne, de exemplu, 8.2.34, deși corecția este inclusă. Invers, un număr care pare actual poate înșela dacă un pachet nu a fost încă actualizat. Hotărâtoare sunt starea pachetelor instalate și confirmarea scrisă a furnizorului.
# Debian/Ubuntu (numele pachetelor ca exemplu)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'
# AlmaLinux/Rocky/RHEL (numele pachetelor ca exemplu)
rpm -qa | grep -E 'plesk-php|^php' | sort
Comparați versiunile pachetelor cu informațiile din jurnalele de modificări Plesk și cu indicațiile distribuției dumneavoastră. Dacă nu este documentat clar acolo că CVE-2026-109618 și CVE-2026-109619 sunt remediate, întrebați furnizorul. Un model în acest sens găsiți la Cum întrebați hosterul despre starea patchului.
Instalați actualizarea și reporniți toți workerii
Actualizarea propriu-zisă se face prin instalatorul Plesk sau prin gestionarul de pachete al sistemului. Urmează apoi pasul care lipsește cel mai des: repornirea. Sub Plesk, fiecare versiune PHP are propriul serviciu FPM. Reporniți-le pe toate, nu doar pe cel al domeniului principal.
# Listați toate serviciile PHP-FPM (numele serviciilor ca exemplu)
systemctl list-units --type=service | grep -i 'php.*fpm'
# Reporniți fiecare serviciu, de ex.:
systemctl restart plesk-php84-fpm
# Verificați ora de pornire a proceselor PHP în execuție
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
Dacă un domeniu rulează cu Apache și mod_php, reporniți complet Apache. Dacă ora de pornire a unui proces PHP este anterioară actualizării, el nu a fost încă reînnoit. Mai multe despre acest pas găsiți la Repornirea PHP-FPM și a tuturor workerilor.
Protecție provizorie, dacă actualizarea încă lipsește
Dacă pentru o versiune nu există încă un patch, php.net recomandă măsuri provizorii. Ele nu reprezintă o protecție completă. Sub Plesk, setați valorile pe care aplicațiile nu au voie să le suprascrie ca php_admin_value în directivele FPM suplimentare ale domeniului sau la nivel de server în php.ini al versiunii respective.
; Exemplu de directive PHP-FPM suplimentare în Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
Pentru încărcări de fișiere, potrivit php.net, este prevăzut post_max_size = 32M, cu upload_max_filesize sub această valoare. Pe PHP 8.5 se adaugă fatal_error_backtraces=0. Eliminarea limitei de memorie prin memory_limit=-1 trebuie folosită doar împreună cu o limită la nivel de container sau cgroup. Urmează din nou o repornire a tuturor workerilor. Detalii găsiți la Măsuri imediate fără patch. BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă scoaterea temporară din rețea a serverelor web dacă actualizarea nu este posibilă imediat.
După patch: salvați jurnalele și căutați urme
Un patch închide vulnerabilitatea pentru viitor. El nu elimină programele malițioase introduse anterior și nu dovedește că nu s-a întâmplat nimic. De aceea, păstrați jurnalele serverului web începând cu 20.10.2026. Plesk le salvează pentru fiecare domeniu în directorul logs; nu scurtați perioada de păstrare în această situație.
Fiți atenți la fișiere PHP noi sau modificate în directoarele de încărcare, la sarcini programate necunoscute și la conturi noi de administrator. Până acum nu există indicatori de compromitere (IoC) publicați și confirmați; detectarea se bazează pe analiza comportamentului. Dacă găsiți nereguli, nu continuați pe cont propriu, ci salvați mai întâi starea sistemului.
Cum ajută PHP SOS concret?
- Inventariem toți handlerii PHP ai serverului dumneavoastră Plesk, atribuim domeniile și verificăm starea reală a pachetelor pentru fiecare versiune.
- În cadrul serviciului nostru de patch PHP instalăm actualizările, repornim toate serviciile și documentăm orele de pornire ale proceselor ca dovadă.
- Acolo unde lipsește un patch, aplicăm măsurile provizorii conform php.net la nivel de server și astfel încât să nu poată fi suprascrise.
- Salvăm jurnalele și căutăm urme de compromitere, iar în caz de constatări continuăm cu răspunsul la incidente.
- Apoi securizăm serverul pe termen lung și eliminăm versiunile PHP de care nu este nevoie.
Întrebări frecvente
De ce arată Plesk încă PHP 8.2.34 după actualizare?
Distribuțiile și furnizorii livrează uneori corecțiile de securitate ca backport, fără să schimbe numărul versiunii. Contează atunci starea pachetului și confirmarea furnizorului. Afișajul singur nu dovedește nici existența, nici lipsa unui patch.
Este suficient să apăs pe Actualizare în panoul Plesk?
Actualizarea scrie fișiere noi, dar procesele PHP în execuție continuă să lucreze în memorie cu codul vechi. Starea nouă este activă abia după repornirea tuturor serviciilor PHP-FPM și a serverului web. Verificați apoi ora de pornire a proceselor.
Trebuie să actualizez și versiunile PHP pe care nu le folosește niciun domeniu?
Da, dacă rămân instalate. Un handler nefolosit poate fi atribuit din greșeală mai târziu sau poate fi accesibil prin medii de test. Versiunile de care nu aveți nevoie este mai bine să le dezinstalați complet.
Ajută o actualizare WordPress din Plesk Toolkit împotriva PHP2Shell?
Nu. PHP2Shell privește PHP însuși, nu CMS-ul. O actualizare a CMS-ului rămâne utilă, dar nu închide această vulnerabilitate.