Mai multe versiuni PHP pe un server: patch separat pentru fiecare

Pe scurt: Dacă pe un server rulează mai multe versiuni PHP, după PHP2Shell fiecare trebuie verificată, actualizată și repornită separat. Sursele tipice sunt sistemul de operare, panourile de hosting precum Plesk sau cPanel, surse terțe precum sury.org sau Remi, CloudLinux, LiteSpeed și versiunile compilate de dumneavoastră. Abia o listă completă din pachete, fișiere și procese care rulează arată dacă într-adevăr nu a fost trecută cu vederea nicio versiune.

Versiunea uitată

Un server care rulează de câțiva ani adună versiuni PHP așa cum o mansardă adună mobilă veche. Panoul a adus trei ramuri, pentru un client s-a adăugat o versiune mai veche dintr-o sursă terță, iar sistemul de operare o are pe a lui. Fiecare a fost instalată cândva dintr-un motiv întemeiat. Doar că astăzi nimeni nu mai știe care este încă necesară.

După PHP2Shell, exact aceasta este o problemă. Corecțiile au apărut pe 21 octombrie 2026 pentru PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Fiecare instalare de pe server le primește însă pe propria cale, de la propriul responsabil de pachet și în propriul moment. Pentru PHP 8.1 și mai vechi există doar backporturi minime la nivel de sursă. Cine actualizează doar versiunea principală le lasă deschise pe celelalte.

De unde vin atâtea versiuni

Tabelul următor indică surse tipice și căi exemplificative. Căile exacte diferă în funcție de versiune și distribuție.

Deosebit de pieziș sunt pachetele sury.org, deoarece folosesc aceleași căi ca distribuția. Dacă un php8.3 provine din Debian sau din sury.org arată abia sursa pachetului. Particularitățile le descriu articolele Repository-ul sury.org și Repository-ul Remi. Cum își administrează Plesk versiunile descrie pagina Servere Plesk: verificarea și patchul versiunilor PHP.

Găsirea tuturor instalărilor PHP

O listă de încredere rezultă din trei perspective. Comenzile sunt exclusiv de citire și, în funcție de server, pot rula un timp.

# 1. Pachete: ce cunoaște gestionarul de pachete
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Fișiere: binare PHP executabile, inclusiv în afara gestionarului de pachete
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Procese: ce rulează efectiv acum, cu ora de pornire
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Comparați cele trei liste. Un fișier fără pachet indică o versiune compilată sau copiată manual. Un proces fără fișier corespunzător poate indica o instalare ștearsă, dar încă în execuție. La Apache verificați suplimentar dacă este încărcat un modul PHP, de exemplu cu apache2ctl -M sau httpd -M. Containerele și podurile Kubernetes apar în aceste liste doar parțial și necesită o verificare separată a imaginilor.

Patch separat pentru fiecare versiune

Când fiecare instalare are un rând în lista dumneavoastră, urmează pentru fiecare același flux:

1. Clarificați responsabilitatea: Patchul vine de la distribuție, de la panou, dintr-o sursă terță sau de la dumneavoastră?
2. Evaluați nivelul: versiune oficială corectată, backport confirmat, neclarificat sau deschis.
3. Actualizați: pe calea sursei respective, nu pe alta.
4. Reporniți: serviciul acelei versiuni, nu doar serviciul principal. La mod_php, serverul web. Detalii găsiți la Repornirea PHP-FPM și a tuturor workerilor.
5. Controlați: comparați ora de pornire a proceselor cu momentul actualizării.
6. Documentați: versiune, nivelul pachetului, dovadă, ora repornirii.

Pentru versiunile pentru care nu există patch, până la migrare se aplică măsurile provizorii de pe php.net. Aplicați-le separat pentru fiecare versiune, deoarece fiecare instalare are propriul php.ini și propriile pool-uri.

Ce versiune folosește linia de comandă, care containerul?

Două domenii scapă deosebit de des prin ochiurile căutării. Primul este linia de comandă. Pe Debian și Ubuntu, sistemul de alternative decide ce binar se află în spatele comenzii php. update-alternatives --display php arată ce versiuni sunt înregistrate și care este cea valabilă acum. Cronjob-urile care apelează o cale fixă precum /usr/bin/php7.4 ocolesc însă această setare. De aceea merită să priviți crontab-urile tuturor utilizatorilor și configurația panourilor care creează propriile cronjob-uri.

Al doilea domeniu sunt containerele. Un container Docker de pe server aduce propria versiune PHP, care nu apare în nicio listă de pachete a gazdei. docker ps arată containerele care rulează; dacă în ele se află PHP și în ce versiune arată o privire în imagine sau un php -v în container. Patchul se face acolo nu pe gazdă, ci prin reconstruirea imaginii și înlocuirea containerului.

Mai puțin înseamnă mai sigur

Cea mai bună verificare este cea pe care nu trebuie să o faceți. Fiecare versiune PHP instalată dublează efortul la următoarea vulnerabilitate. După PHP2Shell merită de aceea o regulă clară: fiecare versiune de pe server are nevoie de un scop și de un responsabil. Ceea ce nu are este mai întâi dezactivat și, după o perioadă de observare, eliminat. Mai multe în articolul Dezactivarea versiunilor PHP vechi în panoul de hosting.

Cum ajută PHP SOS concret?

• Întocmim pentru serverele dumneavoastră o listă completă a tuturor instalărilor PHP din pachete, fișiere, procese și containere.
• Clarificăm pentru fiecare versiune proveniența, responsabilitatea și nivelul de patch.
• În cadrul serviciului de patch PHP actualizăm fiecare versiune, repornim fiecare serviciu și documentăm nivelul.
• Stabilim împreună cu dumneavoastră ce versiuni rămân și le eliminăm controlat pe celelalte.

Întrebări frecvente

Surse

• php.net: anunțuri de securitate
• php.net: versiuni acceptate
• Red Hat Security Bulletin RHSB-2026-013