CVE-2026-63182 in LightSAML
Сводка
по VulDB • 30.10.2026
LightSAML реализует классы модели данных SAML 2.0, сериализацию и десериализацию XML, безопасность XML, поддержку сертификатов и привязки сообщений. До версий 4.7.1 и 5.0.1 LightSAML и xmlseclibs расходятся во мнениях относительно того, какую именно assertion охватывает входящая подпись SAML. `Response::deserialize` использует метод `manyElementsFromXml` для сбора только прямых дочерних элементов `saml:Assertion` из `samlp:Response`, а `AssertionSignatureValidatorAction` проверяет их `ds:Signature` с использованием доверенных учетных данных IdP, разрешаемых по Issuer (извне документа), а не ключа из самого документа. `XMLSecurityDSig::validateReference()` удаляет enveloped signature из общего DOM-дерева, однако `processRefNode()` разрешает URI ссылки в виде `#id` во всем документе с помощью XPath вида `//*[@Id]` и выбирает первый элемент (`item(0)`), который не обязательно является той assertion, чьи утверждения потребляет LightSAML. Атакующий, захвативший одну подлинно подписанную assertion (например, ответ на предыдущую аутентификацию), может поместить ее байты без подписи ранее в `samlp:Extensions` и представить поддельный прямой дочерний элемент с тем же ID и скопированной действительной подписью. В результате проверка охватывает скрытые подлинные данные, тогда как LightSAML предоставляет не подписанные атакующим контролируемые значения для `Subject/NameID`, `Conditions` и `Attributes`, что позволяет обойти аутентификацию или повысить привилегии даже при требовании проверки подписи. Поведение подтверждено в версиях 5.0.0 и 4.6.1. Проблема исправлена в версиях 4.7.1 и 5.0.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.