Накратко: Сигурността на 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.
# Показване на средата, режима за дебъгване и версията на 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 за уязвимости. Остарелите пакети са освен това най-честата причина надграждането на PHP в проекти на Symfony да трае по-дълго от планираното.
Какво постига актуализацията на Symfony и какво не
Актуализация на компоненти на Symfony затваря грешки във фреймуърка. Тя не пачва PHP, не рестартира worker процеси, не подновява изтекли secrets и не премахва манипулиран кеш. Дали има признаци за атака, описва Вече компрометиран ли съм?. Тъй като няма потвърдени индикатори за компрометиране (IOC), помага преди всичко наблюдението на необичайно поведение, например неочаквани процеси или изходящи връзки.
Ако проектът се доставя като контейнер, новият PHP принадлежи в базовия образ. Изградете образа наново, дори и в кода нищо да не се е променило, и го разгърнете във всички среди. Поглед във Dockerfile показва кой базов образ се ползва; фиксиран стар таг иначе пречи новото изграждане изобщо да получи пачнатия PHP. Подробности има на страницата Пачване на PHP в Docker контейнери.
Как помага PHP SOS конкретно?
- Установяваме кой PHP ползват уеб, CLI и worker процесите на Вашия проект на Symfony и съпровождаме подреденото рестартиране.
- Запазваме логове от 20.10.2026 г. нататък и сравняваме кода на сървъра с Вашето хранилище.
- Проверяваме файловете на средата, secrets, кеша, настройките на профайлъра и админ ролите.
- За текущото наблюдение на процеси и връзки предлагаме мониторинг на сигурността.
Често задавани въпроси
Засегнат ли е 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 код. Нападател може да остави там код, който се изпълнява при всяка заявка. При подозрение кешът трябва да се изтрие и да се генерира наново от проверения изходен код.