Разработчик дал Claude задачу проверить реализации корпоративного входа через SAML и за месяц нашёл уязвимости, которые позволяли входить в чужие учётные записи, раскрывать данные и выводить службы из строя. Часть обнаруженных проблем до сих пор не исправлена.
Технический директор Oblique Эрик Чианг проверил с помощью Claude Opus практически все реализации SAML, которые смог найти. Вместо подробных инструкций модели описали возможные угрозы и позволили самостоятельно искать необычное поведение библиотек, а затем объединять находки и проверять их рабочими примерами.
SAML используют для единого входа в корпоративные приложения. Слабым местом протокола давно остаётся то, как программы обрабатывают XML и цифровые подписи . Разные компоненты могут по-разному интерпретировать один документ. В результате программа проверяет подпись одной части сообщения, но затем доверяет данным из другой.
Claude обнаружил, что аутентификацию можно полностью обойти сразу в четырёх проектах: Authentik, LightSaml, OneUptime и Java-библиотеке saml-client. В Authentik уязвимость CVE-2026-57580 получила 8,7 балла из 10. Специально сформированный NameID с комментарием XML позволял связать внешнюю личность злоумышленника с существующей учётной записью и затем входить под именем жертвы без её пароля.
Проблема затрагивала Authentik до версий 2026.5.4 и 2026.2.5 включительно. Разработчики закрыли уязвимость в версиях 2026.5.5 и 2026.2.6. Чтобы использовать уязвимость, требовалась учётная запись у поставщика удостоверений и возможность задавать собственный NameID.
В PHP-библиотеке LightSaml обнаружили другой способ обойти проверку. Компоненты по-разному определяли, какой элемент XML защищает цифровая подпись. Злоумышленник мог использовать настоящую подписанную конструкцию, но заставить приложение принять поддельные сведения о пользователе. Ошибка затрагивала версии до 5.0.0 включительно и исправлена в 5.0.1.
Проверив основной механизм входа, Чианг переключился на менее изученные сообщения SAML. В двенадцати проектах нашлись способы обойти проверку подписей, когда система запрашивает аутентификацию, получает атрибуты или пользователь выходит из системы. Такие ошибки могли раскрывать информацию или принудительно завершать чужие сеансы. Один из примеров разработчик опубликовал для samlify.
Отдельный класс проблем связан с отказом в обслуживании. Многие SAML-библиотеки принимают произвольные XML-документы из интернета, поэтому специально подготовленный запрос способен резко увеличить расход памяти. Для Go уже исправили проблему в goxmldsig, из-за которой память могла расти квадратично. В библиотеках для Python и Node.js, по данным Oblique, часть подобных ошибок остаётся открытой. Для python3-saml и PySAML2 опубликованы отдельные отчёты о том, что ресурсы можно чрезмерно расходовать с помощью преобразований XSLT.
Чианг пришёл к выводу , что зрелые SAML-библиотеки стали заметно устойчивее к попыткам полностью обойти вход, но новые реализации продолжают повторять старые ошибки. Разработчикам он советует не создавать собственную реализацию SAML с нуля, а существующие решения дополнительно проверять автоматизированными средствами на известные классы ошибок.