Pe scurt: O actualizare PHP cPanel după PHP2Shell cuprinde trei pași: aduceți toate pachetele ea-php și, dacă este cazul, alt-php la o stare corectată, reporniți complet PHP-FPM și Apache și documentați starea pachetelor. Clienții de pe server nu pot seta singuri cele mai importante valori provizorii; trebuie să o facă administratorul WHM.
Situația de pornire pe serverele cPanel
PHP2Shell cuprinde vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 din PHP însuși. Ambele permit executarea de cod malițios fără autentificare și sunt evaluate cu CVSS v4.0 9.2. Sunt afectate PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Proiectul PHP a publicat pe 21.10.2026 versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35.
cPanel nu livrează PHP ca un singur pachet, ci prin EasyApache 4, cu câte un set de pachete pentru fiecare versiune, de exemplu ea-php83 sau ea-php84. La acestea se adaugă, pe unele servere, pachetele sistemului de operare și, pe CloudLinux, versiunile alt-php. Fiecare sursă are propria stare. Imaginea completă apare abia când le verificați pe toate trei.
Actualizare PHP cPanel: verificați inventarul și atribuirea
Începeți cu un inventar. Comenzile următoare doar citesc și nu modifică nimic. Căile și numele pachetelor sunt exemple și pot diferi în funcție de instalare.
# Versiunile PHP instalate, conform API-ului WHM
whmapi1 php_get_installed_versions
# Versiunea fiecărei instalări ea-php
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
# Starea pachetelor (sisteme bazate pe RPM, exemplu)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
În MultiPHP Manager vedeți ce domeniu folosește ce versiune și dacă PHP-FPM este activat. Notați versiunile care sunt instalate, dar nu sunt atribuite niciunui domeniu. Și ele trebuie actualizate sau eliminate.
Încadrarea corectă a backporturilor
Ca la alți furnizori, se aplică următoarea regulă: numărul de versiune afișat nu este singurul criteriu. Dacă o corecție este livrată ca backport, numărul poate rămâne neschimbat. Verificați de aceea suplimentar jurnalul de modificări al pachetului și indicațiile furnizorului.
# Căutați numerele CVE în jurnalul de modificări al unui pachet (exemplu)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
Dacă nu găsiți nicio intrare, asta nu înseamnă automat că lipsește corecția. Înseamnă însă că aveți nevoie de o confirmare scrisă înainte de a considera serverul actualizat. Cum citiți corect versiunile descrie articolul Verificarea versiunii PHP și a stării patchului.
Actualizare, repornire și control
Actualizarea o instalați în WHM prin actualizarea sistemului sau prin gestionarul de pachete. Apoi reporniți toate procesele PHP. Fișierele noi singure nu sunt suficiente cât timp procese vechi rulează în memorie.
# Reporniți serviciile PHP-FPM ale tuturor versiunilor (script cPanel)
/scripts/restartsrv_apache_php_fpm
# Reporniți complet Apache
/scripts/restartsrv_httpd
# Verificați ora de pornire a proceselor PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
Fiecare proces PHP ar trebui să aibă o oră de pornire ulterioară actualizării. Dacă nu este așa, opriți-l țintit prin serviciul căruia îi aparține. Dacă aveți mai multe servere, merită un scurt protocol pentru fiecare mașină, pe care îl puteți folosi ulterior ca dovadă.
O actualizare a CMS-ului prin instrumente cPanel precum WP Toolkit nu închide vulnerabilitatea PHP. Este utilă, dar nu înlocuiește nici actualizarea PHP, nici repornirea.
Setați central valorile provizorii
Dacă o versiune nu este încă remediată, php.net recomandă măsuri provizorii care nu oferă o protecție completă. Pe cPanel le setați în MultiPHP INI Editor, în modul pentru administratori, sau direct în php.ini al versiunii ea-php respective. Valorile din .user.ini ale conturilor clienților nu sunt suficiente pentru session.upload_progress.enabled.
; php.ini la nivel de server al versiunii afectate (exemplu)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
Fără funcție de încărcare, php.net indică post_max_size = 8M. Pe PHP 8.5 se adaugă fatal_error_backtraces=0. Apoi reporniți din nou toți workerii. O limită de memorie o setați prin cgroups, de exemplu cu limitele CloudLinux, nu prin RLIMIT_AS sau RLIMIT_DATA. Alte detalii găsiți la Măsuri imediate fără patch.
Responsabilitatea dintre operatorul serverului și titularii de conturi
Pe un server cPanel cu multe conturi, administratorul WHM poartă responsabilitatea pentru PHP, servicii și configurația la nivel de server. Titularii conturilor individuale răspund de aplicațiile, pluginurile și datele lor de acces. Informați titularii conturilor când și cum s-a făcut actualizarea și recomandați-le să-și verifice aplicațiile pentru nereguli. Cum arată situația din perspectiva clientului descrie articolul Shared hosting.
Păstrați jurnalele începând cu 20.10.2026. Un patch nu elimină programele malițioase introduse anterior.
Pentru dovadă este suficient un protocol simplu pentru fiecare server: data și ora actualizării, lista pachetelor ea-php și alt-php cu versiunea dinainte și de după, lista proceselor cu orele de pornire după repornire și, dacă este cazul, confirmarea furnizorului de pachete cu privire la backporturi. Păstrați protocolul în afara serverului. Mai târziu, el servește drept dovadă față de clienți, asigurători sau auditori și ușurează următoarea actualizare de urgență, pentru că pașii sunt deja descriși. Dacă operați mai multe servere cPanel, merită să adunați comenzile de citire de pe această pagină într-un mic script care rulează identic pe toate mașinile și colectează rezultatele. Astfel observați dintr-o privire diferențele dintre servere, de exemplu o versiune PHP uitată.
Cum ajută PHP SOS concret?
- Inventariem pachetele ea-php, alt-php și cele de sistem și atribuim toate conturile versiunii lor PHP.
- Prin serviciul nostru de patch PHP actualizăm, repornim toate serviciile și dovedim starea cu liste de pachete și ore de pornire ale proceselor.
- Acolo unde este nevoie, setăm valorile provizorii la nivel de server și astfel încât să nu poată fi suprascrise.
- Verificăm conturile pentru urme tipice de compromitere și, în caz de constatări, inițiem eliminarea malware-ului.
- Apoi reducem numărul de versiuni PHP și securizăm configurația.
Întrebări frecvente
Unde văd în WHM ce versiune PHP folosește fiecare domeniu?
În MultiPHP Manager din WHM vedeți pentru fiecare domeniu versiunea atribuită și dacă PHP-FPM este activ. Pentru o listă completă este util și interogarea din linia de comandă. Notați și versiunile care nu sunt atribuite niciunui domeniu.
Poate un client cPanel să seteze singur valorile provizorii în .user.ini?
Pentru session.upload_progress.enabled, php.net precizează explicit că .user.ini și ini_set() nu sunt suficiente. Valoarea aparține în php.ini, în pool-ul FPM sau în configurația serverului. Acest lucru îl poate face doar administratorul serverului.
Este suficientă o repornire graceful a Apache?
La PHP-FPM trebuie să repornească chiar serviciile FPM; un reload Apache nu le reînnoiește. La handlerii PHP bazați pe Apache, o repornire completă este calea sigură. Verificați apoi ora de pornire a tuturor proceselor PHP.
Ce se întâmplă cu CloudLinux și alt-php?
Pe serverele CloudLinux, site-urile rulează uneori cu pachete alt-php proprii în loc de ea-php. Acestea au o stare proprie a pachetelor și trebuie verificate și actualizate separat.