Источник: CERT/CC Vulnerability Notes, VU#780781 — https://kb.cert.org/vuls/id/780781
По данным CERT/CC Vulnerability Note VU#780781, Casdoor версий 2.362.0 и ниже затронут несколькими уязвимостями в управлении идентификацией и доступом. Общая проблема серьезная: Casdoor может принять аутентификационные данные, которым не должен доверять, а затем выдать на их основе сессии или токены.
Из-за этого меняется приоритет реагирования. Это не узкий баг в интерфейсе и не редкий сбой при входе. CERT/CC описывает слабые места в обработке SAML, привязке social-login, привязке аккаунтов и обмене токенов. Среди заявленных последствий — обход аутентификации, обход MFA, захват аккаунта, replay assertion, повышение привилегий между организациями и сложности с отзывом скомпрометированных токенов.
Casdoor — open-source IAM-платформа и шлюз Model Context Protocol для аутентификации, single sign-on и identity-сервисов с несколькими протоколами. Если она стоит перед реальными приложениями, сбой здесь находится выше по цепочке, чем многие другие защитные меры.
Что изменилось в VU#780781#
CERT/CC опубликовал VU#780781 28 мая 2026 года. Заметка охватывает Casdoor версий 2.362.0 и ниже и группирует несколько CVE вокруг одной плоскости управления: как Casdoor решает, можно ли доверять identity assertion, привязке входа или обмену токена.
Самые важные структурные проблемы связаны с SAML. По данным CERT/CC, Casdoor может извлекать X.509-сертификат из входящего SAML-сообщения вместо того, чтобы опираться на заранее настроенный доверенный сертификат Identity Provider. Если такое поведение доступно в конкретной установке, атакующий может подписать поддельные assertion ключом под своим контролем, а Casdoor сочтет их валидными.
Другие SAML-проблемы усиливают риск. В заметке сказано, что Casdoor может не проверять audience у assertion, сопоставлять SAML assertion с сессиями без защиты от replay, игнорировать временные границы assertion и обрабатывать unsolicited или устаревшие SAML-ответы без подтверждения, что они связаны с ранее выпущенным запросом. Проще говоря, система может принять assertion для не того сервиса, не в то время, больше одного раза или вне ожидаемого сценария входа.
CERT/CC связывает несколько этих недостатков с CVE-2026-9090, CVE-2026-9093, CVE-2026-9095, CVE-2026-9096 и CVE-2026-9098. Вывод в заметке прямой: эти слабые места могут позволить подделку или replay assertion, использование assertion между сессиями и обработку просроченных или unsolicited SAML-ответов.
Не-SAML проблемы тоже важны. CERT/CC описывает путь привязки social-login, который может обходить настроенные требования MFA. Также описана проблема привязки аккаунтов: пользователи могут сопоставляться по адресу email без проверки, подтвердил ли вышестоящий провайдер свой email claim. Эти находки связаны с CVE-2026-9091 и CVE-2026-9092.
У обмена токенов есть отдельный режим отказа. По данным CERT/CC, Casdoor проверяет подписи JWT, но не проверяет, что пользователь из токена относится к той же организации, что и целевое приложение. Также Casdoor не проверяет, активен ли JWT, используемый для обмена токена, и не проверяет, был ли токен отозван. Эти проблемы обмена токенов связаны с CVE-2026-9094 и CVE-2026-9097.
Почему этот кластер CVE важен#
Риск широкий, потому что IAM работает как множитель. Уязвимый identity provider может превратить одну слабость аутентификации в доступ ко многим подключенным приложениям. Поэтому оценивать эксплуатацию стоит не только по наличию эффектного proof-of-concept на внешнем endpoint. Более полезный вопрос: может ли атакующий взаимодействовать с интерфейсом аутентификации Casdoor так, чтобы попасть в эти потоки.
CERT/CC пишет, что атакующий, способный взаимодействовать с интерфейсом аутентификации Casdoor, может выдавать себя за пользователей, обходить MFA, подделывать и повторно использовать assertion, а также получать постоянный несанкционированный доступ. Этого достаточно, чтобы относиться к проблеме как к задаче security operations, а не только как к обновлению зависимости.
SAML-находки особенно опасны там, где SSO воспринимается как жесткая граница доверия. Если проверки audience, временных ограничений, связи с запросом, доверия к сертификату и защиты от replay слабы, привычная модель безопасности SAML ломается. Assertion перестает быть короткоживущим доказательством, привязанным к получателю, и становится больше похожим на повторно используемый артефакт входа.
Проблема с отзывом токенов бьет по операционной стороне иначе. Если администраторы не могут надежно аннулировать токен после компрометации, incident response слабеет. Отзыв — не декоративная функция. Это один из немногих рычагов у защитников после подозрения, что сессия или токен вышли из-под контроля.
Есть и риск для приватности. IAM-платформы обрабатывают identity-атрибуты, связи аккаунтов и отношения доступа. Путь к захвату или impersonation может раскрыть не только данные приложений. Он может показать, у кого к чему есть доступ, какие аккаунты связаны и какие организации или tenant используют одну identity-инфраструктуру.
Что проверить перед действиями#
Начните с экспозиции. Проверьте, использует ли ваша организация Casdoor, стоит ли версия 2.362.0 или ниже, доступна ли она недоверенным пользователям или внешним identity provider. Не останавливайтесь на публичном периметре. Внутренние IAM-сервисы тоже могут быть доступны подрядчикам, партнерам, скомпрометированным аккаунтам или federated IdP.
Затем проверьте, какие потоки включены. Заметка CERT/CC указывает на SAML, привязку social-login, привязку аккаунтов и обмен токенов. Если конкретный поток не используется, практическая экспозиция может быть уже, но это нужно подтвердить конфигурацией и логами, а не памятью.
Полезные операционные проверки:
- Найдите все экземпляры Casdoor и их версии.
- Проверьте, включена ли функциональность SAML service provider.
- Проверьте настроенные IdP: нет ли среди них неиспользуемых, отключенных, устаревших или контролируемых извне.
- Убедитесь, что MFA применяется ко всем путям входа и привязки, а не только к основному входу по паролю.
- Пересмотрите правила привязки аккаунтов, которые опираются на email claims от вышестоящих провайдеров.
- Подтвердите, помечают ли вышестоящие провайдеры email claims как verified и безопасно ли Casdoor учитывает это различие.
- Проверьте пути обмена токенов между организациями или tenant.
- Протестируйте, действительно ли отзыв токена прекращает доступ в вашей установке.
- Ищите подозрительные SAML callbacks, повторяющиеся assertion, unsolicited responses или входы, которые обходят обычные MFA prompts.
Если проект или ваш канал поставки уже дает исправленную версию, следующий очевидный шаг — обновление. Но одним патчем ограничиваться не стоит. Эти недостатки затрагивают состояние аутентификации. Проверьте свежие логи доступа для администраторских аккаунтов, привилегированных пользователей и активности между организациями. Если есть подозрение на эксплуатацию, ротируйте связанные секреты, по возможности инвалидируйте сессии и проверьте подключенные приложения, которые доверяют сессиям или токенам, выпущенным Casdoor.
Open source security часто спотыкается на передаче от disclosure к эксплуатации в операционной работе. Полезный артефакт — не только список CVE. Важнее связка «уязвимость → включенная функция → доступный endpoint → доверенный IdP → срок жизни токена → поведение отзыва». Это тот же урок, что и в более широкой работе с security artifacts: инвентаризация и advisories помогают только тогда, когда превращаются в практические проверки. См. также: OpenSSF’s April signal: make security artifacts operational — https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
Чего не стоит утверждать без проверки#
CERT/CC описывает серьезные последствия, но исходный материал не доказывает, что каждая установка Casdoor экспонирована одинаково. Возможность эксплуатации зависит от включенных функций, конфигурации потоков аутентификации, отношений с IdP, сетевой доступности и того, может ли атакующий взаимодействовать с нужными интерфейсами.
Не предполагайте влияние SAML, если SAML не включен. Не предполагайте повышение привилегий между организациями, если установка не использует соответствующий паттерн обмена токенов. Не предполагайте захват аккаунта через email binding без проверки того, как вышестоящие провайдеры выпускают и подтверждают email claims.
Но и преуменьшать проблему из-за этих условий не стоит. Условная экспозиция — нормальная ситуация для IAM-уязвимостей. Правильная реакция — быстро снизить неопределенность: найти экземпляры, проверить версии, сопоставить потоки, установить патчи там, где применимо, и изучить признаки злоупотребления.
Самая сильная оценка, которую поддерживает VU#780781, такая: установки Casdoor на затронутых версиях требуют приоритетной проверки, если они служат центральным слоем входа. Когда identity control plane ошибается, нижестоящие защитные механизмы приложений могут даже не получить шанса сработать.