ZITADEL 1-Click XSS Enables Account Takeover | 2026

ZITADEL 1-Click XSS Enables Account Takeover | 2026

Executive Summary

ZITADEL disclosed CVE-2026-29191 in early March 2026, warning that versions 4.0.0 through 4.11.1 are vulnerable to a one-click cross-site scripting issue in the /saml-post endpoint that can lead to account takeover. According to the vendor advisory, an unauthenticated attacker can trick a victim into loading malicious JavaScript in the context of the ZITADEL login flow, then abuse that access to reset the victim’s password and seize the account.

For defenders, the real risk is not just one user session. Because ZITADEL sits in the Identity and Access Management layer, compromise of privileged or administrator identities can cascade into broader tenant, application, and operational impact. The confirmed fix is to upgrade to 4.12.0 or later and review whether exposed instances can still reach the vulnerable flow.

What happened?

ZITADEL’s GitHub security advisory says the vulnerable login V2 implementation exposed a /saml-post endpoint that accepted url and id parameters and automatically submitted a POST request to the supplied destination.

The issue had two dangerous properties:

• the endpoint insecurely redirected users based on attacker-controlled input
• the response reflected user input without proper HTML encoding
• both behaviors enabled Cross-Site Scripting in the victim’s browser
• exploitation required only that a target click a crafted link or otherwise load the malicious request once

Timeline

• 2026-03-04: GitLab advisory record for CVE-2026-29191 appears, referencing the underlying GitHub disclosure.
• 2026-03-09: Public reporting around the flaw expands, often describing it as a “1-click” takeover issue.
• Vendor confirmation: ZITADEL states the flaw affects 4.0.0 to 4.11.1, including RC builds.
• Patch guidance: ZITADEL says the issue is fixed in 4.12.0, where the SAML integration was reworked and the /saml-post endpoint no longer exists.

Why this matters beyond a single account

Some headlines describe this as a route to “entire system takeover.” That wording is more dramatic than the confirmed advisory, which explicitly describes account takeover. Still, that distinction matters less in practice when the affected product is the identity plane.

If an attacker takes over:

• a tenant administrator account
• a break-glass identity
• an account with privileged application bindings
• an account used to manage federation, login policy, or customer access

then the blast radius can extend far beyond one user. In identity infrastructure, Access Control failures often become platform-wide trust failures.

Who is affected?

Confirmed affected versions:

• ZITADEL 4.0.0 through 4.11.1
• release candidates in that line are also included in the advisory

Important detail from the vendor: although /saml-post is associated with SAML IdP handling, the vulnerability does not require a SAML IdP integration to be configured. ZITADEL says default out-of-the-box deployments can still be exposed.

That means the likely at-risk population includes:

• self-hosted ZITADEL deployments
• internet-exposed identity tenants using Login V2
• organizations relying on ZITADEL for workforce or customer identity
• environments where privileged users log in through the same affected UI

Accounts protected by Multi-Factor Authentication or passwordless flows are harder to take over through this specific path, and ZITADEL explicitly calls MFA/passwordless out as mitigating this attack vector.

Technical breakdown

The advisory describes a chain that is straightforward but dangerous:

1. The attacker crafts a malicious request to /saml-post.
2. The request passes a hostile url value, including the possibility of a javascript: scheme.
3. The endpoint either redirects or reflects attacker-controlled content without safe encoding.
4. The victim’s browser executes attacker-supplied JavaScript in the context of the ZITADEL flow.
5. The attacker abuses that execution context to reset the victim’s password.
6. The victim account is taken over.

Confirmed weaknesses

• CWE-79: improper neutralization of input during web page generation
• untrusted redirect behavior on a security-sensitive endpoint
• reflective HTML injection in an authentication flow

Why one click is enough

A single interaction is enough because the vulnerable page performs the unsafe work after the victim loads it. There is no need for prior authentication, malware delivery, or a chained server-side exploit. In identity-centric products, that makes this kind of browser-side bug especially dangerous.

Detection and exposure validation

If you operate ZITADEL, treat this as both a patching and a hunting exercise.

