CVE-2026-105207: ZITADEL Account Takeover
TL;DR - CVE-2026-105207 is a critical, unauthenticated ZITADEL account-takeover vulnerability. - ZITADEL 3.0.0–3.4.15 and 4.0.0 before 4.17.3 are affected. - Upgrade to 4.17.3 or later and investigate unexpected external IdP links immediately.
Summary
CVE-2026-105207 is a critical authentication and authorization vulnerability in the ZITADEL identity and access-management platform. An attacker who knows a victim’s login name can associate the attacker’s own external identity-provider account with the victim’s ZITADEL account. The attacker can then use that linked identity to authenticate as the victim.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-105207 |
| CVSS score | 9.8 Critical |
| CVSS vector | Not included in the supplied NVD record; do not infer it |
| Attack vector | Network-based and remotely exploitable, based on the vulnerability description |
| Authentication required | None for the attacker |
| User interaction | Not required according to the described attack characteristics |
| Patch available | Yes |
| Fixed version identified | ZITADEL 4.17.3 |
| CISA KEV status | Not listed |
The affected workflows include identify-only Login V2 sessions and the User Service V2 AddIDPLink endpoint. This puts internet-facing ZITADEL instances at particular risk because login names may be exposed through normal authentication flows, account discovery, email formats, public directories, or organizational knowledge.
Organizations should also review identity and access-management controls surrounding connected services. For background on protecting credentials and service secrets, see the Kubernetes secrets management best practices glossary.
Root Cause
The root cause is insufficient authentication and authorization validation in the workflow that links an external identity-provider identity to an existing ZITADEL user account. The vulnerable logic can create the association without adequately confirming that the requester has completed a primary authentication factor or has permission to modify the target account.
The flaw affects more than a normal account-profile operation. An external IdP link can become a new authentication path to the account. If an attacker binds an IdP identity they control to a victim’s account, they may subsequently sign in as that victim without knowing the victim’s password or possessing the victim’s legitimate second factor.
The vulnerability is reported in both Login V2-related behavior and the User Service V2 AddIDPLink endpoint. Defenders should review browser-based login activity and API activity rather than assuming that disabling one login path eliminates exposure.
Technical Notes
The relevant operation is the creation of an external identity-provider link. The affected behavior is described around:
- Identify-only Login V2 sessions
- User Service V2
AddIDPLink - Missing verification of a primary factor
- Missing verification that the caller is authorized to modify the target account
The supplied records do not provide source-level function names, request schemas, or a complete CVSS vector. Avoid building detections around undocumented parameter names until the deployed ZITADEL version and API telemetry are confirmed.
Who’s Exposed
ZITADEL 3.0.0 through 3.4.15 is affected. The supplied record does not identify a fixed release for the 3.x branch. Organizations still operating this branch should not assume that a later 3.x version is safe unless the vendor explicitly confirms a backport or provides a supported upgrade path.
ZITADEL 4.0.0 through versions before 4.17.3 is also affected. The fixed version identified in the available record is 4.17.3. Treat deployments as exposed when they run any version in either affected range, whether they are self-hosted, containerized, orchestrated with Kubernetes, or placed behind a reverse proxy.
The highest-risk accounts include organization administrators, project owners, support users, developers, infrastructure operators, and service owners. Any account with access to privileged projects or administrative APIs should receive priority during post-remediation review.
Severity Breakdown
NVD assigns CVE-2026-105207 a CVSS 3.1 score of 9.8, Critical. The available description indicates a remotely exploitable condition that requires no attacker authentication and no victim interaction. Successful exploitation can lead directly to account takeover, making the practical impact substantially greater than a limited account-linking or profile-integrity issue.
The supplied NVD response does not include the CVSS vector string. The following characteristics are supported by the vulnerability description, but they are not a substitute for the authoritative vector:
| Characteristic | Assessment |
|---|---|
| Attack surface | Network-accessible application and API flows |
| Attacker authentication | Not required |
| Victim interaction | Not required based on the described attack |
| Required knowledge | Victim’s login name |
| Primary impact | Authentication bypass and account takeover |
| Confidentiality impact | Potentially high after account compromise |
| Integrity impact | Potentially high after account compromise |
| Availability impact | Not established from the supplied record |
Do not reconstruct or publish a CVSS vector from these characteristics. Validate the vector directly against the NVD entry or the vendor advisory if a precise component breakdown is required for risk registers or compliance reporting.
Analyst’s Take: The first response should be to upgrade affected 4.x deployments and obtain a supported remediation path for affected 3.x deployments. Because the flaw can turn an external IdP link into an authentication path, review existing links and active sessions at the same time. The absence of a verified public proof of concept or CISA KEV listing does not remove the need to investigate privileged accounts first.
Exploitation Status
No verified public proof-of-concept repository was identified in the reviewed material. The available GitHub reference is the vendor-maintained security advisory, not evidence of a working exploit. Unrelated ZITADEL issues, release discussions, or other vulnerability references should not be counted as proof of exploitation for this CVE.
Confirmed exploitation in the wild was not established. CVE-2026-105207 is not currently listed in the CISA Known Exploited Vulnerabilities catalog, so there is no CISA catalog confirmation of active exploitation. KEV absence is not proof that exploitation has never occurred, and the vulnerability remains urgent because the attack can create an attacker-controlled authentication path to a known account.
Sources
The primary reference is the NVD record for CVE-2026-105207, which identifies the affected ranges, CVSS score, vulnerability description, and 4.17.3 fix boundary.
The vendor-maintained ZITADEL GitHub Security Advisory GHSA-g8gj-gq47-xgf4 provides the product-specific advisory reference. Additional context is available from VulnCheck’s advisory and the ZITADEL documentation. Validate version support, upgrade sequencing, and deployment-specific commands against current vendor documentation before production changes.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Detection should focus on unexpected external identity-provider links, especially links created for existing users without a corresponding successful primary authentication event. Review ZITADEL audit and authentication telemetry for the account-linking operation, the AddIDPLink service method, Login V2 identify-only activity, and subsequent successful logins through a newly linked IdP.
Prioritize events where the linking request originates from an unfamiliar IP address, user agent, ASN, geography, or device; where the linked IdP identity has not previously appeared in the organization; or where the target account is privileged. Correlate link creation with password changes, MFA changes, session creation, administrative API calls, and changes to organization or project membership.
Technical Notes
The exact ZITADEL audit event schema and field names depend on the deployment version and logging configuration. Start with a query that searches raw logs for the documented operation and related terms, then map the result to your SIEM’s normalized fields:
("AddIDPLink" OR "add idp link" OR "IDP link" OR "external identity provider")
AND (
"Login V2"
OR "identify-only"
OR "User Service V2"
)
A second useful correlation is a newly created external link followed by authentication from the linked provider within a short interval:
event.action IN ("AddIDPLink", "external_idp_link_created")
| correlate target.user.id, linked.idp.subject
within 30m
| where subsequent event.action IN ("login_success", "session_created")
These examples are detection logic, not guaranteed event names. Confirm the actual audit records in a test environment and preserve the source request, target user, linked provider, actor identity, source IP, user agent, timestamp, and result status.
Remediation Steps
Upgrade affected 4.x deployments to ZITADEL 4.17.3 or later. Prefer the latest vendor-supported release rather than stopping at the minimum fixed version. For affected 3.x deployments, obtain vendor guidance for a supported upgrade or security backport because the supplied record does not identify a fixed 3.x release.
For a container deployment using the official ZITADEL image, pin the workload to the fixed image tag through the deployment system rather than relying on a floating tag. For example, after validating the image registry and deployment name used by the organization:
docker pull ghcr.io/zitadel/zitadel:v4.17.3
Kubernetes operators should update the image through their normal declarative manifest or Helm values, then verify the running version:
kubectl -n <namespace> set image deployment/<deployment-name> \
<container-name>=ghcr.io/zitadel/zitadel:v4.17.3
kubectl -n <namespace> rollout status deployment/<deployment-name>
The registry path, namespace, deployment name, and container name must match the organization’s deployment. Do not execute the example unchanged without confirming those values and the vendor’s supported upgrade procedure.
Before and after upgrading, review external IdP links created during the vulnerable period. Remove links that the account owner cannot explain, force revocation of active sessions for potentially compromised accounts, and reset credentials or authentication factors where compromise is plausible. Prioritize administrator and high-privilege accounts.
For teams reviewing credential hygiene after a potential identity compromise, a reputable password manager such as Try 1Password → can help enforce unique credentials and safer recovery practices. This does not replace patching, session revocation, or investigation of unauthorized IdP links.
If an immediate upgrade is not possible, restrict administrative and user-service API exposure at the network layer, require access through a trusted application gateway or VPN where feasible, and monitor or temporarily disable external IdP-linking workflows if the deployment supports that control. These measures are compensating controls only and do not correct the authorization defect.
Technical Notes
A practical remediation validation sequence is:
# Confirm the deployed application image or package version
kubectl -n <namespace> get deployment/<deployment-name> \
-o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'
# Confirm rollout completion
kubectl -n <namespace> rollout status deployment/<deployment-name>
# Review recent workload events for startup or migration failures
kubectl -n <namespace> get events --sort-by=.lastTimestamp
After the upgrade, test that an external IdP link cannot be created without the required primary authentication and authorization context. Perform this only in a controlled test tenant or staging environment using test identities.
For additional guidance on identity-related service exposure, review the webhook security FAQ when evaluating connected authentication and automation workflows.