# Сигурност на Symfony след PHP2Shell: как да защитите проекти и worker процеси

> Защитете проекти на Symfony след PHP2Shell: проверете PHP с bin/console about, рестартирайте Messenger worker, контролирайте secrets, кеша и профайлъра.

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

**Накратко:** Сигурността на Symfony след PHP2Shell означава: пачнете PHP, рестартирайте всички процеси, включително Messenger worker, и после проверете secrets, кеша и профайлъра. Уязвимостта е в PHP, а не в Symfony; само актуализация на Symfony не я затваря.

## Защо PHP2Shell засяга всеки проект на Symfony

Symfony е основа на много фирмени приложения, API и портали и присъства освен това в системи като Shopware 6 и Contao. PHP уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват според екипа на PHP изпълнение на злонамерен код без вход в системата. Дали приложението е програмирано чисто, няма значение за това.

Екипът на PHP оценява риска при mod_php като най-висок, но са засегнати и PHP-FPM, php-cgi, FrankenPHP и LiteSpeed. Проектите на Symfony, които работят чрез Symfony Runtime с FrankenPHP или други постоянно работещи сървъри, се нуждаят след актуализацията от пълно рестартиране или нов образ.

## Сигурност на Symfony: проверка на версията на PHP и на процесите

`php bin/console about` показва версията на Symfony, средата, режима за дебъгване и версията на PHP за командния ред. Уеб заявките обаче вървят през PHP-FPM или сървър за приложения, а това може да е друга версия. Проверете и двата пътя или ги поискайте като потвърждение от оператора.

Поправените версии на оригиналния проект са 8.5.12, 8.4.27, 8.3.36 и 8.2.35; backport-овете на дистрибуциите често носят по-стари номера. Кои версии на PHP поддържа Вашата версия на Symfony, проверете според системните изисквания в документацията на symfony.com.

```bash
# Показване на средата, режима за дебъгване и версията на PHP
php bin/console about
# Messenger worker да приключат след текущото съобщение
php bin/console messenger:stop-workers
# Известни уязвимости в зависимостите
composer audit
```

Ако няколко инстанции работят зад load balancer или в контейнери, всяка отделна трябва да е пачната и рестартирана. Забравена инстанция продължава да обслужва част от заявките със стария PHP.

Messenger worker, cron команди и други фонови процеси зареждат PHP веднъж при стартиране. Докато не бъдат рестартирани, те работят със стария PHP в паметта. Мениджър на процеси трябва да ги стартира наново след спирането.

## Къде приложенията на Symfony са уязвими

| Място | Съдържание | Какво да проверите |
|---|---|---|
| `.env`, `.env.local`, `.env.local.php` | променливи на средата, често база данни и API ключове | не е достъпно в уеб корена, при подозрение сменете стойностите |
| `config/secrets/prod/` | шифровани secrets | частният ключ за декриптиране не принадлежи в хранилището |
| `public/` | коренна директория с `index.php` | допълнителни PHP файлове |
| `var/cache/prod/` | генериран контейнер и шаблони като PHP | при подозрение изтрийте и генерирайте наново |
| `var/log/` | протоколи | запазете |
| `config/packages/security.yaml` | защитни стени, роли, правила за достъп | неочаквани промени |

Кешът е подценявано скривалище. Symfony генерира там PHP файлове, които се зареждат при всяка заявка. Промяна в тези файлове не се забелязва в хранилището, защото кешът не е версиониран.

> **Важно:**
> В продукция трябва да са `APP_ENV=prod` и `APP_DEBUG=0`, а WebProfilerBundle не бива да е активен там. Публично достъпен профайлър на `/_profiler` издава конфигурация и данни от заявки.

## Административни зони, bundles и зависимости

Проектите на Symfony имат според изграждането собствени административни зони, често с bundles като EasyAdmin или Sonata. Проверете в `security.yaml` кои пътища изискват кои роли, а в базата данни – кой има тези роли. Административните пътища, които са нужни само вътрешно, трябва да са ограничени до познати мрежи на ниво уеб сървър.

Bundles и пакетите на Composer са чужд код със собствени уязвимости. `composer audit` показва известни проблеми; по-подробно има на страницата [Проверка на зависимостите на Composer за уязвимости](https://phpsos.de/bg/ratgeber/composer-abhaengigkeiten-pruefen/). Остарелите пакети са освен това най-честата причина надграждането на PHP в проекти на Symfony да трае по-дълго от планираното.

## Какво постига актуализацията на Symfony и какво не

Актуализация на компоненти на Symfony затваря грешки във фреймуърка. Тя не пачва PHP, не рестартира worker процеси, не подновява изтекли secrets и не премахва манипулиран кеш. Дали има признаци за атака, описва [Вече компрометиран ли съм?](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/). Тъй като няма потвърдени индикатори за компрометиране (IOC), помага преди всичко наблюдението на необичайно поведение, например неочаквани процеси или изходящи връзки.

Ако проектът се доставя като контейнер, новият PHP принадлежи в базовия образ. Изградете образа наново, дори и в кода нищо да не се е променило, и го разгърнете във всички среди. Поглед във Dockerfile показва кой базов образ се ползва; фиксиран стар таг иначе пречи новото изграждане изобщо да получи пачнатия PHP. Подробности има на страницата [Пачване на PHP в Docker контейнери](https://phpsos.de/bg/php2shell/docker-container-patchen/).

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

- Установяваме кой PHP ползват уеб, CLI и worker процесите на Вашия проект на Symfony и съпровождаме подреденото рестартиране.
- Запазваме логове от 20.10.2026 г. нататък и сравняваме кода на сървъра с Вашето хранилище.
- Проверяваме файловете на средата, secrets, кеша, настройките на профайлъра и админ ролите.
- За текущото наблюдение на процеси и връзки предлагаме [мониторинг на сигурността](https://phpsos.de/bg/leistungen/security-monitoring/).


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

**Засегнат ли е Symfony от PHP2Shell?**  
Самият Symfony няма нова уязвимост. PHP2Shell е в PHP, т.е. в средата за изпълнение на всяко приложение на Symfony. Уязвимостта се затваря чрез актуализация на PHP или потвърден backport и рестартиране на всички PHP процеси.

**Как спирам Messenger worker след актуализация на PHP?**  
С php bin/console messenger:stop-workers работещите worker процеси получават указание да приключат след текущото съобщение. Мениджър на процеси като Supervisor или systemd след това ги стартира наново с новия PHP.

**Защо профайлърът на Symfony е опасен в продукция?**  
Профайлърът показва заявки, конфигурация и често променливи на средата. Ако е активен на публичен сървър, всеки може да извика тази информация. Той принадлежи само в средата за разработка.

**Какво се случва с кеша след атака?**  
Кешът под var/cache съдържа генериран PHP код. Нападател може да остави там код, който се изпълнява при всяка заявка. При подозрение кешът трябва да се изтрие и да се генерира наново от проверения изходен код.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [Symfony](https://symfony.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [Поддържани версии на PHP](https://www.php.net/supported-versions.php)