# php-cgi: kockázatos régi örökség

> php-cgi sebezhetőség a PHP2Shell után: CGI- és FastCGI-beállítások megkeresése, javítás, az összes régi folyamat befejezése és az átállás tervezése a PHP-FPM-re.

Forrás: https://phpsos.de/hu/server/php-cgi/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A php-cgi a PHP webszerver mögötti üzemeltetésének legrégebbi módja, és még sok szerveren fut, gyakran észrevétlenül. A PHP2Shell php-cgi sebezhetősége kifejezetten érinti ezt az üzemmódot. Javítson, fejezze be az összes futó php-cgi folyamatot, és tervezze meg az átállást a PHP-FPM-re.

## Mi a php-cgi, és hol fut még

A PHP több változatban létezik: parancssori programként, Apache-modulként, PHP-FPM-ként és php-cgi-ként. A php-cgi olyan program, amelyet a webszerver indít, és amelynek CGI-n vagy FastCGI-n keresztül adja át a kéréseket. Saját folyamatkezelés nélkül egyszerűbb, mint a PHP-FPM, de kevésbé is irányítható.

A tipikus előfordulási helyek a régebbi tárhelypanelek, az Apache `mod_fcgid`-del, a több PHP-verzióhoz írt saját wrapper-szkriptek, valamint a PHP Windows alatt IIS-sel FastCGI-n keresztül. Ügynökségeknél és hivataloknál ezenkívül olyan szerverek is akadnak, amelyeket évekkel ezelőtt állítottak be, és azóta csak üzemeltetik őket.

## A php-cgi sebezhetősége a PHP2Shellnél

A PHP2Shell a CVE-2026-109618 és a CVE-2026-109619 rést jelöli magában a PHP-ban, mindkettő CVSS v4.0 9,2 értékű. Mindkettő kártékony kód bejelentkezés nélküli futtatását teszi lehetővé. A PHP-projekt kifejezetten az érintett üzemmódok között nevezi meg a php-cgi-t, a PHP-FPM, a mod_php, a FrankenPHP és a LiteSpeed mellett.

Javított a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A PHP 8.1-hez és a régebbiekhez már nincs hivatalos frissítés, csak minimális forráskód-backportok a 7.4, 8.0 és 8.1 verzióhoz. Éppen a php-cgi-s beállítások futnak átlagosnál gyakrabban régi verziókon. A php-cgi emellett nem először érintett: már 2024-ben feltűnést keltett egy php-cgi-rés Windows alatt (CVE-2024-4577). Az ilyen régi örökségek ezért különös figyelmet érdemelnek.

## A php-cgi megkeresése a szerveren

A következő parancsok csak olvasnak, és segítenek a php-cgi felkutatásában. Az útvonalak és a modulnevek példák.

```bash
# Futó php-cgi folyamatok indulási idővel és felhasználóval
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Telepített php-cgi programok
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: be van töltve az mod_fcgid vagy az 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
```

Ha `FcgidWrapper` bejegyzéseket vagy php-cgi programra mutató kezelőket talál, akkor ez az üzemmód fut. Minden talált programnál ellenőrizze a verziót a `-v` kapcsolóval. Disztribúciós csomagoknál a CVE-számokat tartalmazó változásnapló igazolja a javítást, mert a backportok a verziószámot gyakran nem változtatják.

## Javítás és az összes folyamat befejezése

Telepítse a frissítést a csomagkezelőn vagy abból a forrásból, ahonnan a php-cgi származik. Utána az összes futó php-cgi folyamatnak el kell tűnnie. Az `mod_fcgid` esetében az Apache egy ideig tartalékban tart folyamatokat; az Apache teljes újraindítása befejezi őket.

```bash
# Az Apache teljes újraindítása (Debian/Ubuntu, illetve RHEL-család)
systemctl restart apache2   # vagy: systemctl restart httpd

# Ellenőrzés: van-e még a frissítésnél régebbi php-cgi folyamat?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep
```

