{"id":"CVE-2026-55670","title":" ZITADEL: Cross-Tenant User Leakage via Recycled Identifiers","summary":" ZITADEL: Cross-Tenant User Leakage via Recycled Identifiers","severity":"low","cwe":["CWE-284","CWE-639"],"vendor":"zitadel","product":"github.com/zitadel/zitadel","ecosystem":"go","affected":["github.com/zitadel/zitadel < 1.80.0-v2.20.0.20260615092437-6082e59d47c1"],"patched":["github.com/zitadel/zitadel 1.80.0-v2.20.0.20260615092437-6082e59d47c1"],"published":"2026-06-18","updated":"2026-06-18","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-6x8v-2fq5-2229","references":[{"url":"https://github.com/zitadel/zitadel/security/advisories/GHSA-6x8v-2fq5-2229"},{"url":"https://github.com/zitadel/zitadel/commit/6082e59d47c17a9d54a6b0556b3f31559d7c620a"},{"url":"https://github.com/zitadel/zitadel/releases/tag/v4.15.2"},{"url":"https://github.com/advisories/GHSA-6x8v-2fq5-2229"}],"tags":["ghsa","go"],"ingestedAt":"2026-06-29T14:31:46.995Z","epss":0.00362,"epssPercentile":0.30018,"slug":"CVE-2026-55670","body":"## Overview\n\n### Summary\n\nA flaw in the user lifecycle enforcement allowed deleted users to retain their original organization/tenant association. Recreating a deleted user under a distinct organization can cause the new user instance to be incorrectly provisioned within the original organization if the previous ID would be used to recreate it.\n\n### Impact\n\nWhen a user is created, the system maps the generated or provided ID to its target organization (`Org A`). When that user is subsequently deleted, a deletion event is appended to the stream, but the historical mapping of the resource owner within the event store's validation layer is not cleared.\n\nIf a new user is later provisioned in a different organization (`Org B`) using that exact same ID, the event store validation logic reads the stream's history, matches it to the original organization, and routes the new user's events to `Org A` instead of `Org B`.\n\nThis issue represents a localized multi-tenancy isolation anomaly rather than an easily exploitable attack vector. Because the new user instance is incorrectly routed and provisioned inside `Org A` instead of `Org B`, an administrator from `Org A` inadvertently gains full access to this new user record.\n\nHowever, there is no technical mechanism for a malicious actor to force, automate, or target this behavior against a specific user or tenant. Because the scenario relies entirely on an accidental sequence of operational events and requires the recycling of a highly specific ID space, the practical security risk is exceptionally low.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n\n* **4.x:** `4.0.0` through `4.15.1` (including RC versions)\n* **3.x:** `3.0.0` through `3.4.11` (including RC versions)\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.\n\n- **4.x**: Upgrade to $\\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n- **3.x**: Update to $\\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n\n### Workarounds\n\nThe recommended solution is to upgrade to a patched version. \n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to Charlie Graven from Famedly for reporting this vulnerability.\n\n## Affected packages\n\n- `github.com/zitadel/zitadel < 1.80.0-v2.20.0.20260615092437-6082e59d47c1`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `github.com/zitadel/zitadel 1.80.0-v2.20.0.20260615092437-6082e59d47c1`","depth":"sunlit","depthScore":14,"depthScoreParts":{"impact":13.8,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}