Praegune olukord: PHP2Shell. Kaks kriitilist PHP turvaauku (CVSS 9,2) lubavad kahjulikku koodi ilma sisselogimata. Paigad alates 21.10.2026.Mida nüüd teha →

php-cgi: riskantne vanapärand

php-cgi peidab end sageli märkamatult vanades seadistustes, paneelides ja Windowsis. Nii leiate selle, paigate pärast PHP2Shelli ja planeerite ülemineku PHP-FPM-ile.

Seis Lugemisaeg 4 minServer ja majutus

Lühidalt: php-cgi on vanim viis PHP-d veebiserveri taga käitada ja töötab veel paljudes serverites, sageli märkamatult. PHP2Shelli php-cgi turvaauk puudutab just seda töörežiimi. Paigake, lõpetage kõik töötavad php-cgi protsessid ja planeerige üleminek PHP-FPM-ile.

Mis on php-cgi ja kus see veel töötab

PHP-d on mitmes variandis: käsurea programmina, Apache'i moodulina, PHP-FPM-ina ja php-cgi-na. php-cgi on programm, mille veebiserver käivitab ja millele ta annab päringud edasi CGI või FastCGI kaudu. Ilma oma protsessihalduseta on see PHP-FPM-ist lihtsam, kuid ka vähem kontrollitav.

Tüüpilised leiukohad on vanemad majutuspaneelid, Apache koos mod_fcgid-iga, oma ümbrisskriptid (wrapper) mitme PHP versiooni jaoks ning PHP Windowsis koos IIS-iga FastCGI kaudu. Agentuurides ja asutustes leidub lisaks servereid, mis on aastaid tagasi seadistatud ja sestsaadik vaid käitatud.

php-cgi turvaauk PHP2Shelli puhul

PHP2Shell hõlmab PHP-s endas olevaid turvauke CVE-2026-109618 ja CVE-2026-109619, kumbki hindega CVSS v4.0 9,2. Mõlemad võimaldavad kahjuliku koodi käivitamist ilma sisselogimata. PHP projekt nimetab php-cgi selgesõnaliselt mõjutatud töörežiimide hulgas, PHP-FPM-i, mod_php, FrankenPHP ja LiteSpeedi kõrval.

Parandatud on PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. PHP 8.1 ja vanemate jaoks ametlikke uuendusi enam ei ole, on vaid minimaalsed lähtekoodi tagasiportimised versioonidele 7.4, 8.0 ja 8.1. Just php-cgi seadistused töötavad keskmisest sagedamini vanadel versioonidel. Lisaks ei ole php-cgi mõjutatud esimest korda: juba 2024. aastal tekitas Windowsi php-cgi turvaauk (CVE-2024-4577) suurt tähelepanu. Seda liiki vanapärand väärib seetõttu erilist tähelepanu.

Leidke php-cgi serverist üles

Järgmised käsud ainult loevad ja aitavad php-cgi üles leida. Teekonnad ja moodulinimed on näited.

# Töötavad php-cgi protsessid koos käivitusaja ja kasutajaga
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Installierte php-cgi-Programme
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: kas mod_fcgid või mod_cgi on laaditud?
apache2ctl -M 2>/dev/null | grep -Ei 'fcgid|cgi'
grep -RniE 'FcgidWrapper|AddHandler.*php|Action.*php' /etc/apache2 /etc/httpd 2>/dev/null

Kui leiate FcgidWrapper kirjeid või käsitlejaid, mis viitavad php-cgi programmile, töötab see töörežiim. Kontrollige iga leitud programmi versiooni võtmega -v. Distributsioonipakettide puhul tõendab paika CVE-numbritega muudatuslogi, sest backportid ei muuda versiooninumbrit sageli.

Paigake ja lõpetage kõik protsessid

Paigaldage uuendus paketihalduse kaudu või allikast, millest php-cgi pärineb. Seejärel peavad kõik töötavad php-cgi protsessid kaduma. mod_fcgid puhul hoiab Apache protsesse mõnda aega ootel; Apache'i täielik taaskäivitus lõpetab need.

# Apache täielikult uuesti käivitada (Debian/Ubuntu või RHEL-i perekond)
systemctl restart apache2   # või: systemctl restart httpd

# Kontroll: kas on veel php-cgi protsesse, mis on uuendusest vanemad?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Kui php-cgi töötab oma protsessihalduri või paneeliteenuse kaudu, käivitage see uuesti. Windowsis koos IIS-iga taaskäitage rakendusepoolid (application pool), vt PHP Windowsis ja IIS-is.

Tegutsege kohe

Kui php-cgi töötab PHP 8.1 või vanemaga avalikult kättesaadavas serveris, puudub ametlik paik. Seadke kohe ajutised meetmed ja kaaluge BSI soovituse kohaselt serveri ajutist võrgust lahtiühendamist.

