# php-cgi: staro breme s tveganjem

> Ranljivost php-cgi pri PHP2Shell: poiščite nastavitve CGI in FastCGI, popravite, končajte vse stare procese in načrtujte prehod na PHP-FPM.

Vir: https://phpsos.de/sl/server/php-cgi/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

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

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

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

> **Ukrepajte takoj:**
> Če php-cgi teče s PHP 8.1 ali starejšim na javno dosegljivem strežniku, uradnega popravka ni. Takoj nastavite vmesne ukrepe in po priporočilu BSI razmislite o začasnem odklopu strežnika z omrežja.

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

```ini
; 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](https://phpsos.de/sl/server/nginx-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](https://phpsos.de/sl/leistungen/php-migration-legacy/).
- V okviru [utrditve strežnika](https://phpsos.de/sl/leistungen/server-haertung/) php-cgi nadomestimo s PHP-FPM z ločenimi pooli.


## Pogosta vprašanja

**Ali uporabljam php-cgi, ne da bi vedel?**  
To je pogosteje, kot bi si mislili. Starejše plošče, zgradbe FastCGI z mod_fcgid in PHP v sistemu Windows z IIS pogosto zaženejo PHP kot php-cgi. Seznam procesov ali Server API v phpinfo to zanesljivo pokaže.

**Ali je FastCGI isto kot php-cgi?**  
Ne povsem. FastCGI je protokol. PHP-FPM in php-cgi znata oba govoriti FastCGI, php-cgi pa je starejši, preprostejši program brez poolov in upravljanja procesov. PHP2Shell php-cgi izrecno zadeva.

**Kaj pomeni klasični CGI pri PHP?**  
Pri klasičnem CGI spletni strežnik za vsako zahtevo zažene nov proces PHP. To je počasno in danes redko. Pogosteje je php-cgi za mod_fcgid ali FastCGI, kjer procesi obdelajo več zahtev.

**Ali moram po posodobitvi kaj znova zagnati?**  
Da. Pri zgradbah FastCGI procesi php-cgi še nekaj časa tečejo. Znova zaženite spletni strežnik oziroma upravitelja procesov in preverite, da noben proces php-cgi ni starejši od posodobitve.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: podprte različice](https://www.php.net/supported-versions.php)
- [BSI (nemški zvezni urad za informacijsko varnost)](https://www.bsi.bund.de/)