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.
# 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.
# 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.
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.
; 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. 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.
- A szerver-megerősítés 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.