LINUXPEDIA / TUTORIAL

PHP2Shell 2026 pe cPanel & WHM: actualizare PHP și securizare server

Publicat:

Tutorial PHP2Shell 2026 pentru cPanel & WHM: verifică versiunile PHP vulnerabile, actualizează EasyApache 4 prin SSH și securizează serverul.

Actualizat: 30 octombrie 2026. Vulnerabilitățile PHP2Shell, urmărite prin CVE-2026-109618 și CVE-2026-109619, afectează procesarea cererilor HTTP în PHP și pot permite executarea de cod la distanță fără autentificare. Pentru administratorii cPanel & WHM, remedierea înseamnă mai mult decât o actualizare a panoului: trebuie inventariate și actualizate toate interpretoarele PHP folosite de domenii, apoi verificate procesele active și eventualele implementări PHP alternative.

Important: acest tutorial este destinat administratorilor cu acces root. Comenzile de inventariere sunt neintruzive; comenzile de actualizare pot reporni servicii și trebuie executate într-o fereastră de mentenanță, după backup și testarea compatibilității. Nu utiliza exploituri publice pentru a verifica vulnerabilitatea pe serverele de producție.

1. Ce este PHP2Shell și de ce contează pentru cPanel?

PHP2Shell desemnează două probleme de corupere a memoriei în gestionarea cererilor PHP. CVE-2026-109618 implică gestionarea defectuoasă a unei situații de memorie insuficientă în timpul parsării cererii. CVE-2026-109619 privește starea internă păstrată incorect între operațiuni. În anumite condiții, aceste defecte pot duce la executarea de cod arbitrar înainte ca aplicația PHP să poată aplica propriile verificări.

Riscul nu este limitat la WordPress: pot fi afectate și Laravel, Magento, Joomla, Drupal sau aplicațiile PHP personalizate. Contează versiunea și compilarea interpreterului PHP care deservește cererea, nu versiunea CMS-ului. PHP-FPM, Apache mod_php, php-cgi și alte integrări pot fi afectate; proiectul PHP a semnalat un risc deosebit de ridicat pentru mod_php.

2. Ce versiuni PHP necesită actualizare?

Ramură PHP Prima versiune upstream care remediază cele două CVE-uri inițiale Recomandare
8.5 8.5.12 Instalează cel mai recent build disponibil de la furnizor.
8.4 8.4.27 Instalează cel mai recent build disponibil de la furnizor.
8.3 8.3.36 Instalează cel mai recent build disponibil de la furnizor.
8.2 8.2.35 Instalează cel mai recent build disponibil de la furnizor.
8.1 și mai vechi Ramuri ieșite din suportul upstream Migrează către o versiune suportată sau verifică explicit un backport de securitate furnizat de vendor.

Atenție la backporturi: un pachet distribuit de cPanel, CloudLinux sau un alt furnizor poate conține remedierea fără să afișeze exact numărul versiunii upstream din tabel. Invers, simpla existență a unui număr de versiune nu demonstrează că fiecare instanță PHP utilizată de server a fost actualizată. Verifică informațiile de securitate și changelog-ul pachetului instalat.

CVE-2026-115560 este o problemă separată, comunicată ulterior, legată de anumite configurații care folosesc mecanismul PHP de progres al încărcării fișierelor în sesiune. Nu considera actualizările din 21 octombrie o remediere automată și pentru această vulnerabilitate; urmărește advisory-ul furnizorului și aplică actualizările ulterioare.

3. Pregătirea intervenției

  1. Verifică dacă ai acces root prin SSH și în WHM.
  2. Programează o fereastră de mentenanță; actualizarea PHP poate reporni procesele PHP-FPM sau serverul web.
  3. Confirmă existența unui backup recent al conturilor, bazelor de date și configurațiilor, plus o procedură de restaurare testată.
  4. Inventariază aplicațiile care depind de extensii PHP speciale, ionCube, versiuni vechi PHP sau module personalizate.
  5. Nu dezactiva firewall-ul, ModSecurity sau WAF-ul pentru a accelera actualizarea.

4. Audit SSH: sistemul, cPanel și interpretoarele PHP

Conectează-te ca root și execută comenzile de mai jos. Acestea doar citesc configurația.

cat /etc/os-release
/usr/local/cpanel/cpanel -V
uname -r

# Versiunea PHP implicită din shell (nu reprezintă neapărat PHP-ul website-urilor)
php -v
command -v php

# Interpretoarele EasyApache instalate
for bin in /opt/cpanel/ea-php*/root/usr/bin/php; do
  [ -x "$bin" ] || continue
  echo "===== $bin ====="
  "$bin" -v | head -n 2
done

# Pachetele PHP instalate din EasyApache 4 (AlmaLinux/Rocky Linux)
rpm -qa 'ea-php*' | sort

# Procese și servicii relevante
ps -eo pid,user,args | grep -E '[p]hp-fpm|[l]sphp|[h]ttpd|[l]itespeed' | head -n 80

