# Изключване на session.upload_progress: правилно и трайно

> session.upload_progress.enabled=0 правилно: къде важи стойността, как да я заключите срещу повторно включване и как да я проверите в уеб контекст.

Източник: https://phpsos.de/bg/blog/session-upload-progress-abschalten/  
Актуалност: 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

**Накратко:** Задайте `session.upload_progress.enabled=0` в php.ini, в пула на PHP-FPM или в конфигурацията на сървъра Apache, никога чрез `ini_set()` или `.user.ini`, и след това рестартирайте всички PHP worker процеси. Мярката става трайна едва когато стойността е заключена срещу повторно включване, важи във всеки режим на работа и всяка инсталирана версия на PHP и се проверява отново след актуализации.

## Малка настройка с двойно действие

Рядко отделна настройка на PHP е получавала толкова внимание. Когато php.net публикува на 21 октомври 2026 г. пачовете срещу PHP2Shell, `session.upload_progress.enabled=0` беше в списъка с преходни мерки. Два дни по-късно последва съобщението за CVE-2026-115560 и препоръчаната мярка беше същата настройка.

Много администратори я зададоха бързо в тези дни. Дали действа навсякъде, е друг въпрос. Типичните пропуски се изброяват бързо: стойността стои само в конфигурацията на CLI, забравена е втора версия на PHP или хостинг панел е презаписал файла при следващото запазване. Тази статия показва как да приложите мярката така, че да важи и след три месеца.

