Skip to main content

Logto CVE-2026-55789

| EUVDEUVD-2026-43010 HIGH
XML Injection (aka Blind XPath Injection) (CWE-91)
2026-07-10 security-advisories@github.com
8.5
CVSS 3.1 · Vendor: github
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate as low-privilege Logto user
  2. Delivery
    Inject XML markup into profile attribute
  3. Exploit
    Initiate SAML login to relying SP
  4. Execution
    Logto signs forged assertion with elevated role
  5. Impact
    SP 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

logto < 1.41.0

Affected Packages

euvd logto fix: 1.41.0

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

Vendor (github) PRIMARY 8.5 HIGH
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N
vuln.today AI 8.5 HIGH

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.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
High
Availability
None

Lifecycle Timeline

1
Patch available
Jul 10, 2026 - 21:02 EUVD

DescriptionCVE.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

Why It Matters

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.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.3%
Top 78% exploitable
Prevalence
Low
open-source auth platform; self-hosted SAML IdP is a niche subset
Data Quality
6 sources
Confidence: High

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Partial

Priority Score

42
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +42
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy