By combining AI with human insight, Armis Vulnerability Intelligence Database offers extended coverage for vulnerabilities that matter to you, your industry, and provides you with clear remediation instructions.
Loading CVE list…
CVE Name
Severity Score
Published Date
CISA KEV
New from Armis
Armis Pulse
One CVE. Every day. Curated by Armis researchers and delivered to your inbox or RSS reader.
See everything.Identify true risk.Proactively mitigate threats.Book a Demo
Let's talk!
CVE-2026-110801:
Loading CVE details…
CVE-2026-110801 | Critical Severity | Armis
CVE-2026-110801:
Summary
ZITADEL’s hosted Login V1 UI allowed an unauthenticated attacker to create a user account bound to an arbitrary external identity provider (IdP) identity without completing authentication at that IdP. By submitting forged identity fields to the “external account not found” registration endpoint, an attacker could pre-create an account for a victim’s public external user ID (for example a GitHub numeric user id). The victim’s later genuine “Sign in with …” then logged into that pre-created account.
Impact
An attacker who can reach a Login V1 authentication flow can:
Create a user account without a real IdP login, when the selected IdP allows manual account creation
Bind that account to an attacker-chosen external IdP identity (IDPConfigID + ExternalUserID)
Pre-hijack a victim’s future first-time external login when the victim’s external user ID is known or guessable
This affects applications that authenticate users through ZITADEL’s hosted Login V1 UI (OIDC/SAML) with at least one external IdP that allows manual account creation.
Scope note: This issue affects Login V1 only. Login V2 uses a cryptographically bound IdP intent and is not affected by this registration path.
Affected Versions
Systems running one of the following versions are affected:
4.x:4.0.0 through 4.16.1 (including RC versions)
3.x:3.0.0 through 3.4.13 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. Login V1 now requires verified external user data from a completed IdP callback (authReq.LinkingUsers) before creating an account, and no longer trusts identity or verification flags from the registration form body alone.
The recommended solution is to upgrade to a patched version.
If an immediate upgrade is not possible:
Disable Account creation allowed (manually) on each configured external IdP. This blocks the vulnerable registration path, but also disables legitimate self-service account creation via that IdP.
Automatic creation is not affected: it runs only after a verified IdP callback and uses server-side external user data. Automatic creation with manual creation disabled avoids the vulnerable path, but changes onboarding (users are created immediately after IdP login, without the review/edit step). If both manual and automatic creation are enabled, the manual path remains exposed.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to
Michael Wollner from Deutsche Telekom AG (@Ibonok) for reporting the vulnerability.
Adam Korczynski from Ada Logics (@AdamKorcz) for reporting the issue with the help of Anthropic.
Score
A numerical rating that indicates how dangerous this vulnerability is.
9.1Critical
Published Date:Jul 29, 2026
CISA KEV Date:*No Data*
Industries Affected:20
Exploitability
Score:3.9
Attack Vector:NETWORK
Attack Complexity:LOW
Privileges Required:NONE
User Interaction:NONE
Scope:UNCHANGED
Impact
Score:5.2
Confidentiality Impact:HIGH
Integrity Impact:HIGH
Availability Impact:NONE
Description Preview
Summary
ZITADEL’s hosted Login V1 UI allowed an unauthenticated attacker to create a user account bound to an arbitrary external identity provider (IdP) identity without completing authentication at that IdP. By submitting forged identity fields to the “external account not found” registration endpoint, an attacker could pre-create an account for a victim’s public external user ID (for example a GitHub numeric user id). The victim’s later genuine “Sign in with …” then logged into that pre-created account.
Impact
An attacker who can reach a Login V1 authentication flow can:
Create a user account without a real IdP login, when the selected IdP allows manual account creation
Bind that account to an attacker-chosen external IdP identity (IDPConfigID + ExternalUserID)
Pre-hijack a victim’s future first-time external login when the victim’s external user ID is known or guessable
This affects applications that authenticate users through ZITADEL’s hosted Login V1 UI (OIDC/SAML) with at least one external IdP that allows manual account creation.
Scope note: This issue affects Login V1 only. Login V2 uses a cryptographically bound IdP intent and is not affected by this registration path.
Affected Versions
Systems running one of the following versions are affected:
4.x:4.0.0 through 4.16.1 (including RC versions)
3.x:3.0.0 through 3.4.13 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. Login V1 now requires verified external user data from a completed IdP callback (authReq.LinkingUsers) before creating an account, and no longer trusts identity or verification flags from the registration form body alone.
The recommended solution is to upgrade to a patched version.
If an immediate upgrade is not possible:
Disable Account creation allowed (manually) on each configured external IdP. This blocks the vulnerable registration path, but also disables legitimate self-service account creation via that IdP.
Automatic creation is not affected: it runs only after a verified IdP callback and uses server-side external user data. Automatic creation with manual creation disabled avoids the vulnerable path, but changes onboarding (users are created immediately after IdP login, without the review/edit step). If both manual and automatic creation are enabled, the manual path remains exposed.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to
Michael Wollner from Deutsche Telekom AG (@Ibonok) for reporting the vulnerability.
Adam Korczynski from Ada Logics (@AdamKorcz) for reporting the issue with the help of Anthropic.
Industries Affected
Below is a list of industries most commonly impacted or potentially at risk based on intelligence.
