Skip to content

GHSA-7wfc-4796-gmg5 CVE-2025-67494 GO-2025-4210

ZITADEL Vulnerable to Unauthenticated Full-Read SSRF via V2 Login

High Go
Severity
9.3 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.44%
Chance of exploitation in the next 30 days. Higher than 38.61% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-918 Server-Side Request Forgery (SSRF)
Fix
Available
2 packages have a fixed version

Description

Summary

Zitadel is vulnerable to an unauthenticated, full-read SSRF vulnerability. An unauthenticated remote attacker can force Zitadel into making HTTP requests to arbitrary domains, including internal addresses. The server then returns the upstream response to the attacker, enabling data exfiltration from internal services.

Impact

ZITADEL Login UI (V2) was vulnerable to service URL manipulation through the x-zitadel-forward-host header. The service URL resolution logic treated the header as a trusted fallback for all deployments, including self-hosted instances. This allowed unauthenticated attacker to force the server to make outbound requests and read the responses, reaching internal services, exfiltrating data, and bypassing IP-based or network-segmentation controls.

Affected Versions

Systems using the login UI (v2) and running one of the following versions are affected:

  • v4.x: 4.0.0-rc.1 through 4.7.0

Patches

The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the x-zitadel-forward-host, resp. all forwarded headers against the instance domains and trusted domains. It's no longer used to route traffic to the Zitadel API.

Before you upgrade, ensure that:

  • the ZITADEL_API_URL is set and is pointing to your instance, resp. system in multi-instance deployments.
  • the HTTP host (or a x-forwarded-host) is passed in your reverse proxy to the login UI.
  • a x-zitadel-instance-host (or x-zitadel-forward-host) is set in your reverse for multi-instance deployments. If you're running a single instance solution, you don't need to take any actions.

Fixed versions:

  • 4.x: Upgrade to >=4.7.1

Workarounds

The recommended solution is to update ZITADEL to a patched version.

A ZITADEL fronting proxy can be configured to delete all x-zitadel-forward-host header values or set it to the requested host before sending requests to ZITADEL self-hosted environments.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.

Affected versions

Go

PackageVulnerableFixed in
github.com/zitadel/zitadel
< 1.80.0-v2.20.0.20251208091519-4c879b47334e
1.80.0-v2.20.0.20251208091519-4c879b47334e
github.com/zitadel/zitadel
>= 1.83.4, <= 1.87.5
No fix yet
github.com/zitadel/zitadel
>= 4.0.0-rc.1, < 4.7.1
4.7.1
github.com/zitadel/zitadel
< 1.80.0-v2.20.0.20251208091519-4c879b47334e
>= 1.83.4
1.80.0-v2.20.0.20251208091519-4c879b47334e
github.com/zitadel/zitadel/v2
< 1.80.0-v2.20.0.20251208091519-4c879b47334e
1.80.0-v2.20.0.20251208091519-4c879b47334e

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/zitadel/zitadel Go → 1.80.0-v2.20.0.20251208091519-4c879b47334e

go
go get github.com/zitadel/zitadel@v1.80.0-v2.20.0.20251208091519-4c879b47334e && go mod tidy

github.com/zitadel/zitadel/v2 Go → 1.80.0-v2.20.0.20251208091519-4c879b47334e

go
go get github.com/zitadel/zitadel/v2@v1.80.0-v2.20.0.20251208091519-4c879b47334e && go mod tidy

Severity breakdown

CVSS 3.1 9.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
Low
Availability
None

Weakness

CWE-918: Server-Side Request Forgery (SSRF)

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-fgmf-7rf8-m6vf
ZITADEL: Actions V1 sandbox escape: host file read via require()
High Also affects github.com/zitadel/zitadel
GHSA-9993-rfwp-rhwf
ZITADEL: MFA bypass via session reuse in Login V2
High Also affects github.com/zitadel/zitadel
GHSA-v859-c572-qh5p
ZITADEL: Improper Role Revocation on Granted Projects during Multiple Role Deletions
Medium Also affects github.com/zitadel/zitadel
GHSA-jq8w-8q2f-ffm9
ZITADEL Users Can Self-Verify Email/Phone via API
High Also affects github.com/zitadel/zitadel
GHSA-vrh8-c9cm-wh8v
ZITADEL: Unauthorized Token Privilege Escalation in OAuth2 Token Exchange
High Also affects github.com/zitadel/zitadel
GHSA-992q-9gwp-7r79
ZITADEL: Auto-linking by email: IdP-side email verification is not checked
Medium Also affects github.com/zitadel/zitadel
GHSA-v77h-2w3m-94hx
ZITADEL: Missing Token Expiration (`exp`) Validation in JWT IdP Provider
Medium Also affects github.com/zitadel/zitadel
GHSA-g5h5-m4hm-xjrr
ZITADEL: Missing Token Audience Validation (`aud`) in JWT IdP Provider
Medium Also affects github.com/zitadel/zitadel
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor