CVE-2026-47201: authentik SAML XML Signature Wrapping Authentication Bypass
authentik, an open-source identity provider used to manage user authentication and authorization, contains a vulnerability in how it validates SAML responses from upstream identity providers. The flaw allows an attacker who has any valid account at an upstream IdP to reuse a legitimately signed authentication assertion to impersonate other federated users. This works because authentik doesn't properly validate XML signatures, making it vulnerable to XML Signature Wrapping attacks—a technique where attackers manipulate the structure of signed XML data without invalidating the signature itself. An attacker needs valid credentials at the upstream IdP but can then gain unauthorized access as arbitrary other users in systems relying on authentik for federation.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.5 HIGH · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
- Weaknesses (CWE)
- CWE-20, CWE-347
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-02 / 2026-06-17
NVD description (verbatim)
authentik is an open-source identity provider. Prior to versions 2025.12.5, 2026.2.3, and 2026.5.1, authentik's SAML Source ACS endpoint is vulnerable to XML Signature Wrapping when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user. This issue has been patched in versions 2025.12.5, 2026.2.3, and 2026.5.1.
1 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The vulnerability exists in authentik's SAML Source ACS (Assertion Consumer Service) endpoint, specifically in its validation of upstream SAML responses. The root cause is improper XML signature validation that fails to defend against signature wrapping attacks (CWE-347). In this attack class, an attacker modifies the XML document structure—such as by duplicating, reordering, or wrapping signed assertions—in ways that leave the cryptographic signature valid but alter which assertion the application processes. An authenticated attacker at the upstream IdP can craft a malicious SAML response containing a reused signed assertion from a legitimate authentication event, wrapped in a way that causes authentik to authenticate the attacker as a different user. The issue affects authentik versions prior to 2025.12.5, 2026.2.3, and 2026.5.1, depending on the release branch.
Business impact
Organizations using authentik as a federated identity provider face significant authentication bypass risk. Attackers with valid credentials at any upstream IdP (such as an external corporate identity provider or third-party SaaS directory) can escalate their access to impersonate any other federated user in downstream applications. This undermines the core trust model of federated identity—the assumption that a valid signature from an upstream provider correctly identifies the authenticated user. Potential consequences include unauthorized access to sensitive applications, data theft, lateral movement within federated environments, and compliance violations if authentication logs misattribute actions to impersonated users.
Affected systems
The vulnerability affects authentik prior to specific patched versions: 2025.12.5, 2026.2.3, and 2026.5.1. Organizations should identify which version branch they operate and determine if they are below the patched threshold. The vulnerability specifically impacts deployments using SAML federation with upstream identity providers. Organizations relying on authentik as a central identity broker—whether for SaaS application access, internal corporate systems, or multi-tenant platforms—should treat this as affecting their authentication layer unless they have already applied the relevant patch.
Exploitability
The vulnerability requires the attacker to possess valid credentials at the upstream IdP (PR:L in the CVSS vector), but the CVSS score of 8.5 reflects that exploitation is otherwise relatively straightforward once that prerequisite is met. The attack does not require user interaction (UI:N) and can be executed over the network (AV:N). The AC:H (high attack complexity) factor likely accounts for the specifics of crafting valid XML signature wrapping payloads, but this is well-understood in security research and tooling exists to automate such attacks. The scope is changed (S:C), meaning the attacker can affect confidentiality, integrity, and availability beyond the vulnerable component itself—specifically, they can impersonate other users and access their resources. This is not currently listed in the CISA KEV catalog, indicating either recent publication or lower observed exploitation in the wild; however, the attack surface and motivation for exploitation are clear.
Remediation
Organizations must apply patches immediately. Upgrade authentik to version 2025.12.5 if on the 2025.12.x branch, 2026.2.3 for the 2026.2.x branch, or 2026.5.1 for the 2026.5.x branch. Verify the correct target version against your current authentik deployment. If immediate patching is not possible, disable SAML federation or restrict upstream IdP access to trusted internal providers only, though this may significantly impact user workflow. Review recent authentication logs for anomalies—particularly failed SAML validation attempts or successful authentications for users from unexpected upstream IdPs—though note that successful signature wrapping attacks may not leave obvious audit traces if the attacker's reused assertion was originally valid.
Patch guidance
Apply the patches provided by goauthentik as soon as feasible. The fixes address the XML signature validation logic in the SAML Source ACS endpoint. After patching, verify the fix by confirming the authentik version matches the patched release and by testing SAML federation with upstream providers to ensure normal authentication flow remains functional. If you maintain a custom fork or deployment of authentik, review the upstream patch commits to understand the validation changes and apply equivalent fixes. Document patch deployment in your change management system and communicate updates to any downstream teams relying on authentik for authentication.
Detection guidance
Monitor authentik logs and SAML transaction logs for suspicious patterns: repeated failed SAML validation events, successful authentications where the assertion timestamp or issuer does not match normal patterns for that upstream IdP, or users successfully authenticating with assertions bearing timestamps significantly in the past. Implement alerting on anomalous federated login patterns, such as a user authenticated via one upstream IdP suddenly appearing with a different identity or elevated privileges. If SAML debugging is enabled, review XML structures of incoming assertions for signs of wrapping (duplicate assertions, unusual nesting, or reordered elements). Correlate authentik authentication events with upstream IdP logs to identify cases where the upstream provider has no corresponding login event for an assertion authentik accepted.
Why prioritize this
This vulnerability merits immediate priority because it directly compromises the authentication layer—the foundation of access control. The attack requires only valid upstream IdP credentials (not admin access or rare conditions) and can result in privilege escalation and unauthorized access to downstream systems. The CVSS 8.5 HIGH rating reflects the severity. Although currently not in the KEV catalog, the attack is deterministic, not requiring exploitation of race conditions or user interaction. Organizations with federated identity deployments should treat this as critical regardless of KEV status, as the business impact—user impersonation and authentication bypass—is severe.
Risk score, explained
The CVSS 3.1 score of 8.5 reflects: (1) network-accessible endpoint (AV:N); (2) legitimate user credentials required at upstream IdP (PR:L), elevating attack complexity; (3) no user interaction needed (UI:N); (4) scope change—the attacker can affect resources beyond the vulnerable component, specifically other federated users and downstream applications (S:C); and (5) full impact on confidentiality, integrity, and availability (C:H, I:H, A:H) through user impersonation. The AC:H factor acknowledges that crafting valid signature wrapping payloads requires technical sophistication, but this is not a barrier given existing research and tooling. The combination of network accessibility, scope expansion, and high impact justifies the HIGH severity rating.
Frequently asked questions
What is XML Signature Wrapping and why is it a problem in SAML?
XML Signature Wrapping exploits ambiguity in how signed XML is parsed and processed. An attacker modifies the structure of a signed SAML assertion (e.g., by wrapping it in additional XML elements or reordering sections) such that the cryptographic signature remains valid but a naive parser processes a different assertion than the one that was actually signed. In SAML federation, this means an attacker can reuse a legitimately signed assertion but manipulate its context so the identity provider accepts it as authenticating a different user. Proper defense requires validating not just the signature itself but also that the assertion being processed is the one that was actually signed.
Do I need upstream IdP credentials to exploit this, or can external attackers attack me?
Yes, the attacker needs valid credentials at the upstream identity provider (the IdP that authentik trusts). This is reflected in the CVSS PR:L (Privilege Required: Low). If your upstream IdP is public or externally accessible, an attacker can register an account and gain credentials. If your upstream IdP is internal-only (e.g., a corporate Active Directory accessible only to employees), the risk is limited to insider threats. Either way, this should be treated as urgent because the attack requires no additional privileges or special access beyond a normal user account.
How do I know if I've been exploited?
Successful XML Signature Wrapping attacks often leave minimal audit traces because the attacker reuses a legitimate signature from an earlier login. Review authentication logs for users appearing to log in from unexpected upstream IdPs, logins bearing assertion timestamps far in the past, or anomalous privilege escalations following federated logins. Correlate authentik audit logs with upstream IdP logs—if authentik shows a successful SAML login but the upstream IdP has no corresponding login event for that user at that time, signature wrapping may have occurred. After patching, monitor for any residual anomalies and consider a one-time review of recent authentication activity, though note that attribution may be difficult if logs have rotated.
Is there a temporary mitigation if I can't patch immediately?
The most effective interim control is to disable SAML federation entirely or restrict it to trusted internal upstream IdPs where you control access and can audit login events. This may significantly impact user workflow and is not a long-term solution. Alternatively, implement strict monitoring of SAML assertion timestamps and failed validation attempts, and require downstream applications to perform additional verification of user identity before granting elevated access. None of these replace patching; they are holding measures only.
This analysis is provided for informational and operational security purposes. The information herein reflects the CVE details, CVSS vector, and patch guidance as of the publication date. Verify all patch version numbers and affected product information against official goauthentik advisories and your deployed version before taking action. This document does not constitute legal advice. Organizations should perform their own risk assessment based on their specific deployment context, upstream IdP trust relationships, and downstream application criticality. Exploit code, detailed attack walkthroughs, and weaponized proof-of-concept demonstrations are not provided in this analysis. Consult official security advisories and your vendor support channels for deployment-specific guidance. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2025-22424HIGHAndroid Local Privilege Escalation via Image Disclosure
- CVE-2026-0078HIGHAndroid Privilege Escalation via DevicePolicyManagerService Desync
- CVE-2026-10020HIGHChrome Android Sandbox Escape via Skia Input Validation Flaw
- CVE-2026-10021HIGHGoogle Chrome USB Validation Flaw – RCE Vulnerability Patch
- CVE-2026-10863HIGHMISP Correlations Query Ordering Vulnerability (CVSS 8.1)
- CVE-2026-10904HIGHChrome V8 Sandbox Escape Remote Code Execution
- CVE-2026-10911HIGHChrome Sandbox Escape Vulnerability (High Severity)
- CVE-2026-10917HIGHChrome Media Sandbox Escape Vulnerability (High CVSS 8.3)