php-cgi: rizikinga sena našta

Trumpai: php-cgi yra seniausias būdas valdyti PHP už žiniatinklio serverio ir vis dar veikia daugelyje serverių, dažnai nepastebimai. PHP2Shell php-cgi pažeidžiamumas aiškiai liečia šį veikimo režimą. Pataisykite, užbaikite visus veikiančius php-cgi procesus ir suplanuokite perėjimą prie PHP-FPM.

Kas yra php-cgi ir kur jis dar veikia

PHP yra keliais variantais: kaip komandinės eilutės programa, kaip Apache modulis, kaip PHP-FPM ir kaip php-cgi. php-cgi yra programa, kurią paleidžia žiniatinklio serveris ir kuriai užklausas perduoda per CGI arba FastCGI. Be savo procesų valdymo ji paprastesnė nei PHP-FPM, bet ir sunkiau valdoma.

Tipinės vietos yra senesni hostingo skydeliai, Apache su mod_fcgid, savi apvalkalo scenarijai (wrapper) kelioms PHP versijoms ir PHP sistemoje Windows su IIS per FastCGI. Be to, agentūrose ir institucijose pasitaiko serverių, kurie buvo sukonfigūruoti prieš daugelį metų ir nuo tada tik eksploatuojami.

php-cgi pažeidžiamumas PHP2Shell atveju

PHP2Shell apima pažeidžiamumus CVE-2026-109618 ir CVE-2026-109619 pačiame PHP, kiekvienas su CVSS v4.0 9,2. Abu leidžia vykdyti kenkėjišką kodą be prisijungimo. PHP projektas php-cgi aiškiai nurodo tarp paveiktų veikimo režimų, greta PHP-FPM, mod_php, FrankenPHP ir LiteSpeed.

Ištaisyti PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. PHP 8.1 ir senesnėms versijoms oficialių atnaujinimų nebėra, yra tik minimalūs atgaliniai pataisų perkėlimai šaltinio kode 7.4, 8.0 ir 8.1. Būtent php-cgi sąrankos neįprastai dažnai veikia su senomis versijomis. php-cgi paveiktas ne pirmą kartą: dar 2024 m. pažeidžiamumas php-cgi sistemoje Windows (CVE-2024-4577) sukėlė didelį dėmesį. Todėl tokia sena našta nusipelno ypatingo dėmesio.

Raskite php-cgi serveryje

Toliau pateiktos komandos tik skaito ir padeda rasti php-cgi. Keliai ir modulių pavadinimai yra pavyzdžiai.

# Veikiantys php-cgi procesai su paleidimo laiku ir naudotoju
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Įdiegtos php-cgi programos
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: ar įkeltas mod_fcgid ar 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

Jei randate FcgidWrapper įrašų ar tvarkyklių, nukreipiančių į php-cgi programą, veikia šis režimas. Kiekvienai rastai programai patikrinkite versiją su -v. Distribucijų paketų atveju pataisą įrodo pakeitimų žurnalas su CVE numeriais, nes backport dažnai nepakeičia versijos numerio.

Pataisykite ir užbaikite visus procesus

Atnaujinimą įdiekite per paketų tvarkyklę arba šaltinį, iš kurio ateina php-cgi. Po to turi išnykti visi veikiantys php-cgi procesai. Naudojant mod_fcgid, Apache procesus kurį laiką išlaiko; visiškas Apache paleidimas iš naujo juos užbaigia.

# Visiškai paleiskite Apache iš naujo (Debian/Ubuntu arba RHEL šeima)
systemctl restart apache2   # arba: systemctl restart httpd

# Kontrolė: ar dar yra php-cgi procesų, senesnių už atnaujinimą?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Jei php-cgi veikia per atskirą procesų valdytoją ar skydelio tarnybą, paleiskite ją iš naujo. Sistemoje Windows su IIS perkraukite programų baseinus (recycle), žr. PHP sistemoje Windows ir IIS.

Pereinamosios priemonės su php-cgi

php.net rekomenduoja pereinamąsias priemones, kurios nesuteikia visiškos apsaugos. Su php-cgi reikšmės turi būti php.ini, kurį įkelia atitinkama programa, arba serverio konfigūracijoje. .user.ini failų ir ini_set() pasak php.net session.upload_progress.enabled atveju nepakanka.

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

Su įkėlimo funkcija php.net nurodo post_max_size = 32M. PHP 8.5 papildomai nustatoma fatal_error_backtraces=0. Atminties ribas nustatykite per cgroups žiniatinklio serverio tarnybai, o ne per RLIMIT_AS ar RLIMIT_DATA. Po to iš naujo paleiskite visus procesus.

Kelias į PHP-FPM

Ilgainiui php-cgi nėra geras pasirinkimas. PHP-FPM siūlo baseinus kiekvienai svetainei, atskirus naudotojus, ribas kiekvienam baseinui, būsenos puslapius ir kontroliuojamus paleidimus iš naujo. Perėjimą dažniausiai galima gerai suplanuoti: įdiegti PHP-FPM, sukurti baseinus, žiniatinklio serverį perjungti į FastCGI su PHP-FPM, pašalinti apvalkalo scenarijus. Kaip atrodo tvarkinga sąranka, rodo Nginx su PHP-FPM apsauga. Jei papildomai veikia sena PHP versija, perėjimą sujunkite su atnaujinimu.

Kol perėjimas neįvyko, esamą konfigūraciją turėtumėte kritiškai peržiūrėti. Žiniatinklio serveris turėtų perduoti php-cgi tik failus su plėtiniu .php, o ne kelius, nukreipiančius į neegzistuojančius failus. Įkėlimų kataloguose PHP vykdymas neturi būti įmanomas. Apvalkalo scenarijus, kurie kiekvienai svetainei įkelia savą php.ini, patikrinkite, ar tie failai neatšaukia pereinamųjų reikšmių. Jei php-cgi programa yra tiesiai viešai pasiekiamame kataloge, pavyzdžiui, cgi-bin, ją reikia iš ten pašalinti. Tokia sena našta dažnai kyla iš praėjusių metų diegimo instrukcijų ir vėlesnių pertvarkymų metu tiesiog pamirštama. Dokumentuokite kiekvieną radinį su keliu ir paskirtimi, kad vėlesnis pertvarkymas nieko nepraleistų.

Svarbu išlieka: pataisa nepašalina kenkėjiškos programinės įrangos, įterptos anksčiau. Išsaugokite žurnalus nuo 2026-10-20.

Kaip PHP SOS padeda konkrečiai?

• Surandame php-cgi diegimus, apvalkalus ir tvarkykles ir priskiriame jas svetainėms.
• Pataisome, užbaigiame visus senus procesus ir dokumentuojame būseną.
• PHP 8.1 ir senesnėms versijoms kartu su jumis planuojame perėjimą prie palaikomos PHP versijos.
• Pagal serverio sutvirtinimą php-cgi pakeičiame PHP-FPM su atskirais baseinais.

Dažni klausimai

Šaltiniai

• php.net: saugumo pranešimai
• PHP 8 ChangeLog
• php.net: palaikomos versijos
• BSI