Важно предварително: изключването не замества актуализацията на PHP. Според специализирани доклади само `session.upload_progress.enabled=0` не затваря и двете уязвимости на PHP2Shell. Какво точно засяга CVE-2026-115560, обяснява страницата [CVE-2026-115560: указание за session upload progress](https://phpsos.de/bg/php2shell/cve-2026-115560/).

## Какво прави функцията и кой я използва

Session upload progress записва по време на качване на файл непрекъснато напредъка в сесията, за да може приложението да покаже лента за напредък. В PHP функцията е включена по подразбиране. Самото ръководство на PHP сочи, че при това изпратените от подателя имена на файлове и полета попадат непроверени в хранилището на сесиите, и препоръчва функцията да се изключи, ако приложението не я използва.

Дали Вашето приложение я използва, откривате с чисто четящо търсене в кода:

```bash
# Търси използване на функцията за напредък в кода на приложението
grep -rn --include="*.php" -e "upload_progress" -e "PHP_SESSION_UPLOAD_PROGRESS" /var/www/
```

Ако търсенето не намери нищо, можете да изключите функцията без осезаеми последици. Ако има попадения, приложението губи само показването на напредъка, не качването. Съвременните формуляри така или иначе измерват напредъка обикновено в браузъра.

## Задаване на session.upload_progress.enabled на правилното място

Според ръководството на PHP настройката е в режим `INI_PERDIR`. Това означава: може да се задава в php.ini, в конфигурацията на сървъра, в `.htaccess` (само mod_php) и в `.user.ini` (само FPM и CGI), но не по време на изпълнение. php.net изрично изключва `.user.ini` като място за мярката. Следната таблица показва подходящите места за всеки режим на работа.

| Режим на работа | Препоръчително място | Заключва ли срещу презаписване? | След това рестартирайте |
|---|---|---|---|
| PHP-FPM | файл на пула с `php_admin_flag` | да | всяка услуга FPM |
| PHP-FPM | php.ini на FPM SAPI | не, `.user.ini` може да презапише | всяка услуга FPM |
| Apache с mod_php | VirtualHost или конфигурация на сървъра с `php_admin_flag` | да | Apache изцяло |
| php-cgi, LiteSpeed, FrankenPHP | php.ini на съответната среда за изпълнение | проверете според структурата | всички процеси на средата |
| Docker образ | собствен файл в `/usr/local/etc/php/conf.d/` при изграждането | да, ако не е позволено презаписване | създайте контейнера наново |

Двата устойчиви варианта изглеждат така:

```ini
; PHP-FPM, напр. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[session.upload_progress.enabled] = off
```

```apache
# Apache с mod_php, във VirtualHost или за целия сървър
<IfModule php_module>
    php_admin_flag session.upload_progress.enabled off
</IfModule>
```

Допълнително си струва записът в php.ini на всеки уеб SAPI като базова стойност. Тогава настройката важи и за нови пулове, които някой създаде по-късно. Защо `php_admin_flag` прави разликата, описва статията [php_admin_value: заключване на настройки срещу презаписване](https://phpsos.de/bg/blog/php-admin-value-sperren/).

## Проверка на действието в уеб контекст

Командният ред често чете друг php.ini от уеб сървъра. Затова `php -i` доказва малко. И `php-fpm8.3 -i` показва само стойностите от php.ini, не записите от пуловете. Надеждна е само заявка, която действително минава през пула.

Постъпете така:

1. Рестартирайте всички PHP услуги, например `systemctl restart php8.3-fpm` или Apache при mod_php. Без рестартиране старата стойност продължава да работи.
2. Поставете в уеб корена кратък проверочен файл със случайно име, който извежда само текущата стойност.
3. Извикайте файла веднъж през истинския домейн и запишете резултата.
4. Изтрийте файла веднага и повторете стъпката за всеки сайт и всеки пул.

```php
<?php
// Проверочен файл: поставете го само за кратко, после го изтрийте веднага
header('Content-Type: text/plain');
echo 'session.upload_progress.enabled = ', var_export(ini_get('session.upload_progress.enabled'), true), "\n";
echo 'PHP ', PHP_VERSION, ' / SAPI ', PHP_SAPI, "\n";
```

Очаква се празна стойност или `'0'`. Ако там стои `'1'`, Вашата настройка не действа в този пул. След актуализация на PHP проверете допълнително дали всички worker процеси са рестартирани, както е описано в [Рестартиране на PHP-FPM и на всички worker процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/).

> **Важно:**
> Никога не оставяйте проверочни файлове. Те издават версии и конфигурация и са популярна цел на автоматизирани сканирания.

## За да остане настройката трайно

Повечето връщания назад възникват не от атакуващи, а от експлоатацията. Нов пул се копира от стар шаблон, актуализация на пакет създава нов php.ini или някой сменя версията на PHP в хостинг панела. Срещу такива връщания помагат устойчиви навици.

- **Покрийте всички версии:** на много сървъри работят успоредно няколко версии на PHP. Всяка има собствени конфигурационни папки и се нуждае от записа.
- **Адаптирайте шаблоните:** шаблоните на пулове, ролите на Ansible, Dockerfile файловете и шаблоните на панела съдържат стойността, за да я наследяват автоматично новите сайтове.
- **Използвайте настройките на панела:** в хостинг панелите стойността принадлежи в предвидените от панела допълнителни директиви, иначе следващата промяна презаписва ръчната работа.
- **Проверявайте след актуализации:** проверката от предишния раздел принадлежи в контролния списък на всяка актуализация на PHP.
- **Документирайте:** запишете дата, сървър, пулове и резултат. Това помага по-късно пред ръководството, застрахователя или проверяващите.

Който изобщо не използва `.user.ini`, може да изключи изцяло четенето на такива файлове с `user_ini.filename =` в php.ini. Това засяга обаче всички настройки, които приложенията съхраняват там. Затова тествайте тази стъпка предварително, особено при CMS, които пишат собствени файлове `.user.ini`.

Останалите преходни мерки на php.net, например лимитите за `post_max_size` и лимита на паметта чрез cgroup, са събрани в [Незабавни мерки, когато още не можете да пачнете](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/). Как PHP подрежда принципно нивата на конфигурация, обяснява [php.ini обяснен](https://phpsos.de/bg/php/php-ini-erklaert/).

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

- **Отчитане на наличното:** установяваме всички версии на PHP, режими на работа и пулове на Вашите сървъри и прочитаме действащите стойности в уеб контекст.
- **Чисто задаване:** вписваме настройката заключена в пуловете и в конфигурацията на сървъра и рестартираме контролирано всички worker процеси.
- **Тест на функциите:** след прехода проверяваме формулярите за качване и управлението на медия.
- **Предотвратяване на връщане назад:** адаптираме шаблони, внедрявания и настройки на панела и документираме състоянието в рамките на [заздравяването на сървъра](https://phpsos.de/bg/leistungen/server-haertung/).


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

**Защо session.upload_progress.enabled=0 не действа през ini_set()?**  
Според ръководството на PHP настройката е в режим INI_PERDIR. Затова изобщо не може да се променя по време на изпълнение чрез ini_set(). php.net посочва като правилни места php.ini, пула на FPM или конфигурацията на сървъра и изрично изключва .user.ini.

**Работят ли качванията на файлове след изключването?**  
Да. Изключва се само съобщението за напредъка, което PHP записва в сесията по време на качване. Самото качване продължава. Засегнати са само приложения, които изграждат лентата си за напредък точно чрез тази функция на PHP.

**Може ли приложение да включи функцията отново?**  
През файл .htaccess при mod_php или през .user.ini при PHP-FPM това по принцип е възможно, докато стойността не е заключена. С php_admin_flag в пула или в конфигурацията на Apache го предотвратявате.

**Трябва ли да върна стойността след следващата актуализация на PHP?**  
Не, не е нужно. Функцията не е необходима на повечето приложения, а ръководството на PHP само съветва да се изключва в такива случаи. След всяка актуализация проверявайте само дали стойността още важи.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [Ръководство на PHP: конфигурация на сесии](https://www.php.net/manual/en/session.configuration.php)
- [Ръководство на PHP: файлове .user.ini](https://www.php.net/manual/en/configuration.file.per-user.php)