Monitor vulnerabilities like this one. Sign up free to get alerted when software you use is affected.

Authentik Invitation Tokens Can Be Reused Across Different Flows

BIT-authentik-2022-23555 CVE-2022-23555 GHSA-9qwp-jf7p-vr7h
Summary

Certain versions of Authentik's invitation system can be exploited if an attacker knows the different invitation flow names. This can lead to unauthorized access to accounts. To protect against this, update to version 2022.11.4 or later, or use a workaround that involves adding fixed data to invitations or using a unique identifier for each flow.

What to do
  • Update authentik to version 2022.11.4.
Affected software
Ecosystem VendorProductAffected versions
Bitnami – authentik >= 2022.11.0, < 2022.11.4
Fix: upgrade to 2022.11.4
Original title
authentik vulnerable to Improper Authentication via invitation URL token reuse
Original description
authentik is an open-source Identity Provider focused on flexibility and versatility. Versions prior to 2022.11.4 and 2022.10.4 are vulnerable to Improper Authentication. Token reuse in invitation URLs leads to access control bypass via the use of a different enrollment flow than in the one provided. The vulnerability allows an attacker that knows different invitation flows names (e.g. `enrollment-invitation-test` and `enrollment-invitation-admin`) via either different invite links or via brute forcing to signup via a single invitation url for any valid invite link received (it can even be a url for a third flow as long as it's a valid invite) as the token used in the `Invitations` section of the Admin interface does NOT change when a different `enrollment flow` is selected via the interface and it is NOT bound to the selected flow, so it will be valid for any flow when used. This issue is patched in authentik 2022.11.4,2022.10.4 and 2022.12.0. Only configurations that use invitations and have multiple enrollment flows with invitation stages that grant different permissions are affected. The default configuration is not vulnerable, and neither are configurations with a single enrollment flow. As a workaround, fixed data can be added to invitations which can be checked in the flow to deny requests. Alternatively, an identifier with high entropy (like a UUID) can be used as flow slug, mitigating the attack vector by exponentially decreasing the possibility of discovering other flows.
Published: 16 Apr 2026 · Updated: 17 Apr 2026 · First seen: 17 Apr 2026