php-cgi: naslijeđeni rizik

Ukratko: php-cgi je najstariji način pokretanja PHP-a iza web-poslužitelja i još radi na mnogim poslužiteljima, često neprimjetno. php-cgi sigurnosna ranjivost iz PHP2Shella izričito pogađa taj način rada. Zakrpajte, zaustavite sve php-cgi procese koji rade i planirajte prelazak na PHP-FPM.

Što je php-cgi i gdje još radi

PHP postoji u više varijanti: kao program naredbenog retka, kao Apache modul, kao PHP-FPM i kao php-cgi. php-cgi je program koji pokreće web-poslužitelj i kojem zahtjeve predaje putem CGI-ja ili FastCGI-ja. Bez vlastitog upravljanja procesima jednostavniji je od PHP-FPM-a, ali i manje kontroliran.

Tipična mjesta nalaza su stariji hosting paneli, Apache s mod_fcgid, vlastite wrapper skripte za više PHP verzija i PHP na Windowsu s IIS-om putem FastCGI-ja. U agencijama i tijelima uprave nalaze se uz to poslužitelji koji su postavljeni prije mnogo godina i od tada se samo održavaju u radu.

php-cgi sigurnosna ranjivost kod PHP2Shella

PHP2Shell obuhvaća ranjivosti CVE-2026-109618 i CVE-2026-109619 u samom PHP-u, svaku s CVSS v4.0 9,2. Obje omogućuju izvršavanje zlonamjernog koda bez prijave. PHP projekt izričito navodi php-cgi među pogođenim načinima rada, uz PHP-FPM, mod_php, FrankenPHP i LiteSpeed.

Ispravljeni su PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Za PHP 8.1 i starije više nema službenih ažuriranja, samo minimalni backporti izvornog koda za 7.4, 8.0 i 8.1. Upravo php-cgi postavke natprosječno često rade na starim verzijama. php-cgi osim toga nije prvi put pogođen: već je 2024. ranjivost u php-cgi na Windowsu (CVE-2024-4577) izazvala pozornost. Naslijeđeni sustavi te vrste zato zaslužuju posebnu pažnju.

Pronađite php-cgi na poslužitelju

Sljedeće naredbe samo čitaju i pomažu pronaći php-cgi. Putanje i nazivi modula su primjeri.

# php-cgi procesi koji rade s vremenom pokretanja i korisnikom
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Instalirani php-cgi programi
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: je li učitan mod_fcgid ili 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

Ako pronađete unose FcgidWrapper ili handlere koji pokazuju na php-cgi program, taj način rada je u upotrebi. Za svaki pronađeni program provjerite verziju s -v. Kod paketa distribucije zakrpu dokazuje zapisnik promjena s CVE brojevima jer backporti često ne mijenjaju broj verzije.

Zakrpajte i zaustavite sve procese

Ažuriranje instalirajte putem upravitelja paketa ili izvora iz kojeg php-cgi potječe. Nakon toga svi php-cgi procesi koji rade moraju nestati. Kod mod_fcgid Apache procese neko vrijeme drži u pričuvi; potpuno ponovno pokretanje Apachea zaustavlja ih.

# Potpuno ponovno pokrenite Apache (Debian/Ubuntu odnosno RHEL obitelj)
systemctl restart apache2   # ili: systemctl restart httpd

# Kontrola: ima li još php-cgi procesa starijih od ažuriranja?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Ako php-cgi radi putem vlastitog upravitelja procesa ili usluge panela, ponovno pokrenite njega. Na Windowsu s IIS-om reciklirajte aplikacijske poolove, vidi PHP na Windowsu i IIS-u.

Privremene mjere kod php-cgi-a

php.net preporučuje privremene mjere koje ne pružaju potpunu zaštitu. Kod php-cgi-a vrijednosti pripadaju u php.ini koji učitava dotični program ili u konfiguraciju poslužitelja. Datoteke .user.ini i ini_set() za session.upload_progress.enabled prema php.net-u nisu dovoljni.

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

Uz funkciju uploada php.net navodi post_max_size = 32M. Na PHP-u 8.5 dodaje se fatal_error_backtraces=0. Ograničenja memorije postavite putem cgroupa za uslugu web-poslužitelja, a ne putem RLIMIT_AS ili RLIMIT_DATA. Nakon toga ponovno pokrenite sve procese.

Put prema PHP-FPM-u

Dugoročno php-cgi nije dobar izbor. PHP-FPM nudi poolove po web-stranici, vlastite korisnike, ograničenja po poolu, stranice statusa i kontrolirana ponovna pokretanja. Prelazak je najčešće dobro izvediv: instalirati PHP-FPM, izraditi poolove, web-poslužitelj prebaciti na FastCGI prema PHP-FPM-u, ukloniti wrapper skripte. Kako izgleda uredna izvedba, pokazuje članak Zaštita Nginxa s PHP-FPM-om. Ako uz to radi i stara PHP verzija, prelazak povežite s nadogradnjom.

Dok prelazak ne bude proveden, postojeću konfiguraciju kritički provjerite. Web-poslužitelj bi php-cgi-u trebao predavati samo datoteke s nastavkom .php, a ne putanje koje pokazuju na nepostojeće datoteke. U direktorijima za upload ne smije biti moguće izvršavanje PHP-a. Wrapper skripte koje za svaku web-stranicu učitavaju vlastiti php.ini provjerite poništavaju li te datoteke ponovno privremene vrijednosti. Ako se php-cgi program nalazi izravno u javno dostupnom direktoriju poput cgi-bin, tamo ga treba ukloniti. Takvo naslijeđe često potječe iz uputa za instalaciju iz prošlih godina i pri kasnijim preinakama jednostavno bude zaboravljeno. Svaki nalaz dokumentirajte s putanjom i svrhom kako kasnija preinaka ništa ne bi propustila.

Ostaje važno: zakrpa ne uklanja zlonamjerni softver koji je ubačen prije. Sačuvajte zapisnike od 20. 10. 2026.

Kako PHP SOS konkretno pomaže?

• Pronalazimo php-cgi instalacije, wrappere i handlere te ih pridružujemo web-stranicama.
• Zakrpamo, zaustavljamo sve stare procese i dokumentiramo stanje.
• Za PHP 8.1 i starije s Vama planiramo migraciju na podržanu PHP verziju.
• U okviru ojačavanja poslužitelja php-cgi zamjenjujemo PHP-FPM-om s odvojenim poolovima.

Česta pitanja

Izvori

• php.net: sigurnosne objave
• PHP 8 ChangeLog
• php.net: podržane verzije
• BSI