GHSA-cpf4-pmr4-w6cx CVE-2025-64431 GO-2025-4099
IDOR Vulnerabilities in ZITADEL's Organization API allows Cross-Tenant Data Tempering
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.30%
- Chance of exploitation in the next 30 days. Higher than 23.10% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-639 Authorization Bypass Through User-Controlled Key
- Fix
4.6.3- Upgrade github.com/zitadel/zitadel to this version or later
Description
Summary
ZITADEL's Organization V2Beta API contains Insecure Direct Object Reference (IDOR) vulnerabilities that allow authenticated users with specific administrator roles within one organization to access and modify data belonging to other organizations.
Impact
ZITADEL's Organization V2Beta API, intended for managing ZITADEL organizations, contains multiple endpoints that fail to properly authorize authenticated users. An attacker with an administrator role for a specific organization could exploit this to bypass access controls and perform unauthorized actions on other organizations within the same ZITADEL instance.
This could allow an attacker to:
- Read organization data, including the name, domains and metadata.
- Manipulate (modify) the corresponding organization data.
- Delete the corresponding data, up to and including the entire organization.
Note that this vulnerability is limited to organization-level data (name, domains, metadata). No other related data (such as users, projects, applications, etc.) is affected.
Affected Versions
Systems running one of the following versions are affected:
- v4.x:
4.0.0-rc.1through4.6.2
Patches
The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the caller's permission against the target organization.
- v4.x: Upgrade to version 4.6.3 or later.
Workarounds
Upgrading to a patched version is the recommended solution.
If an immediate upgrade is not possible, mitigation can be achieved by disabling the affected Organization V2Beta API endpoints (e.g., /v2beta/organizations/...) at a reverse proxy or Web Application Firewall (WAF) level.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/zitadel/zitadel | >= 4.0.0-rc.1, < 4.6.3 |
4.6.3 |
| github.com/zitadel/zitadel | >= 1.80.0-v2.20.0.20250414095945-f365cee73242, < 1.80.0-v2.20.0.20251105083648-8dcfff97ed52 |
1.80.0-v2.20.0.20251105083648-8dcfff97ed52 |
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 → 4.6.3
- go
go get github.com/zitadel/zitadel@v4.6.3 && go mod tidy
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- Low
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-639: Authorization Bypass Through User-Controlled Key
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
How to prevent it
- Architecture and Design: For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- Architecture and Design, Implementation: Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
- Architecture and Design: Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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 |
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