EUVD-2026-43010Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N
Any authenticated low-privilege account (PR:L) can inject over the network with low complexity; forged signed attributes give I:H, and the trust boundary crossed to relying SPs justifies S:C with A:N.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's self-hosted SAML application IdP built the signed SAML response and assertion by string-substituting user-controlled profile attributes such as name, email, and custom attribute-mapping values into element-text placeholders of a SAML XML template using samlify 2.10.0, which left those placeholders unescaped. An authenticated low-privilege user could place XML markup in a profile attribute so Logto signed a forged SAML attribute, such as an arbitrary role, allowing privilege escalation at relying Service Providers that authorize on SAML attributes. This issue is fixed in version 1.41.0.
AnalysisAI
Privilege escalation in Logto's self-hosted SAML IdP (before 1.41.0) lets an authenticated low-privilege user forge signed SAML attributes such as roles, enabling elevated access at any relying Service Provider that authorizes on SAML attributes. Because user-controlled profile fields (name, email, custom attribute-mapping values) were string-substituted into an unescaped XML template via samlify 2.10.0, an attacker embeds XML markup that Logto then cryptographically signs as legitimate. Rated CVSS 8.5 with scope change; no public exploit identified at time of analysis, but the fix is confirmed in release v1.41.0 with a corresponding GitHub advisory and commit.
Technical ContextAI
The flaw lives in Logto's self-hosted SAML application acting as an Identity Provider, which uses the samlify 2.10.0 library to build SAML 2.0 responses and assertions. Rather than DOM-based XML construction with proper entity encoding, Logto substituted user-controlled profile attributes directly into element-text placeholders of a SAML XML template as raw strings, leaving them unescaped. This is a textbook CWE-91 (XML Injection / improper neutralization of XML) issue: because the injected markup is inserted before the assertion is signed, the forged XML nodes become part of the signed, trusted payload rather than being rejected as tampering. SAML relying parties inherently trust signed assertions, so any Service Provider mapping authorization decisions to SAML attributes (e.g., role, group, entitlement) will honor the attacker-forged values.
RemediationAI
Vendor-released patch: upgrade Logto to 1.41.0 or later, which is the fix released in https://github.com/logto-io/logto/releases/tag/v1.41.0 (code changes in PR https://github.com/logto-io/logto/pull/9107 and commit 9097054860f0d638d90778d3dcde2ba050b844b6). If immediate upgrade is not possible, compensating controls include disabling the self-hosted SAML application IdP feature entirely (eliminates the injection path but breaks SAML SSO for downstream apps), and, at relying Service Providers, tightening authorization so it does not trust attacker-influenceable SAML attributes for role/entitlement decisions (reduces impact but may require SP-side config changes). You can also restrict who can register accounts or edit profile attributes and audit existing profile/custom attribute values for embedded XML markup, though this is a partial mitigation only and does not fully close the flaw. Full details are in the vendor advisory GHSA-vfpw-vq44-4p63.
Same weakness CWE-91 – XML Injection (aka Blind XPath Injection)
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today