php-cgi: наследство с риск

Накратко: php-cgi е най-старият начин да се ползва PHP зад уеб сървър и още работи на много сървъри, често незабелязано. Уязвимостта в php-cgi от PHP2Shell засяга изрично този режим на работа. Пачнете, прекратете всички работещи php-cgi процеси и планирайте прехода към PHP-FPM.

Какво е php-cgi и къде още работи

PHP има няколко варианта: като програма за командния ред, като модул на Apache, като PHP-FPM и като php-cgi. php-cgi е програма, която уеб сървърът стартира и на която предава заявки през CGI или FastCGI. Без собствено управление на процесите тя е по-проста от PHP-FPM, но и по-малко контролируема.

Типични места, където се намира, са по-стари хостинг панели, Apache с mod_fcgid, собствени скриптове-обвивки за няколко версии на PHP и PHP под Windows с IIS през FastCGI. В агенции и ведомства освен това има сървъри, които са настроени преди години и оттогава само се експлоатират.

Уязвимостта в php-cgi при PHP2Shell

PHP2Shell обхваща уязвимостите CVE-2026-109618 и CVE-2026-109619 в самия PHP, и двете с CVSS v4.0 9,2. И двете позволяват изпълнение на зловреден код без вход в системата. Проектът PHP изрично посочва php-cgi сред засегнатите режими на работа, наред с PHP-FPM, mod_php, FrankenPHP и LiteSpeed.

Коригирани са PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. За PHP 8.1 и по-стари вече няма официални актуализации, а само минимални бекпортове на изходния код за 7.4, 8.0 и 8.1. Именно конфигурациите с php-cgi работят над средното често на стари версии. php-cgi освен това не е засегнат за пръв път: още през 2024 г. уязвимост в php-cgi под Windows (CVE-2024-4577) предизвика сериозен отзвук. Наследство от този вид затова заслужава особено внимание.

Откриване на php-cgi на сървъра

Следващите команди само четат и помагат да се открие php-cgi. Пътищата и имената на модулите са примери.

# Работещи php-cgi процеси с време на стартиране и потребител
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Инсталирани php-cgi програми
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: зареден ли е mod_fcgid или 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

Ако намерите записи FcgidWrapper или манипулатори, сочещи към програма php-cgi, този режим на работа е в действие. За всяка намерена програма проверете версията с -v. При пакети на дистрибуции пачът се доказва с дневника на промените с номерата на CVE, защото бекпортовете често не променят номера на версията.

Пач и прекратяване на всички процеси

Внесете актуализацията чрез управлението на пакетите или източника, от който идва php-cgi. След това всички работещи php-cgi процеси трябва да изчезнат. При mod_fcgid Apache държи процесите известно време; пълният рестарт на Apache ги прекратява.

# Пълен рестарт на Apache (Debian/Ubuntu респективно семейство RHEL)
systemctl restart apache2   # или: systemctl restart httpd

# Проверка: има ли още php-cgi процеси, по-стари от актуализацията?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Ако php-cgi работи през собствен мениджър на процесите или услуга на панел, рестартирайте него. Под Windows с IIS рециклирайте пуловете на приложенията, вж. PHP под Windows и IIS.

Временни мерки при php-cgi

php.net препоръчва временни мерки, които не осигуряват пълна защита. При php-cgi стойностите принадлежат в php.ini, който зарежда съответната програма, или в конфигурацията на сървъра. Файловете .user.ini и ini_set() според php.net не са достатъчни за session.upload_progress.enabled.

; php.ini на инсталацията с php-cgi
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

При функция за качване php.net посочва post_max_size = 32M. При PHP 8.5 се добавя fatal_error_backtraces=0. Ограниченията на паметта задавате чрез cgroups за услугата на уеб сървъра, не чрез RLIMIT_AS или RLIMIT_DATA. След това рестартирайте всички процеси.

Пътят към PHP-FPM

В дългосрочен план php-cgi не е добър избор. PHP-FPM предлага пулове за всеки уебсайт, собствени потребители, ограничения за всеки пул, страници за състояние и контролирани рестарти. Преминаването най-често е добре планируемо: инсталиране на PHP-FPM, създаване на пулове, преминаване на уеб сървъра към FastCGI към PHP-FPM, премахване на скриптовете-обвивки. Как изглежда чистото изграждане, показва Как да обезопасите Nginx с PHP-FPM. Ако освен това работи стара версия на PHP, свържете смяната с надграждането.

Докато преминаването не е направено, преценявайте критично съществуващата конфигурация. Уеб сървърът трябва да предава на php-cgi само файлове с разширение .php и не пътища, които сочат към несъществуващи файлове. В директориите за качване не бива да е възможно изпълнение на PHP. Скриптовете-обвивки, които зареждат отделен php.ini за всеки уебсайт, проверете дали тези файлове не отменят отново временните стойности. Ако програма php-cgi стои директно в публично достъпна директория като cgi-bin, там тя трябва да се премахне. Такова наследство често идва от инструкции за инсталиране от минали години и при по-късни преустройства просто се забравя. Документирайте всяка находка с път и предназначение, за да не пропусне по-късното преустройство нищо.

Остава важно: пачът не премахва зловреден софтуер, внесен преди това. Запазете логовете от 20.10.2026 г. нататък.

Как помага PHP SOS конкретно?

• Откриваме инсталациите на php-cgi, скриптовете-обвивки и манипулаторите и ги свързваме с уебсайтовете.
• Пачваме, прекратяваме всички стари процеси и документираме състоянието.
• За PHP 8.1 и по-стари планираме заедно с Вас миграция към поддържана версия на PHP.
• В рамките на укрепването на сървъри заместваме php-cgi с PHP-FPM с отделни пулове.

Често задавани въпроси

Източници

• php.net: Съобщения за сигурност
• PHP 8 ChangeLog
• php.net: Поддържани версии
• BSI