Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege Logto user
-
DeliveryInject XML markup into profile attribute
-
ExploitInitiate SAML login to relying SP
-
ExecutionLogto signs forged assertion with elevated role
-
ImpactSP authorizes attacker as privileged user
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization XPath query parameterization
|
| Exploitation Conditions | Exploitation requires that Logto be deployed with the self-hosted SAML application IdP feature enabled and that at least one relying Service Provider authorizes based on SAML attributes (e.g., role, group). The attacker must hold an authenticated low-privilege Logto account (PR:L) and be able to set a profile attribute - name, email, or a custom attribute-mapping value - that flows into the SAML assertion template. Limiting factors: the SAML IdP feature must be in use (not a default for all deployments), the downstream SP must trust SAML attribute values for authorization, and the affected version must be below 1.41.0; no user interaction from a victim is needed. |
| Impact | The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N, score 8.5) aligns well with the described mechanics: remote, low-complexity, requiring only a low-privilege authenticated account, with high integrity impact and a scope change reflecting compromise of downstream Service Providers - a distinct trust boundary from Logto itself. There is no EPSS score, KEV listing, or POC provided, so exploitation likelihood cannot be quantified from the input; this appears to be a coordinated GitHub-reported disclosure (GHSA-vfpw-vq44-4p63) rather than an actively exploited bug. The real-world priority is elevated for organizations running Logto as a self-hosted SAML IdP with role/attribute-based SP authorization, because the barrier (any valid low-privilege account) is low and the payoff (arbitrary signed roles) is high; it is lower priority where the SAML IdP feature is not enabled or SPs do not authorize on SAML attributes. No signals conflict, but note the impact is realized at relying SPs, so blast radius depends on how downstream applications consume Logto assertions. |
| Exploit ScenarioDerived | A low-privilege user with a valid Logto account edits a profile attribute (such as display name or a custom attribute-mapping value) to embed SAML XML markup declaring an elevated role. When that user authenticates via SAML to a relying Service Provider, Logto substitutes and signs the assertion containing the forged attribute, and the SP grants admin-level access based on the trusted, signed role. No POC is provided in the input, but the attack requires no special tooling - only the ability to set a profile attribute value. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 10, 2026
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.
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.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity 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
1DescriptionCVE.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.
Executive ViewAI
Logto self-hosted SAML identity providers (versions before 1.41.0) contain a privilege escalation vulnerability allowing authenticated users to forge SAML attributes and escalate access at downstream applications that rely on SAML-based authorization. This directly impacts organizations where Logto manages federated authentication across multiple services, potentially allowing low-privilege users to assume administrative roles organization-wide. Immediate identification and patching is critical as this affects the core authentication and authorization trust boundary.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
EUVD-2026-43010
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB