# php-cgi: naslijeđeni rizik

> php-cgi sigurnosna ranjivost PHP2Shell: pronađite CGI i FastCGI postavke, zakrpajte, zaustavite sve stare procese i planirajte prelazak na PHP-FPM.

Izvor: https://phpsos.de/hr/server/php-cgi/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**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.

```bash
# 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.

```bash
# 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](https://phpsos.de/hr/server/windows-iis-php/).

> **Djelujte odmah:**
> Ako php-cgi radi s PHP-om 8.1 ili starijim na javno dostupnom poslužitelju, službena zakrpa ne postoji. Odmah postavite privremene mjere i prema preporuci BSI-ja (njemački Savezni ured za informacijsku sigurnost) razmotrite privremeno odvajanje poslužitelja s mreže.

## 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.

```ini
; 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](https://phpsos.de/hr/server/nginx-php-fpm/). 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](https://phpsos.de/hr/leistungen/php-migration-legacy/).
- U okviru [ojačavanja poslužitelja](https://phpsos.de/hr/leistungen/server-haertung/) php-cgi zamjenjujemo PHP-FPM-om s odvojenim poolovima.


## Česta pitanja

**Koristim li php-cgi, a da to ne znam?**  
To je češće nego što se misli. Stariji paneli, FastCGI postavke s mod_fcgid i PHP na Windowsu s IIS-om često pokreću PHP kao php-cgi. Popis procesa ili Server API u phpinfo to pouzdano pokazuju.

**Je li FastCGI isto što i php-cgi?**  
Ne sasvim. FastCGI je protokol. I PHP-FPM i php-cgi mogu govoriti FastCGI, ali php-cgi je stariji, jednostavniji program bez poolova i upravljanja procesima. PHP2Shell izričito pogađa php-cgi.

**Što kod PHP-a znači klasični CGI?**  
Kod klasičnog CGI-ja web-poslužitelj za svaki zahtjev pokreće novi PHP proces. To je sporo i danas rijetko. Češći je php-cgi iza mod_fcgid ili FastCGI, gdje procesi obrađuju više zahtjeva.

**Moram li nakon ažuriranja nešto ponovno pokrenuti?**  
Da. Kod FastCGI postavki php-cgi procesi neko vrijeme nastavljaju raditi. Ponovno pokrenite web-poslužitelj odnosno upravitelj procesa i provjerite da nijedan php-cgi proces nije stariji od ažuriranja.

## Izvori

- [php.net: sigurnosne objave](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: podržane verzije](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)