Comanda php -v poate arăta un PHP CLI diferit de versiunea folosită efectiv de un domeniu. În cPanel, MultiPHP Manager poate asocia versiuni diferite fiecărui site. Dacă folosești LiteSpeed Enterprise, verifică și handlerul LSAPI și binarele PHP pe care le utilizează efectiv.

5. Verificarea versiunilor PHP atribuite domeniilor

Din WHM deschide Software → MultiPHP Manager și verifică toate domeniile, inclusiv subdomeniile și domeniile de test. Notează versiunile PHP atribuite și handlerul utilizat. Într-un server cu zeci de conturi, este posibil să existe simultan PHP 8.1, 8.2, 8.3 și 8.4.

Din SSH, poți inspecta și fișierele de configurare cPanel, fără să le modifici:

# Listarea versiunilor PHP instalate în EasyApache
ls -d /opt/cpanel/ea-php*/root/usr/bin/php 2>/dev/null

# Identificarea configurațiilor de domeniu și a handlerelor
ls -ld /var/cpanel/userdata/* 2>/dev/null | head -n 30

# Versiunile și pachetele disponibile pentru actualizare
dnf check-update 'ea-php*' || test "$?" -eq 100

Notă: dnf check-update poate returna codul 100 când există actualizări disponibile; acesta nu este, în sine, un eșec. Pe Ubuntu cu cPanel folosește mecanismul APT corespunzător, nu DNF.

6. Metoda recomandată: actualizare din WHM → EasyApache 4

  1. Autentifică-te în WHM ca administrator.
  2. Accesează Software → EasyApache 4.
  3. Verifică profilul curent și versiunile PHP instalate.
  4. Folosește funcția Run System Update pentru actualizarea pachetelor disponibile, inclusiv pachetele EasyApache relevante.
  5. Dacă o versiune PHP este depășită și nu primește corecții, planifică instalarea unei versiuni suportate și migrarea domeniilor din MultiPHP Manager.
  6. După actualizare, verifică statusul serviciilor, logurile și funcționarea aplicațiilor.

Nu confunda actualizarea pachetelor PHP cu schimbarea versiunii majore PHP. cPanel actualizează buildurile ramurilor instalate, dar nu mută automat toate domeniile de pe PHP 8.1 pe PHP 8.4, de exemplu.

7. Actualizarea prin SSH pe AlmaLinux și Rocky Linux

Pe un server cPanel care folosește EasyApache 4 și pachete RPM, administratorul poate aplica actualizările prin DNF. Înainte de execuție, verifică sursele de pachete și lista de tranzacții propuse.

# Inventariere actualizări disponibile
dnf check-update 'ea-php*' || test "$?" -eq 100

# Simulare de tranzacție, fără instalare
dnf upgrade --assumeno 'ea-php*'

# Actualizarea pachetelor PHP EasyApache instalate
# EXECUTĂ NUMAI DUPĂ BACKUP ȘI VALIDAREA TRANZACȚIEI
dnf upgrade 'ea-php*'

Dacă furnizorul a distribuit și alte pachete relevante pentru remediere, urmează advisory-ul său oficial. O actualizare completă de sistem se planifică separat, deoarece poate implica biblioteci, kernel sau alte servicii și poate necesita reboot. Evită amestecarea pachetelor PHP din depozite incompatibile cu EasyApache.

Pe serverele care folosesc CloudLinux ALT-PHP, pachetele și mecanismul de actualizare sunt distincte de EasyApache. Verifică CloudLinux PHP Selector și advisory-urile CloudLinux; actualizarea exclusivă a pachetelor ea-php* nu acoperă automat interpretoarele ALT-PHP.

8. Repornirea controlată a PHP-FPM și a serviciilor web

După instalarea pachetelor, procesele PHP deja pornite pot continua să ruleze codul anterior până la repornire. cPanel documentează următoarea comandă pentru serviciul Apache PHP-FPM:

/usr/local/cpanel/scripts/restartsrv_apache_php_fpm --hard

Execută această comandă doar dacă folosești Apache PHP-FPM și într-o fereastră de mentenanță. Pentru configurațiile cu LiteSpeed Enterprise/LSAPI, folosește procedura de restart recomandată de LiteSpeed pentru handlerul PHP activ; nu presupune că restartarea Apache PHP-FPM reîncarcă procesele LSAPI. Evită restartările indiscriminate și verifică ce handler deservește efectiv fiecare domeniu.

9. Verificări după actualizare

# Versiuni efective ale interpretoarelor EasyApache
for bin in /opt/cpanel/ea-php*/root/usr/bin/php; do
  [ -x "$bin" ] || continue
  printf '%s: ' "$bin"
  "$bin" -r 'echo PHP_VERSION, PHP_EOL;'
done

# Versiuni și release-uri ale pachetelor RPM
rpm -qa 'ea-php*' | sort

# Actualizări PHP rămase disponibile
dnf check-update 'ea-php*' || test "$?" -eq 100

# Starea serviciilor, în funcție de handler
systemctl --failed
ps -eo pid,lstart,user,args | grep -E '[p]hp-fpm|[l]sphp' | head -n 50