Ajutised meetmed php-cgi puhul

php.net soovitab ajutisi meetmeid, mis ei paku täielikku kaitset. php-cgi puhul kuuluvad väärtused php.ini-sse, mille vastav programm laadib, või serveri seadistusse. .user.ini failidest ja ini_set()-ist sätte session.upload_progress.enabled jaoks php.net-i järgi ei piisa.

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

Üleslaadimisfunktsiooniga nimetab php.net post_max_size = 32M. PHP 8.5 puhul lisandub fatal_error_backtraces=0. Mälupiirangud seadke veebiserveri teenuse jaoks cgroupide kaudu, mitte RLIMIT_AS või RLIMIT_DATA abil. Seejärel käivitage kõik protsessid uuesti.

Tee PHP-FPM-ini

Pikemas perspektiivis ei ole php-cgi hea valik. PHP-FPM pakub poole iga veebisaidi kohta, oma kasutajaid, piire poolide kaupa, olekulehti ja kontrollitud taaskäivitusi. Üleminek on enamasti hästi planeeritav: paigaldada PHP-FPM, luua poolid, seadistada veebiserver FastCGI kaudu PHP-FPM-ile ja eemaldada ümbrisskriptid. Kuidas näeb välja korralik ülesehitus, näitab leht Nginx ja PHP-FPM turvamine. Kui lisaks töötab vana PHP versioon, siduge vahetus versiooniuuendusega.

Kuni üleminekuni peaksite olemasolevat seadistust kriitiliselt üle vaatama. Veebiserver peaks andma php-cgi-le edasi ainult laiendiga .php faile ja mitte teekondi, mis viitavad olematutele failidele. Üleslaadimiskataloogides ei tohi PHP käivitamine olla võimalik. Ümbrisskriptid, mis laadivad iga veebisaidi jaoks oma php.ini, kontrollige selle suhtes, kas need failid tühistavad ajutised väärtused uuesti. Kui php-cgi programm asub otse avalikult kättesaadavas kataloogis, nagu cgi-bin, tuleb see sealt eemaldada. Sellised vanapärandid pärinevad sageli möödunud aastate paigaldusjuhenditest ja need lihtsalt unustatakse hilisemate ümberehituste käigus. Dokumenteerige iga leid koos teekonna ja otstarbega, et hilisem ümberehitus ei jätaks midagi kahe silma vahele.

Oluline on: paik ei eemalda pahavara, mis toodi sisse varem. Säilitage logid alates 20.10.2026.

Kuidas PHP SOS konkreetselt aitab?

  • Leiame php-cgi paigaldused, ümbrisskriptid ja käsitlejad ning seostame need veebisaitidega.
  • Paigame, lõpetame kõik vanad protsessid ja dokumenteerime seisu.
  • PHP 8.1 ja vanemate puhul planeerime koos teiega ülemineku toetatud PHP versioonile.
  • Serveri karastamise raames asendame php-cgi PHP-FPM-iga eraldi poolidega.

Korduma kippuvad küsimused

Kas ma kasutan php-cgi-d, ilma et teaksin?

See on sagedasem, kui arvata võiks. Vanemad paneelid, mod_fcgid-ga FastCGI seadistused ja PHP Windowsis koos IIS-iga käivitavad PHP sageli php-cgi-na. Protsesside loend või phpinfo Server API näitab seda usaldusväärselt.

Kas FastCGI on sama mis php-cgi?

Mitte päris. FastCGI on protokoll. PHP-FPM ja php-cgi oskavad mõlemad FastCGI-d, kuid php-cgi on vanem, lihtsam programm ilma poolide ja protsessihalduseta. PHP2Shell puudutab php-cgi-d selgesõnaliselt.

Mida tähendab klassikaline CGI PHP puhul?

Klassikalise CGI korral käivitab veebiserver iga päringu jaoks uue PHP protsessi. See on aeglane ja tänapäeval haruldane. Sagedasem on php-cgi mod_fcgid või FastCGI taga, kus protsessid töötlevad mitut päringut.

Kas pean pärast uuendust midagi uuesti käivitama?

Jah. FastCGI seadistustes jätkavad php-cgi protsessid mõnda aega tööd. Käivitage veebiserver või protsessihaldur uuesti ja kontrollige, et ükski php-cgi protsess poleks uuendusest vanem.

Allikad

Kohene kontakt

Iga tund loeb. Kirjutage meile kohe.

Kirjeldage lühidalt süsteemi, PHP versiooni ja tähelepanekut. Võtame teiega ühendust, selgitame olukorra välja ja töötame kaugtööna, kuni intsident on lõpetatud ja dokumenteeritud.

Kohene abi