php-cgi: staro breme s tveganjem

Na kratko: php-cgi je najstarejši način delovanja PHP za spletnim strežnikom in še vedno teče na mnogih strežnikih, pogosto neopazno. Ranljivost php-cgi pri PHP2Shell ta način delovanja izrecno zadeva. Popravite, končajte vse delujoče procese php-cgi in načrtujte prehod na PHP-FPM.

Kaj je php-cgi in kje še teče

PHP obstaja v več različicah: kot program ukazne vrstice, kot modul Apache, kot PHP-FPM in kot php-cgi. php-cgi je program, ki ga zažene spletni strežnik in mu prek CGI ali FastCGI predaja zahteve. Brez lastnega upravljanja procesov je preprostejši od PHP-FPM, a tudi slabše nadzorljiv.

Tipična najdišča so starejše gostiteljske plošče, Apache z mod_fcgid, lastne skripte ovojnice (wrapper) za več različic PHP in PHP v sistemu Windows z IIS prek FastCGI. V agencijah in uradih se poleg tega najdejo strežniki, ki so bili postavljeni pred leti in se od takrat samo še obratujejo.

Ranljivost php-cgi pri PHP2Shell

PHP2Shell obsega ranljivosti CVE-2026-109618 in CVE-2026-109619 v samem PHP, vsaka s CVSS v4.0 9,2. Obe omogočata izvajanje škodljive kode brez prijave. Projekt PHP php-cgi izrecno navaja med prizadetimi načini delovanja, poleg PHP-FPM, mod_php, FrankenPHP in LiteSpeed.

Odpravljeni so PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Za PHP 8.1 in starejše uradnih posodobitev ni več, samo minimalni backporti izvorne kode za 7.4, 8.0 in 8.1. Prav zgradbe php-cgi nadpovprečno pogosto tečejo na starih različicah. php-cgi poleg tega ni prizadet prvič: že leta 2024 je ranljivost v php-cgi v sistemu Windows (CVE-2024-4577) vzbudila pozornost. Taka stara bremena zato zaslužijo posebno pozornost.

Poiščite php-cgi na strežniku

Spodnji ukazi samo berejo in pomagajo izslediti php-cgi. Poti in imena modulov so primeri.

# Delujoči procesi php-cgi s časom zagona in uporabnikom
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Nameščeni programi php-cgi
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: je naložen mod_fcgid ali 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

Če najdete vnose FcgidWrapper ali handlerje, ki kažejo na program php-cgi, ta način delovanja teče. Za vsak najden program preverite različico z -v. Pri paketih distribucij popravek dokazuje dnevnik sprememb s številkami CVE, ker backporti številke različice pogosto ne spremenijo.

Popravite in končajte vse procese

Posodobitev namestite prek upravitelja paketov ali vira, iz katerega izvira php-cgi. Nato morajo izginiti vsi delujoči procesi php-cgi. Pri mod_fcgid Apache procese nekaj časa zadržuje; popoln ponovni zagon Apacheja jih konča.

# Popolnoma znova zaženite Apache (Debian/Ubuntu oziroma družina RHEL)
systemctl restart apache2   # ali: systemctl restart httpd

# Kontrola: ali še obstajajo procesi php-cgi, starejši od posodobitve?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Če php-cgi teče prek lastnega upravitelja procesov ali storitve plošče, znova zaženite tega. V sistemu Windows z IIS reciklirajte skupine aplikacij, glej PHP v sistemu Windows in IIS.

Vmesni ukrepi pri php-cgi

php.net priporoča vmesne ukrepe, ki ne nudijo popolne zaščite. Pri php-cgi sodijo vrednosti v php.ini, ki jo nalaga posamezni program, ali v konfiguracijo strežnika. Datoteke .user.ini in ini_set() za session.upload_progress.enabled po navedbah php.net ne zadoščajo.

; php.ini namestitve php-cgi
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

S funkcijo nalaganja datotek php.net navaja post_max_size = 32M. Pri PHP 8.5 se doda fatal_error_backtraces=0. Omejitve pomnilnika nastavite prek cgroups za storitev spletnega strežnika, ne prek RLIMIT_AS ali RLIMIT_DATA. Nato znova zaženite vse procese.

Pot do PHP-FPM

Dolgoročno php-cgi ni dobra izbira. PHP-FPM ponuja poole za vsako spletno stran, lastne uporabnike, meje za vsak pool, statusne strani in nadzorovane ponovne zagone. Prehod je praviloma dobro načrtljiv: namestite PHP-FPM, ustvarite poole, spletni strežnik preusmerite na FastCGI do PHP-FPM, skripte ovojnice odstranite. Kako je videti čista zgradba, kaže stran Zaščita Nginxa s PHP-FPM. Če poleg tega teče še stara različica PHP, prehod združite s nadgradnjo.

Do prehoda obstoječo konfiguracijo kritično preverite. Spletni strežnik naj php-cgi predaja samo datoteke s končnico .php in nobenih poti, ki kažejo na neobstoječe datoteke. V imenikih za nalaganje izvajanje PHP ne sme biti mogoče. Skripte ovojnice, ki za vsako spletno stran naložijo lastno php.ini, preverite, ali te datoteke vmesnih vrednosti spet ne razveljavijo. Če program php-cgi leži neposredno v javno dosegljivem imeniku, kot je cgi-bin, ga je treba od tam odstraniti. Taka stara bremena pogosto izvirajo iz namestitvenih navodil preteklih let in se pri poznejših predelavah preprosto pozabijo. Vsako najdbo dokumentirajte s potjo in namenom, da poznejša predelava ničesar ne spregleda.

Pomembno ostaja: popravek ne odstrani škodljive programske opreme, ki je bila vnesena prej. Dnevnike hranite od 20. 10. 2026 naprej.

Kako PHP SOS konkretno pomaga?

• Poiščemo namestitve php-cgi, ovojnice in handlerje ter jih povežemo s spletnimi stranmi.
• Popravimo, končamo vse stare procese in dokumentiramo stanje.
• Za PHP 8.1 in starejše z vami načrtujemo migracijo na podprto različico PHP.
• V okviru utrditve strežnika php-cgi nadomestimo s PHP-FPM z ločenimi pooli.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• PHP 8 ChangeLog
• php.net: podprte različice
• BSI (nemški zvezni urad za informacijsko varnost)