Testează fiecare website critic: homepage, autentificare, formulare, upload, cron, comenzi WP-CLI, coș și checkout WooCommerce, joburi Laravel, integrarea Redis și extensiile PHP. Verifică jurnalele aplicațiilor și ale serverului web pentru erori noi. Nu crea un fișier phpinfo() accesibil public pentru testare; dacă este absolut necesar, limitează accesul și șterge-l imediat.

Criteriul de închidere: toate interpretoarele folosite de domenii trebuie să provină din builduri confirmate ca remediate de vendor, iar procesele care executau codul vechi trebuie reîncărcate. O singură comandă php -v nu demonstrează acest lucru.

10. Măsuri temporare dacă patchul nu este încă disponibil

  • Restricționează expunerea aplicațiilor neesențiale și a mediilor de test.
  • Menține activ ModSecurity și actualizează seturile de reguli WAF.
  • Aplică regulile gestionate Cloudflare sau ale furnizorului WAF, când sunt disponibile și compatibile cu traficul legitim.
  • Redu privilegiile proceselor PHP și verifică separarea conturilor de găzduire.
  • Monitorizează erorile neobișnuite, căderile proceselor PHP, consumul de memorie și execuțiile suspecte.
  • Planifică migrarea versiunilor PHP ieșite din suport.

WAF-ul poate reduce expunerea, dar nu înlocuiește actualizarea PHP. Nu aplica reguli generice care blochează toate cererile POST sau dezactivează funcții PHP la întâmplare: acestea pot întrerupe aplicațiile fără să elimine cauza vulnerabilității.

11. Cum investighezi un posibil incident

Dacă serverul prezintă indicii de compromitere, nu șterge imediat jurnalele și nu presupune că actualizarea PHP elimină un atacator deja prezent. Izolează sistemul conform procedurii de răspuns la incidente, păstrează probele și investighează:

  • jurnalele Apache, LiteSpeed, ModSecurity și WAF pentru cereri anormale;
  • erorile PHP-FPM/LSAPI, restartările neașteptate și segfault-urile;
  • fișiere PHP recent modificate în directoarele publice și în zonele de upload;
  • conturile noi, cheile SSH, cron joburile și procesele neobișnuite;
  • conexiunile de rețea și accesul la secrete, baze de date și fișiere de configurare.

După confirmarea compromiterii, poate fi necesară reconstruirea serverului dintr-o sursă de încredere, restaurarea datelor verificate și rotația credențialelor. Simpla repornire a PHP-FPM nu este o procedură de remediere a unui incident.

12. Întrebări frecvente

Actualizarea cPanel din WHM rezolvă automat PHP2Shell?

Nu neapărat. Verifică dacă pachetele PHP folosite de domenii au primit buildurile remediate. Actualizarea panoului și actualizarea interpretoarelor PHP sunt operațiuni care trebuie validate separat.

Trebuie să actualizez și WordPress sau Laravel?

Da, ca măsură generală de securitate și compatibilitate, dar actualizarea aplicației nu înlocuiește remedierea interpreterului PHP vulnerabil.

Este suficient să verific php -v?

Nu. PHP CLI poate fi diferit de PHP-ul folosit de website-uri. Verifică fiecare versiune EasyApache sau ALT-PHP și asocierea domeniilor din MultiPHP Manager ori PHP Selector.

PHP-FPM este imun?

Nu. PHP-FPM este inclus între modurile de execuție afectate. Riscul și condițiile de exploatare pot varia, dar actualizarea rămâne necesară.

Ce fac dacă folosesc LiteSpeed Enterprise?

Verifică versiunea PHP și handlerul LSAPI activ pentru fiecare domeniu. Actualizează pachetele PHP corespunzătoare și reîncarcă procesele conform documentației LiteSpeed.

Ce fac dacă folosesc PHP 7.4 sau 8.1?

Prioritizează migrarea la o ramură suportată. Dacă furnizorul oferă un backport pentru versiunea veche, verifică explicit numărul buildului și advisory-ul; nu considera toate instalările vechi remediate implicit.

13. Checklist final pentru administrator

  • ☐ Backup verificat și fereastră de mentenanță aprobată.
  • ☐ Toate domeniile și versiunile PHP inventariate.
  • ☐ Pachetele EasyApache și, dacă există, ALT-PHP actualizate.
  • ☐ Buildurile comparate cu advisory-urile furnizorilor.
  • ☐ Procesele PHP vechi reîncărcate controlat.
  • ☐ Website-urile și funcțiile critice testate.
  • ☐ WAF, jurnale și monitorizare verificate.
  • ☐ CVE-2026-115560 urmărită separat.

14. Surse și documentație oficială

Notă editorială: acest material descrie proceduri de administrare defensivă. Disponibilitatea exactă a pachetelor remediate depinde de sistemul de operare, depozitele configurate, furnizor și momentul actualizării. Verifică întotdeauna advisory-ul aplicabil serverului înainte de a declara incidentul remediat.

Andrei
DESPRE AUTOR

Andrei

Administrator

Vezi profilul autorului →