High priorityDisclosed

Advisory · CVE-2026-119127

Account takeover in ZITADEL Login V2 via host header injection

ZITADEL 4.0.0 through 4.19.4 lets an unauthenticated attacker poison password-reset, invite, and email-verification links via untrusted host headers and harvest the single-use codes. ZITADEL rates it high at CVSS 4.0 8.6.

Advisory published October 29, 2026Independent summary
Vendor
ZITADEL
Product
ZITADEL
Identifier / CWE
CVE-2026-119127
CWE-640
Action timing
Immediate
ELI5

Explain it like I’m five

ZITADEL emails you a genuine reset link, but it builds the link address from a header the attacker controls. The attacker points your real link at their own site and collects your reset code when you click.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Poisoned header

    An unauthenticated attacker who knows a victim login name submits a request with a crafted public-host header.

  2. 02Genuine email, hostile link

    ZITADEL sends a genuine reset, invite, or verification email whose link points at the attacker host while carrying the real single-use code.

  3. 03Code harvested

    The victim opens the link, or automated mail scanning fetches it, and the attacker captures the code.

  4. 04Account taken over

    The attacker sets a new password or completes verification and signs in as the victim, including an instance administrator.

What happened

ZITADEL disclosed CVE-2026-119127 in versions 4.0.0 through 4.19.4: the hosted Login V2 UI built password-reset, invite, and email-verification links from client-supplied proxy headers without confirming the host belonged to the instance, and the trusted-domain control was silently skipped for malformed hosts that resolved to an empty host. An unauthenticated attacker who knows only a victim login name can redirect the genuine links to an attacker host and harvest the single-use codes. ZITADEL rates it high at CVSS 4.0 8.6.

The email itself is genuine, with the correct sender and branding, so only the link host differs. Takeover of an instance administrator yields full control of the instance. Deployments not running Login V2 are not affected.

What to do

  1. Inventory ZITADEL instances and confirm whether the hosted Login V2 UI is in use.
  2. Upgrade ZITADEL to version 4.19.5 or later, which validates the public host against trusted domains.
  3. As a partial mitigation before upgrading, configure a fronting proxy to strip or overwrite the public-host headers on inbound requests.
  4. Review login, password-reset, and verification logs for resets or verifications tied to unfamiliar hosts.
  5. Force credential resets for accounts, especially administrators, where a poisoned link cannot be excluded.

Management note

Identity providers are crown-jewel targets: one poisoned reset link can hand over an administrator. Patch Login V2 deployments promptly and check reset logs.