Pe scurt: Pentru administratorii fără experiență de dezvoltare, cinci noțiuni de bază sunt suficiente pentru a opera PHP în siguranță: PHP este format din mai multe programe (linia de comandă, PHP-FPM, modulul Apache), fiecare cu propria versiune; setările acționează pe niveluri, de la php.ini până la aplicație; PHP-FPM distribuie cererile pe workeri, în pool-uri; o actualizare are efect abia după repornirea tuturor proceselor; iar logurile sunt cel mai important indiciu atunci când ceva nu este în regulă. Cine cunoaște aceste puncte poate închide rapid și dovedibil vulnerabilități precum PHP2Shell.
Din ce este alcătuit PHP pe un server
PHP nu este un singur program. Pe un server Linux tipic se găsesc mai multe variante, fiecare conectată printr-o interfață de server (SAPI):
| Variantă | Nume tipic | Pentru ce |
|---|---|---|
| Linia de comandă (CLI) | php, php8.3 |
cronjob-uri, Composer, scripturi de mentenanță |
| PHP-FPM | php-fpm, php-fpm8.3 |
cereri web în spatele Nginx sau Apache |
| Modul Apache | mod_php, libphp |
cereri web direct în procesul Apache |
| CGI | php-cgi |
structuri mai vechi |
Fiecare variantă poate avea altă versiune și alt php.ini. Pe multe servere rulează în plus mai multe versiuni PHP în paralel, de exemplu 8.2 și 8.4. La o actualizare, fiecare trebuie analizată separat. Cum lucrează interfețele explică PHP-FPM explicat.
Care variantă deservește efectiv site-urile dumneavoastră aflați din procesele care rulează și din configurația serverului web:
ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php # încarcă Apache un modul PHP?
ls /run/php/ 2>/dev/null # socket-uri FPM, adesea pe versiune și pool
Coloana cu ora de pornire este importantă mai târziu, la repornire: toate procesele PHP trebuie să fi pornit după momentul actualizării. Dacă procesele rulează sub utilizatori diferiți, aceasta indică pool-uri separate, ceea ce este bine. Dacă în Apache apare un modul PHP, deși toate site-urile ar trebui să ruleze prin FPM, este un indiciu al unei moșteniri vechi, care trebuie eliminată. Pentru interfețele de hosting precum Plesk sau cPanel se aplică același principiu, doar că interfața arată versiunile și handlerele pentru fiecare site; rămâne însă decisiv ce rulează efectiv ca proces.
Cele mai importante comenzi pentru administratori
php -v # versiunea liniei de comandă
php --ini # php.ini încărcat și directoarele citite suplimentar
php --ini=diff # din PHP 8.5: abateri de la valorile implicite
php -m # module compilate și încărcate
php --ri session # setările unei extensii
php -l datei.php # verificarea sintaxei, fără execuție
php-fpm8.3 -v # versiunea binarului FPM (numele diferă după distribuție)
php-fpm8.3 -t # testează configurația FPM, fără repornire
systemctl status php8.3-fpm
Două observații din manual: php -l găsește erori de sintaxă, dar nu erori care apar abia la execuție. Și php -i apelează phpinfo(); ieșirea nu are ce căuta în fișiere publice din directorul web.
Cum acționează setările PHP
O setare poate fi stabilită în mai multe locuri. Cine are voie să schimbe ce și unde reglementează modul de modificare al fiecărei directive:
- php.ini și conf.d: configurația de bază pentru fiecare variantă, citită la pornire.
- Pool-ul FPM:
php_valueșiphp_admin_valuepentru fiecare pool. Valorile setate cuphp_admin_valuenu pot fi suprascrise de aplicație prinini_set(), potrivit manualului. - Nivelul directorului:
.user.inila FPM sau.htaccessla mod_php, doar pentru directive în modulINI_PERDIRsauINI_ALL. - Aplicația:
ini_set()la execuție, doar pentru directive în modulINI_ALL.
Un exemplu: memory_limit are modul INI_ALL, deci poate fi schimbat de aplicație. post_max_size are INI_PERDIR și nu poate fi schimbat prin ini_set(). De aceea php.net cere, la măsurile de tranziție PHP2Shell, ca valorile să fie setate astfel încât aplicațiile să nu le poată suprascrie. Detalii despre niveluri explică php.ini explicat.
Pool-urile PHP-FPM, pe scurt
Un pool este un grup de workeri cu utilizator propriu, socket propriu și setări proprii. Cele mai importante directive potrivit manualului:
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic ; static, dynamic sau ondemand
pm.max_children = 20 ; cel mult 20 de cereri simultane
pm.max_requests = 500 ; reînnoiește workerul după 500 de cereri
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
php_admin_value[error_log] = /var/log/php-fpm/shop-error.log
php_admin_flag[log_errors] = on
Un pool propriu pentru fiecare site, cu utilizator propriu, separă site-urile între ele. security.limit_extensions este implicit pe .php .phar și împiedică FPM să execute alte extensii de fișier decât PHP. clear_env este implicit activat și ține variabilele de mediu departe de worker.
Loguri: unde se uită administratorii
PHP scrie erorile în destinația stabilită cu error_log, PHP-FPM suplimentar în propriul log, iar pentru cererile lente în slowlog, cu backtrace. La acestea se adaugă logurile de acces și de erori ale serverului web. Aveți grijă ca display_errors să fie dezactivat în producție și log_errors activat: erorile aparțin logului, nu paginii web. Logurile ar trebui în plus rotite și păstrate o perioadă stabilită, pentru ca în caz de urgență să mai existe. După PHP2Shell, presa de specialitate recomandă păstrarea logurilor serverului începând cu 20.10.2026. Un semnal puternic de avertizare este un proces PHP-FPM sau al serverului web care pornește un shell; cum recunoașteți aceasta se găsește la Semnal de avertizare: serverul web pornește un shell.
Lista de verificare pentru administratori după PHP2Shell
- Enumerați toate variantele și versiunile PHP de pe server, inclusiv cele nefolosite.
- Verificați starea pachetului; la backport-urile distribuției, căutați în changelog CVE-2026-109618 și CVE-2026-109619.
- Actualizați la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, respectiv la backport-ul confirmat.
- Reporniți PHP-FPM, Apache și LiteSpeed și controlați orele de pornire ale proceselor.
- Contraprobă cu
php -r 'var_dump(ini_get("memory_hard_limit_percent"));';bool(false)înseamnă, potrivit manualului, o versiune afectată. - Securizați logurile și verificați-le pentru neregularități.
Cum dovediți solid versiunea și starea de patch descrie Verificarea corectă a versiunii PHP și a stării de patch.
Cum ajută PHP SOS concret?
În contractul de mentenanță de securitate preluăm împreună cu echipa dumneavoastră îngrijirea de bază a PHP:
- Inventar: toate variantele PHP, versiunile, pool-urile și locurile de configurare pentru fiecare server.
- Configurare: valori relevante pentru securitate setate cu
php_admin_value, pool-uri separate pentru fiecare site. - Actualizări: instalare, repornire, control și documentare la fiecare lansare de securitate.
- Transferul de cunoștințe: Le explicăm administratorilor dumneavoastră ce am schimbat și de ce.
Întrebări frecvente
De ce arată php -v o altă versiune decât site-ul?
Linia de comandă, PHP-FPM și modulul Apache sunt programe separate, cu versiune proprie și php.ini propriu. php -v arată doar linia de comandă. Pentru site contează versiunea binarului care procesează efectiv cererile.
Ce php.ini se aplică pe serverul meu?
Pentru linia de comandă, arată php --ini. Pentru PHP-FPM există de obicei un php.ini propriu și fișiere de pool suplimentare. Din PHP 8.5, php --ini=diff arată ce valori diferă de cele implicite.
Care este diferența dintre php_value și php_admin_value?
Ambele setează opțiuni într-un pool FPM. Valorile setate cu php_admin_value nu pot fi suprascrise de aplicație cu ini_set(), potrivit manualului. Pentru setările relevante pentru securitate, php_admin_value este de aceea alegerea corectă.
Este suficientă o actualizare fără repornire?
Nu. Procesele PHP care rulează păstrează codul vechi în memorie. După o actualizare, PHP-FPM, Apache cu mod_php sau LiteSpeed trebuie repornite, altfel versiunea vulnerabilă continuă să ruleze.