php-cgi: o moștenire cu risc

Pe scurt: php-cgi este cea mai veche modalitate de a rula PHP în spatele unui server web și mai funcționează pe multe servere, adesea neobservat. Vulnerabilitatea php-cgi din PHP2Shell afectează explicit acest mod de operare. Actualizați, opriți toate procesele php-cgi în execuție și planificați trecerea la PHP-FPM.

Ce este php-cgi și unde mai rulează

PHP există în mai multe variante: ca program de linie de comandă, ca modul Apache, ca PHP-FPM și ca php-cgi. php-cgi este un program pe care îl pornește serverul web și căruia îi transmite cererile prin CGI sau FastCGI. Fără administrare proprie a proceselor, este mai simplu decât PHP-FPM, dar și mai puțin controlabil.

Locurile tipice sunt panourile de hosting mai vechi, Apache cu mod_fcgid, scripturile wrapper proprii pentru mai multe versiuni PHP și PHP pe Windows cu IIS prin FastCGI. În agenții și autorități se găsesc, în plus, servere configurate cu ani în urmă și operate de atunci doar în regim de funcționare.

Vulnerabilitatea php-cgi la PHP2Shell

PHP2Shell cuprinde vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 din PHP însuși, fiecare cu CVSS v4.0 9.2. Ambele permit executarea de cod malițios fără autentificare. Proiectul PHP menționează explicit php-cgi printre modurile de operare afectate, alături de PHP-FPM, mod_php, FrankenPHP și LiteSpeed.

Sunt remediate PHP 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, doar backporturi minime la nivel de sursă pentru 7.4, 8.0 și 8.1. Tocmai configurațiile php-cgi rulează peste medie de des pe versiuni vechi. php-cgi nu este, în plus, afectat pentru prima dată: încă din 2024, o vulnerabilitate din php-cgi pe Windows (CVE-2024-4577) a făcut valuri. Moștenirile de acest fel merită de aceea o atenție deosebită.

Găsiți php-cgi pe server

Comenzile următoare doar citesc și ajută la depistarea php-cgi. Căile și numele modulelor sunt exemple.

# Procesele php-cgi în execuție, cu ora de pornire și utilizatorul
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Programele php-cgi instalate
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: este încărcat mod_fcgid sau mod_cgi?
apache2ctl -M 2>/dev/null | grep -Ei 'fcgid|cgi'
grep -RniE 'FcgidWrapper|AddHandler.*php|Action.*php' /etc/apache2 /etc/httpd 2>/dev/null

Dacă găsiți intrări FcgidWrapper sau handleri care indică un program php-cgi, acest mod de operare este în uz. Verificați pentru fiecare program găsit versiunea cu -v. La pachetele distribuției, jurnalul de modificări cu numerele CVE dovedește patchul, deoarece backporturile nu schimbă adesea numărul de versiune.

Actualizați și opriți toate procesele

Instalați actualizarea prin gestionarul de pachete sau prin sursa din care provine php-cgi. Apoi toate procesele php-cgi în execuție trebuie să dispară. La mod_fcgid, Apache ține procesele disponibile o vreme; o repornire completă a Apache le oprește.

# Reporniți complet Apache (Debian/Ubuntu, respectiv familia RHEL)
systemctl restart apache2   # sau: systemctl restart httpd

# Control: mai există procese php-cgi mai vechi decât actualizarea?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Dacă php-cgi rulează printr-un manager de procese propriu sau printr-un serviciu al panoului, reporniți-l pe acesta. Pe Windows cu IIS reciclați pool-urile de aplicații, vezi PHP pe Windows și IIS.

Măsuri provizorii la php-cgi

php.net recomandă măsuri provizorii care nu oferă o protecție completă. La php-cgi, valorile aparțin în php.ini încărcat de programul respectiv sau în configurația serverului. Fișierele .user.ini și ini_set() nu sunt suficiente pentru session.upload_progress.enabled, potrivit php.net.

; php.ini al instalării php-cgi
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Cu funcție de încărcare, php.net indică post_max_size = 32M. Pe PHP 8.5 se adaugă fatal_error_backtraces=0. Limitele de memorie le setați prin cgroups pentru serviciul serverului web, nu prin RLIMIT_AS sau RLIMIT_DATA. Apoi reporniți toate procesele.

Calea către PHP-FPM

Pe termen lung, php-cgi nu este o alegere bună. PHP-FPM oferă pool-uri pentru fiecare site, utilizatori proprii, limite pentru fiecare pool, pagini de stare și reporniri controlate. Trecerea se poate planifica, de regulă, bine: instalați PHP-FPM, creați pool-uri, treceți serverul web pe FastCGI către PHP-FPM, eliminați scripturile wrapper. Cum arată o construcție curată arată articolul Securizarea Nginx cu PHP-FPM. Dacă rulează în plus o versiune PHP veche, combinați trecerea cu upgrade-ul.

Până la trecere, ar trebui să examinați critic configurația existentă. Serverul web ar trebui să transmită către php-cgi doar fișiere cu extensia .php și nu căi care indică fișiere inexistente. În directoarele de încărcare nu trebuie să fie posibilă execuția PHP. Scripturile wrapper care încarcă un php.ini propriu pentru fiecare site verificați-le dacă aceste fișiere anulează din nou valorile provizorii. Dacă un program php-cgi se află direct într-un director accesibil public, precum cgi-bin, trebuie eliminat de acolo. Astfel de moșteniri provin adesea din ghiduri de instalare din anii trecuți și sunt pur și simplu uitate la reconstruirile ulterioare. Documentați fiecare constatare cu calea și scopul, pentru ca reconstrucția ulterioară să nu omită nimic.

Rămâne important: un patch nu elimină programele malițioase introduse anterior. Păstrați jurnalele începând cu 20.10.2026.

Cum ajută PHP SOS concret?

• Depistăm instalările php-cgi, wrapperele și handlerii și îi atribuim site-urilor.
• Actualizăm, oprim toate procesele vechi și documentăm starea.
• Pentru PHP 8.1 și mai vechi planificăm împreună cu dumneavoastră migrarea la o versiune PHP acceptată.
• În cadrul securizării serverelor înlocuim php-cgi cu PHP-FPM, cu pool-uri separate.

Întrebări frecvente

Surse

• php.net: anunțuri de securitate
• PHP 8 ChangeLog
• php.net: versiuni acceptate
• BSI: Oficiul Federal German pentru Securitatea Informațiilor