Validate exposure

• identify all ZITADEL instances running 4.11.1 or earlier in the 4.x line
• confirm whether Login V2 is enabled on exposed tenants
• test whether /saml-post is still reachable externally
• review reverse proxy and WAF logs for requests to /saml-post
• review password reset events for unusual patterns following inbound links

Hunt for suspicious behavior

Look for:

• unusual bursts of password reset completions
• resets affecting privileged users or administrators
• login activity shortly after password changes from unfamiliar IP ranges
• browser-originated requests to /saml-post with atypical url= parameters
• evidence of attacker-controlled redirect destinations or encoded HTML payloads

Example Splunk query

splCopy
index=proxy OR index=web
("/saml-post" OR "%2Fsaml-post")
| rex field=url "url=(?<target_url>[^&\s]+)"
| search target_url="javascript:*" OR url="*<*" OR url="*%3C*"
| stats count values(target_url) values(src_ip) by host, user_agent

Example hunting pattern only. Adjust fields and decoding logic to your telemetry model.

Containment and remediation checklist

🔴 Immediate actions (0-24h)

• upgrade to ZITADEL 4.12.0 or later
• if you cannot patch immediately, block access to /saml-post at the reverse proxy or Firewall layer when SAML IdP handling is not required
• enforce MFA or passwordless authentication for all privileged users
• reset credentials for sensitive accounts if suspicious reset activity is found
• invalidate active sessions for administrators and support users
• review recent password reset, account recovery, and policy change events

🟠 Near-term hardening (24-72h)

• move all administrator accounts to phishing-resistant authentication where possible
• restrict administrative access paths by IP, device trust, or conditional access
• alert on resets followed by successful sign-ins from new geographies
• ensure the identity tier is covered by central logging and detection engineering
• verify reverse proxy rules reject unsafe schemes and malformed redirect parameters

🟡 Longer-term controls (1-4 weeks)

• treat the identity plane as tier-zero infrastructure
• add secure code review gates for redirect and reflection behavior in auth workflows
• create detections for browser-driven abuse of recovery and reset journeys
• segment admin roles and reduce standing privilege
• run tabletop exercises for identity-provider compromise and tenant takeover scenarios

Strategic analysis

This case is a useful reminder that not all high-impact identity flaws are deep backend bugs. Sometimes a seemingly simple client-side or UI-path issue creates the shortest route to meaningful compromise.

Three points stand out:

• identity products magnify impact: an Exploit against the login tier can become control over downstream applications, users, and trust relationships
• default exposure matters: ZITADEL notes this issue can exist even without SAML IdP configuration, which broadens the affected surface considerably
• MFA changes the outcome: the vendor’s mitigation note reinforces a familiar lesson—strong authentication does not remove every risk, but it often prevents an application bug from turning into full Account Takeover

What is CVE-2026-29191?

It is a ZITADEL Login V2 vulnerability that allows one-click XSS in the /saml-post endpoint and can lead to account takeover.

Which ZITADEL versions are affected?

ZITADEL says versions 4.0.0 through 4.11.1, including release candidates, are affected.

Does this require SAML to be configured?

No. The advisory explicitly says the vulnerable behavior can exist in default deployments even without SAML IdP configuration.

What is the fixed version?

The vendor says the issue is patched in 4.12.0.

Is MFA relevant here?

Yes. ZITADEL says this specific attack path is mitigated for accounts protected by MFA or passwordless authentication.

Should defenders assume compromise?

Not automatically, but organizations running affected versions should urgently check for unusual password reset activity, privileged account changes, and suspicious sign-ins tied to recovery flows.

References

1. ZITADEL GitHub Security Advisory GHSA-pr34-2v5x-6qjq
2. GitHub Advisory Database: CVE-2026-29191
3. NVD: CVE-2026-29191
4. GitLab Advisory Database: CVE-2026-29191
5. ZITADEL Technical Advisories

---

Published: 2026-03-11 Author: Invaders Cybersecurity Classification: Public / TLP:CLEAR Reading Time: 7 minutes