Критическая уязвимость в Angular Server-Side Rendering угрожает тысячам веб-приложений

В популярном фреймворке Angular обнаружена критическая уязвимость, позволяющая злоумышленникам осуществлять атаки типа Server-Side Request Forgery (SSRF, подделка межсайтовых запросов на стороне сервера) и Header Injection (внедрение заголовков). Проблема, получившая идентификатор CVE-2026-27739 и максимальную оценку опасности 10.0 по шкале CVSS v4, затрагивает механизм Server-Side Rendering (SSR, серверный рендеринг), который широко используется для повышения производительности и поисковой оптимизации веб-приложений. Суть уязвимости заключается в том, что злоумышленник может заставить серверное приложение выполнять несанкционированные запросы к внутренним или внешним ресурсам, что открывает путь к хищению учётных данных, сканированию внутренней сети и утечке конфиденциальных данных.

Детали уязвимости

Уязвимость имеет широкий охват, поскольку затрагивает несколько ключевых пакетов для реализации SSR: "@angular/ssr", "@nguniversal/common" и "@nguniversal/express-engine". Это означает, что под угрозой находятся тысячи приложений по всему миру, построенных на Angular. По данным разработчиков, корень проблемы лежит в логике реконструкции URL, которая некорректно обрабатывает контролируемые пользователем HTTP-заголовки. А именно, фреймворк слепо доверяет заголовкам "Host" и семейству "X-Forwarded-*" для определения базового источника приложения, не проводя проверки целевого домена.

Можно выделить три ключевые области, где отсутствовала необходимая валидация. Во-первых, заголовки "Host" и "X-Forwarded-Host" не проверялись на соответствие доверенным источникам. Это позволяло атакующему подменить базовый адрес приложения на адрес контролируемого им вредоносного внешнего домена. Во-вторых, для заголовка "X-Forwarded-Host" отсутствовали проверки на наличие сегментов пути или специальных символов, что давало возможность манипулировать базовым путём для относительных URL. В-третьих, заголовок "X-Forwarded-Port" не проходил строгой проверки на числовое значение, что могло привести к созданию некорректных URI и атакам с внедрением кода.

Механизм эксплуатации этой уязвимости позволяет злоумышленнику перенаправлять внутренние запросы приложения на произвольные адреса. Это становится возможным, когда "HttpClient" Angular разрешает относительные URL относительно непроверенного базового источника, или когда разработчики вручную конструируют URL, используя непроверенные заголовки. Последствия успешной атаки могут быть крайне серьёзными. Во-первых, возможно хищение учётных данных, таких как заголовки авторизации или файлы cookie сессии, путём перенаправления запросов на серверы, контролируемые злоумышленником. Во-вторых, атакующие получают возможность зондировать внутреннюю сеть, получая доступ к данным от внутренних сервисов, баз данных или конечных точек метаданных облачных провайдеров, которые не предназначены для публичного доступа. В-третьих, под угрозу попадает конфиденциальность любой информации, обрабатываемой в серверном окружении приложения.

Однако для успешной атаки необходимо соблюдение ряда условий. Целевое приложение должно использовать Angular SSR и задействовать "HttpClient" для работы с относительными URL или вручную строить URL на основе непроверенных заголовков. Кроме того, атакующий должен иметь возможность напрямую влиять на эти заголовки, что предполагает отсутствие строгой валидации на промежуточных прокси-серверах. Наконец, критичным фактором является отсутствие дополнительной проверки на уровне инфраструктуры, такой как облачные провайдеры, сети доставки контента или балансировщики нагрузки.

Разработчики Angular уже выпустили исправленные версии пакетов: 21.2.0-rc.1, 21.1.5, 20.3.17 и 19.2.21. Настоятельно рекомендуется немедленно обновить "@angular/ssr" до защищённой версии. Если срочное обновление невозможно, можно применить временные меры защиты. Эффективным решением является отказ от использования "req.headers" для построения URL и переход на абсолютные URL, основанные на доверенных, жёстко заданных переменных для базовых путей API. Дополнительно рекомендуется реализовать строгую проверку заголовков на уровне middleware в файле "server.ts", обеспечив проверку числовых значений портов и разрешённых имён хостов, чтобы взаимодействовать с сервером могли только одобренные домены.

В заключение, данная уязвимость демонстрирует классические риски, связанные с излишним доверием к пользовательскому вводу, даже на уровне HTTP-заголовков. Для команд разработки это служит важным напоминанием о необходимости реализации принципа наименьших привилегий и многоуровневой защиты. Помимо исправления в коде фреймворка, критически важной является настройка корректной валидации на всех уровнях инфраструктуры приложения, чтобы исключить возможность подобных атак в будущем. Своевременное обновление зависимостей остаётся одним из самых эффективных способов защиты от известных угроз.

Детали уязвимости

Ссылки