Symfony закрыл обход access_control через HEAD и подмену входа по сертификату

4 ноября 2026 года команда безопасности Symfony раскрыла бюллетень из нескольких уязвимостей в компонентах HttpFoundation и Security, а на следующий день вышли патч-релизы 5.4.56, 6.4.50, 7.4.23 и 8.1.11. Независимо от официального анонса детали и CVSS-оценки задокументированы в базе OSV — расхождений в описании механики уязвимостей между источниками нет.

Для команды, которая ведёт PHP-проект на Symfony не эпизодически, а на постоянной основе, подобные бюллетени — рутинная часть цикла: откатить security-патч в проекте, где разработку проекта под ключ ведёт одна и та же команда, обычно быстрее, чем там, где между правками проект передаётся от подрядчика к подрядчику и история решений теряется.

HEAD обходил access_control (CVE-2026-118514)

Уязвимость с CVSS 6.3 — это уже вторая, неполная попытка закрыть проблему: первый фикс выходил как CVE-2026-45075, но и он не учёл все сценарии. Суть в том, что RequestMatcher и MethodRequestMatcher сравнивали HTTP-метод запроса с конфигурацией буквально, а сам роутер Symfony по правилам HTTP обслуживает HEAD-запрос тем же обработчиком, что и GET. В результате конфигурация вида:

• access_control: - { path: ^/admin, roles: ROLE_ADMIN, methods: [GET] }

корректно отклоняла GET /admin без роли, но пропускала HEAD /admin: контроллер отрабатывал полностью, а правило доступа просто не применялось к этому методу. Фикс делает поведение симметричным: если в списке методов есть GET, Symfony теперь автоматически добавляет туда и HEAD — и для RequestMatcher, и для MethodRequestMatcher, и в HttpFoundation, и в firewall-конфигурации Security.

Подмена входа по сертификату (CVE-2026-118513)

Вторая уязвимость серьёзнее: CVSS 7.7, authentication bypass by spoofing в X509Authenticator и X509AuthenticationListener. Если приложение аутентифицирует пользователей по клиентскому TLS-сертификату и берёт идентификатор пользователя из поля CN (Common Name) сертификата, то любой, кто получил сертификат от того же доверенного CA с контролируемым значением CN, мог аутентифицироваться как произвольный пользователь приложения, включая привилегированного. Для организаций с собственным CA и mTLS-доступом (внутренние панели, B2B-интеграции, VPN-порталы на базе Symfony) это прямой обход авторизации, а не теоретический сценарий.

Что ещё в этой партии патчей

В тот же релизный цикл вошли и другие исправления, которые стоит проверить по журналу изменений:

• CVE-2026-121623 — уязвимость высокой серьёзности в компоненте Serializer, затрагивает версии до 5.4.56, 6.4.50, 7.4.23 и 8.1.11
• CVE-2026-118516 — компоненты Routing по-разному интерпретируют host и path в запросе, из-за чего правило авторизации, привязанное к пути, можно обойти, подобрав несовпадающую трактовку хоста

Что проверить прямо сейчас

• Обновить symfony/http-foundation и symfony/security-http до 5.4.56, 6.4.50, 7.4.23 или 8.1.11 — патч один для всех поддерживаемых веток, отдельного обходного конфига нет
• Если в проекте есть access_control или firewall-правила с methods: [GET] (без явного HEAD) — после обновления перепроверить, что HEAD-запрос к этому же пути действительно получает отказ
• Если приложение использует X509Authenticator для входа по сертификату — убедиться, что привязка пользователя не опирается только на CN из сертификата, выданного общим для всех клиентов CA
• Проверить правила маршрутизации, которые завязаны на host — паттерн, описанный в CVE-2026-118516, легко пропустить при ревью, если тестировать только по пути без вариаций заголовка Host

Четыре CVE в одном бюллетене, причём один из них — повторная попытка закрыть брешь, которую не добили в первый раз. Это лишний повод смотреть на security-рассылку фреймворка не раз в полгода, а на каждый минорный релиз. На проектах, где эту рассылку некому читать месяцами, подобные патчи залёживаются до тех пор, пока уязвимость не попадёт в чей-то сканер.