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

> Уязвимост в php-cgi (PHP2Shell): как да намерите CGI и FastCGI конфигурации, да ги пачнете, да прекратите стари процеси и да планирате прехода към PHP-FPM.

Източник: https://phpsos.de/bg/server/php-cgi/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** 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. Пътищата и имената на модулите са примери.

```bash
# Работещи 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 ги прекратява.

```bash
# Пълен рестарт на 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](https://phpsos.de/bg/server/windows-iis-php/).

> **Действайте веднага:**
> Ако php-cgi работи с PHP 8.1 или по-стар на публично достъпен сървър, официален пач липсва. Задайте незабавно временните мерки и обмислете по препоръка на BSI (Федерална служба за информационна сигурност на Германия) сървърът да се изключи временно от мрежата.

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

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

```ini
; 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](https://phpsos.de/bg/server/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](https://phpsos.de/bg/leistungen/php-migration-legacy/).
- В рамките на [укрепването на сървъри](https://phpsos.de/bg/leistungen/server-haertung/) заместваме php-cgi с PHP-FPM с отделни пулове.


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

**Ползвам ли php-cgi, без да го знам?**  
Това е по-често, отколкото се мисли. По-стари панели, FastCGI конфигурации с mod_fcgid и PHP под Windows с IIS често стартират PHP като php-cgi. Списък на процесите или Server API в phpinfo го показват надеждно.

**Едно и също ли са FastCGI и php-cgi?**  
Не съвсем. FastCGI е протокол. И PHP-FPM, и php-cgi могат да говорят FastCGI, но php-cgi е по-старата, по-проста програма без пулове и управление на процесите. PHP2Shell засяга изрично php-cgi.

**Какво означава класически CGI при PHP?**  
При класическия CGI уеб сървърът стартира нов PHP процес за всяка заявка. Това е бавно и днес рядко се среща. По-често се среща php-cgi зад mod_fcgid или FastCGI, където процесите обработват няколко заявки.

**Трябва ли да рестартирам нещо след актуализацията?**  
Да. При FastCGI конфигурациите php-cgi процесите продължават да работят известно време. Рестартирайте уеб сървъра, респективно мениджъра на процесите, и проверете дали няма php-cgi процес, по-стар от актуализацията.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: Поддържани версии](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)