# Незабавни мерки, когато още не можете да пачнете

> Обходно решение за уязвимостта в PHP PHP2Shell: временните мерки на php.net, зададени правилно, с техните граници и бележки за пътя към пача.

Източник: https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/  
Актуалност: 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 PHP2Shell може да намали риска, но не замества актуализацията. За целта php.net назовава твърди ограничения за паметта и качванията, изключване на Session Upload Progress и при PHP 8.5 `fatal_error_backtraces=0`. Ако и това не е възможно в кратък срок, BSI препоръчва уеб сървърът да се изключи временно от мрежата.

## Какво може да постигне едно обходно решение и какво не

Временните мерки на php.net трябва да затруднят условията, при които уязвимостите CVE-2026-109618 и CVE-2026-109619 могат да бъдат експлоатирани. Те изрично **не са пълна защита**. Уязвимостите са поправени само в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 или в потвърден backport на Вашия доставчик.

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

Затова заедно с обходното решение планирайте и актуализацията: кой я изпълнява, в кой прозорец за поддръжка и кой проверява след това, че всички worker процеси са рестартирани? Преход без крайна дата рискува да се превърне в постоянно състояние.

## Вариант 1: временно изключване на сървъра от мрежата

BSI обяви ниво на предупреждение 3 (оранжево) и препоръчва засегнатите уеб сървъри да се изключат временно от мрежата, когато актуализацията не е възможна веднага. Някои доставчици са го направили превантивно; това не означава, че тези сайтове са хакнати.

За много фирми недостъпността на магазина или портала е скъпа. Може да е разумна преценка: достъп само през VPN или от разрешени IP адреси, статична страница за поддръжка вместо PHP приложението или изключване на отделни, ненужни уебсайтове на сървъра. Колкото по-малко PHP е достъпен отвън, толкова по-малка е повърхността за атака.

Важно е решението да бъде взето съзнателно и да бъде записано: кой е решил кога сървърът да остане онлайн и с какви защитни мерки? Това помага по-късно пред застраховател, защита на данните и управители.

## Временните мерки на php.net

| Мярка | Стойност | Бележка |
|---|---|---|
| `memory_limit` | `-1`, без възможност за презаписване | ограничението на паметта се задава тогава чрез контейнер или cgroup |
| `post_max_size` | `8M` без качвания, `32M` с качвания | `upload_max_filesize` под него |
| Ограничение на паметта | чрез контейнер/cgroup | не чрез `RLIMIT_AS` или `RLIMIT_DATA` |
| `session.upload_progress.enabled` | `0` | в php.ini, пула или конфигурацията на сървъра, не чрез `ini_set()` или `.user.ini` |
| `fatal_error_backtraces` | `0` | само PHP 8.5 |

Настройката `session.upload_progress.enabled=0` е същевременно и средството за съобщената на 23 октомври уязвимост [CVE-2026-115560](https://phpsos.de/bg/php2shell/cve-2026-115560/).

## Правилно задаване на обходното решение за уязвимостта в PHP

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

**PHP-FPM, в пула** (напр. `/etc/php/8.3/fpm/pool.d/www.conf`):

```ini
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; само PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
```

**Apache с mod_php,** в конфигурацията на сървъра или във VirtualHost:

```apache
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

**Ограничение на паметта чрез cgroup,** тук чрез systemd за услугата FPM. Стойността нагласете според Вашия сървър:

```ini
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
```

След това рестартирайте всички worker процеси, иначе нищо от това не действа: `systemctl restart php8.3-fpm` или при mod_php Apache. Как да проверите, че не работи стар процес, е описано на страницата [Рестартиране на PHP-FPM и на всички worker процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/). Общото заздравяване на конфигурацията описва страницата [Как да конфигурирате php.ini сигурно](https://phpsos.de/bg/ratgeber/php-ini-sicher-konfigurieren/).

> **Важно:**
> След преминаването тествайте качванията и големите формуляри. Прекалено тясно `post_max_size` може да блокира поръчки, формуляри за кандидатстване или качване на медии. Това е причина да не отлагате актуализацията дълго.

## Допълнителни защитни слоеве

Web Application Firewall или виртуално пачване може да помогне като допълнителен слой. Cloudflare внедри защитни правила, но сама предупреждава, че правила само по данните от заявките не са достатъчни. Затова WAF е допълнение, а не заместител. Повече има на страницата [WAF и виртуално пачване](https://phpsos.de/bg/leistungen/waf-virtuelles-patching/).

Запазете освен това сървърните логове от 20 октомври нататък. Според съобщения в медиите първият опит за атака е наблюдаван още на 17 октомври; логовете са основата, ако по-късно трябва да изясните дали преди пача е станало нещо.

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

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


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

**Защитава ли обходното решение напълно от PHP2Shell?**  
Не. php.net изрично определя мерките като преходни, а не като пълна защита. Те намаляват риска, докато бъде внесена актуализацията. BSI препоръчва сървърите без пач да се изключат временно от мрежата.

**Мога ли да задам настройките чрез .htaccess или .user.ini?**  
За session.upload_progress.enabled php.net изрично изключва ini_set() и .user.ini. И за memory_limit важи: стойността трябва да е зададена така, че приложението да не може да я презапише. Това се постига в php.ini, във FPM пула с php_admin_value или в конфигурацията на сървъра на Apache.

**Достатъчна ли е Web Application Firewall като обходно решение?**  
Като допълнителен слой може да помогне. Cloudflare внедри защитни правила, но сама посочва, че правила само по данните от заявките не са достатъчни. WAF не замества нито актуализацията, нито временните мерки на сървъра.

**Какво правя, ако имам само споделен хостинг?**  
Тогава php.ini и рестартирането са при хостинг доставчика. Попитайте конкретно дали актуализацията е внесена или временните мерки са зададени и дали всички PHP процеси са рестартирани.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [BSI: Федерална служба за информационна сигурност](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)