What is the CVSS score of CVE-2026-47201?

CVE-2026-47201 has a CVSS 3.1 base score of 8.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of authentik are affected by CVE-2026-47201?

A high-severity authentication bypass in authentik's SAML source endpoint (CVE-2026-47201, CVSS 8.5) enables attackers with valid accounts at federated identity providers to impersonate other users…. A patch is available.

How to fix or mitigate CVE-2026-47201?

24 hours: Identify all systems running authentik and verify which deployments use SAML Source with federated IdPs. 7 days: Apply available vendor patch for CVE-2026-47201 to all affected authentik instances. 30 days: Complete production deployment verification and audit SAML assertion logs for anomalous impersonation patterns within the past 30 days.

authentik CVE-2026-47201

EUVD-2026-34027 HIGH

Improper Authentication (CWE-287)

2026-05-29 https://github.com/goauthentik/authentik

GHSA-c3m2-jqmq-pvp3

Authentication Bypass

8.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.5 HIGH

AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 29, 2026 - 20:50 vuln.today

Analysis Generated

May 29, 2026 - 20:50 vuln.today

DescriptionGitHub Advisory

Summary

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.

Patches

authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue.

Impact

Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation.

The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker's original signed assertion while authentik reads identity data from a different forged assertion.

An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes.

The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled.

Workarounds

Disable affected SAML Sources, or block access to their ACS endpoints.

For more information

If there are any questions or comments about this advisory:

Send an email to [security@goauthentik.io](mailto:security@goauthentik.io)

AnalysisAI

Authentication bypass in authentik's SAML Source ACS endpoint allows an attacker holding any account at a trusted upstream IdP to impersonate other federated users via XML Signature Wrapping (XSW). The flaw stems from the signature verifier not binding the validated signature to the assertion subsequently consumed for identity data, so a crafted response can present a legitimately signed assertion for signature checks while a separate forged assertion supplies the victim identifier. No public exploit identified at time of analysis, but the upstream commit (a370d76) and detailed XSW3-style test fixtures make the technique transparent to anyone reading the patch.

Technical ContextAI

authentik is an open-source identity provider written primarily in Python/Go (pkg:go/goauthentik.io) that can federate to upstream SAML 2.0 IdPs through its SAML Source. The vulnerable code path lived in authentik/sources/saml/processors/response.py, where _verify_signature() called xmlsec.tree.add_ids() on the entire document root and then verified the first <Signature> node it found, without ensuring that the signed element's ID actually matched the Assertion or Response later consumed. This is a textbook CWE-287 / XML Signature Wrapping issue (a known class of attack against xmlsec/lxml-based SAML stacks): the XML Digital Signature spec permits a Reference URI to point to any element with a matching ID, so an attacker can embed a validly signed assertion in a sibling/ancestor location while injecting an unsigned 'evil' assertion that the application logic actually parses. The fix introduces a per-target verification: the Reference URI must be empty or equal to '#<target ID>', exactly one Reference is permitted, and xmlsec IDs are now registered only on the target element rather than the whole tree.

RemediationAI

Vendor-released patch: upgrade to authentik 2026.5.1, 2026.2.4, or 2025.12.6, whichever matches your release train, per advisory GHSA-c3m2-jqmq-pvp3 (https://github.com/goauthentik/authentik/security/advisories/GHSA-c3m2-jqmq-pvp3); the underlying fix is commit a370d76d23c7de0fceed064ca322e33e6ebf0119, which binds each verified XML signature to a specific target element by Reference URI and registers xmlsec IDs only on that target. If immediate patching is not possible, the vendor-recommended workarounds are to disable the affected SAML Sources in the authentik admin interface, or to block external access to their ACS endpoints (e.g., via reverse-proxy or WAF rules) - both will break upstream SAML federation for end users until the patch is applied, so plan for an authentication outage or fall back to another configured source. As an interim compensating control, restrict who can create or hold accounts at the upstream IdP, since exploitation requires the attacker to obtain a legitimately signed assertion from that IdP first, and audit the authentik SAML Source configuration to disable email/username matching modes if they are enabled, as these expand the impact to local users.