CVE-2026-29067

The vulnerable behavior stems from building IDP redirect flows using instance selection derived from request-controlled headers via `getServiceUrlFromHeaders`, while also constructing success/failure URLs from the original/public host. The fix specifically replaces this with `getServiceConfig`, which pins `baseUrl` to `ZITADEL_API_URL` and separates `instanceHost`/`publicHost`, indicating the bug was improper instance validation rather than the new fallback logic itself. This suspected commit introduced the new `redirectUserToIDP` fallback path that uses `serviceUrl` and `organization` to redirect users to an organization-level IDP, thereby adding the vulnerable V2 login takeover/open-redirect-capable flow into `loginname.ts`.

• •In commit 11a35f4..., `redirectUserToIDP(userId?: string, organization?: string)` was added and for org-level fallback it calls `getActiveIdentityProviders({ serviceUrl, orgId: organization })` and `startIdentityProviderFlow({ serviceUrl, idpId: activeIdps[0].id, ... })`.
• •At that commit, `getServiceUrlFromHeaders` derives `serviceUrl` from `x-zitadel-forward-host` or `host`, so instance selection is influenced by inbound headers rather than a validated config.
• •The fix commit replaces `getServiceUrlFromHeaders` with `getServiceConfig`, whose implementation always uses `ZITADEL_API_URL` as `baseUrl` and separately passes sanitized `instanceHost`/`publicHost`, directly addressing improper instance validation.
• •The fix also replaces `getOriginalHost()` with `getPublicHost(_headers)`, showing the security-sensitive distinction between instance routing and public-facing redirect host in this exact code path.

The vulnerability (CVE-2026-29067) is about improper instance validation due to trusting user-controllable headers (`x-zitadel-forward-host`, `x-forwarded-host`) in `getServiceUrlFromHeaders` and `getOriginalHost` to determine the ZITADEL instance and redirect URLs. The BIC (11a35f4ef48c7bbbe0d049a9a655477c59951391) only refactored IDP redirect logic by merging two functions and adding fallback behavior. The vulnerable functions `getServiceUrlFromHeaders` and `getOriginalHost` were already used in the file before this commit (confirmed at parent commit b56bedc77). While the BIC did add new call sites for these vulnerable functions within the refactored code, it did not introduce the core vulnerability — the improper header-based instance resolution that the fix addresses.

• •The vulnerable functions getServiceUrlFromHeaders and getOriginalHost were already imported and used in loginname.ts before the BIC (at commit b56bedc77, lines 12, 25, 38, 81, 82, 131, 132)
• •The BIC only refactored IDP redirect logic by merging redirectUserToSingleIDPIfAvailable and redirectUserToIDP into a single function with fallback behavior
• •The fix commit changes the fundamental approach: replacing getServiceUrlFromHeaders with getServiceConfig (which requires ZITADEL_API_URL) and getOriginalHost with getPublicHost (which separates instance host from public host) - these are architectural changes to functions that predate the BIC
• •The core vulnerability is in service-url.ts and host.ts, not in the IDP redirect logic that the BIC modified

The vulnerability (CVE-2026-29067) is an Improper Instance Validation issue in V2 Login, which allows Account Takeover. The fix commit addresses this by centralizing host resolution logic, replacing `getOriginalHost` with `getPublicHost` and `getServiceUrlFromHeaders` with `getServiceConfig` to prevent attackers from manipulating headers like `Host` or `X-Forwarded-Host`. The suspected Bug-Introducing Commit (11a35f4ef48c7bbbe0d049a9a655477c59951391) refactors the IDP redirection logic in `loginname.ts`. However, the diff clearly shows that the vulnerable functions `getOriginalHost` and `getServiceUrlFromHeaders` were already being used in this file prior to this commit. The suspected BIC merely moved the existing vulnerable code around and did not introduce the improper host validation logic itself. Therefore, it is unlikely that this commit introduced the vulnerability.

• •The fix commit (4c879b47334e01d4fcab921ac1b44eda39acdb96) addresses the vulnerability by replacing `getOriginalHost` with `getPublicHost` and `getServiceUrlFromHeaders` with `getServiceConfig` to properly validate and separate instance and public hosts.
• •The suspected BIC (11a35f4ef48c7bbbe0d049a9a655477c59951391) refactors IDP redirection logic in `apps/login/src/lib/server/loginname.ts`.
• •The diff of the suspected BIC shows that `getOriginalHost` and `getServiceUrlFromHeaders` were already being used in `redirectUserToSingleIDPIfAvailable` and `redirectUserToIDP` before the commit.
• •Since the vulnerable host resolution functions were already present and used in the login flow prior to the suspected BIC, this commit did not introduce the vulnerability.