Ha a php-cgi saját folyamatkezelőn vagy panelszolgáltatáson keresztül fut, azt indítsa újra. Windows alatt IIS-sel az alkalmazáskészleteket (application pool) recycle-ölje, lásd [PHP Windows alatt és IIS](https://phpsos.de/hu/server/windows-iis-php/).

> **Azonnal cselekedjen:**
> Ha a php-cgi PHP 8.1-gyel vagy régebbivel fut egy nyilvánosan elérhető szerveren, hivatalos javítás nincs. Azonnal állítsa be az átmeneti intézkedéseket, és a BSI ajánlása szerint fontolja meg a szerver ideiglenes leválasztását a hálózatról.

## Átmeneti intézkedések php-cgi esetén

A php.net átmeneti intézkedéseket javasol, amelyek nem nyújtanak teljes védelmet. A php-cgi-nél az értékek az adott program által betöltött php.ini fájlba vagy a szerverkonfigurációba tartoznak. A `.user.ini` fájlok és az `ini_set()` a php.net szerint a `session.upload_progress.enabled` esetében nem elegendők.

```ini
; a php-cgi-telepítés php.ini fájlja
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
```

Feltöltési funkcióval a php.net `post_max_size = 32M` értéket nevezi meg. A PHP 8.5-nél ehhez jön a `fatal_error_backtraces=0`. A memóriakorlátokat cgroupokon keresztül állítsa be a webszerver-szolgáltatásra, ne a `RLIMIT_AS` vagy a `RLIMIT_DATA` segítségével. Utána indítsa újra az összes folyamatot.

## Az út a PHP-FPM felé

Hosszú távon a php-cgi nem jó választás. A PHP-FPM weboldalankénti poolokat, saját felhasználókat, poolonkénti korlátokat, állapotoldalakat és ellenőrzött újraindításokat kínál. Az átállás többnyire jól tervezhető: telepíteni a PHP-FPM-et, poolokat létrehozni, a webszervert FastCGI-ra állítani a PHP-FPM felé, a wrapper-szkripteket eltávolítani. Hogyan néz ki egy rendezett felépítés, azt mutatja a [Nginx védelme PHP-FPM-mel](https://phpsos.de/hu/server/nginx-php-fpm/). Ha emellett egy régi PHP-verzió is fut, kösse össze az átállást a verziófrissítéssel.

Amíg az átállás meg nem történt, kritikusan vizsgálja át a meglévő konfigurációt. A webszerver csak a `.php` végződésű fájlokat adja át a php-cgi-nek, a nem létező fájlokra mutató útvonalakat ne. A feltöltési könyvtárakban nem lehet lehetséges a PHP-futtatás. A weboldalanként saját php.ini fájlt betöltő wrapper-szkripteknél ellenőrizze, hogy ezek a fájlok nem oldják-e fel ismét az átmeneti értékeket. Ha egy php-cgi program közvetlenül egy nyilvánosan elérhető könyvtárban, például a `cgi-bin`-ben van, onnan el kell távolítani. Az ilyen régi örökségek gyakran korábbi évek telepítési útmutatóiból származnak, és a későbbi átalakításoknál egyszerűen elfelejtik őket. Dokumentáljon minden leletet útvonallal és céllal, hogy a későbbi átalakítás semmit ne hagyjon ki.

Fontos marad: a javítás nem távolítja el a korábban bejuttatott kártevőt. Őrizze meg a naplókat 2026. október 20-tól.

## Hogyan segít konkrétan a PHP SOS?

- Felkutatjuk a php-cgi-telepítéseket, a wrappereket és a kezelőket, és hozzárendeljük őket a weboldalakhoz.
- Javítunk, befejezzük az összes régi folyamatot, és dokumentáljuk az állapotot.
- A PHP 8.1-hez és a régebbiekhez Önnel együtt megtervezzük az [áttérést egy támogatott PHP-verzióra](https://phpsos.de/hu/leistungen/php-migration-legacy/).
- A [szerver-megerősítés](https://phpsos.de/hu/leistungen/server-haertung/) keretében a php-cgi-t PHP-FPM-mel váltjuk le, elkülönített poolokkal.


## Gyakori kérdések

**Használok php-cgi-t anélkül, hogy tudnék róla?**  
Ez gyakoribb, mint gondolná. A régebbi panelek, az mod_fcgid-es FastCGI-beállítások és a PHP Windows alatt IIS-sel a PHP-t gyakran php-cgi-ként indítják. A folyamatlista vagy a phpinfo Server API sora megbízhatóan megmutatja.

**A FastCGI ugyanaz, mint a php-cgi?**  
Nem egészen. A FastCGI egy protokoll. A PHP-FPM és a php-cgi is tud FastCGI-t beszélni, a php-cgi azonban a régebbi, egyszerűbb program poolok és folyamatkezelés nélkül. A PHP2Shell kifejezetten érinti a php-cgi-t.

**Mit jelent a klasszikus CGI a PHP-nél?**  
A klasszikus CGI-nál a webszerver minden kéréshez új PHP-folyamatot indít. Ez lassú, és ma ritka. Gyakoribb a php-cgi az mod_fcgid vagy a FastCGI mögött, ahol a folyamatok több kérést dolgoznak fel.

**A frissítés után kell valamit újraindítanom?**  
Igen. A FastCGI-beállításoknál a php-cgi folyamatok egy ideig tovább futnak. Indítsa újra a webszervert, illetve a folyamatkezelőt, és ellenőrizze, hogy egyetlen php-cgi folyamat sem régebbi a frissítésnél.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)