CVE-2026-76081 in ZITADEL
Summary
by MITRE • 09/15/2026
ZITADEL is an open source identity management platform. Prior to version 4.16.0, a bug in how ZITADEL updates permissions when multiple project roles are deleted at the same time can cause some user permissions to be missed. This issue specifically affects User Grants on Granted Projects (projects shared between different organizations), potentially allowing users to keep access rights that were supposed to be completely removed. This issue has been fully resolved in version 4.16.0. There are no configuration workarounds. Upgrading to a patched version is the only way to trigger the automatic cleanup migration. Those who cannot upgrade immediately should manually review user permissions specifically for Granted Projects where multiple roles were recently deleted.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in ZITADEL prior to version 4.16.0 represents a critical logic flaw within the platform's permission management subsystem, specifically concerning the handling of project role deletions across shared organizational boundaries. As an open source identity and access management solution, ZITADEL relies on precise state transitions to ensure that user privileges align strictly with administrative intent. The defect emerges when multiple project roles are deleted simultaneously for a specific user within the context of Granted Projects, which are resources shared between distinct organizations in a multi-tenant architecture. In this scenario, the internal mechanism responsible for updating permissions fails to iterate through all affected role assignments correctly, resulting in an incomplete cleanup process where certain permission entries remain persisted in the database despite being logically revoked by the administrative action.
From a technical perspective, this flaw constitutes a form of improper access control due to insufficient state management during batch operations. The system does not properly validate that all associated role-to-user mappings have been successfully removed before finalizing the transaction or updating the user's permission cache. This oversight allows for residual permissions to persist on Granted Projects even after an administrator has explicitly revoked them. Consequently, users retain access rights they should no longer possess, creating a discrepancy between the intended security policy and the actual enforced state of the system. This type of error is particularly dangerous in multi-tenant environments where strict isolation between organizations is paramount for data privacy and compliance.
The operational impact of this vulnerability centers on unauthorized persistence of privileges, which directly undermines the principle of least privilege. Users who have had their access revoked may continue to interact with sensitive resources within Granted Projects, potentially leading to data leakage or unauthorized modifications depending on the specific permissions retained. This situation complicates audit trails and compliance reporting, as historical records might indicate that access was properly terminated while active sessions or API calls still reflect lingering authorization tokens derived from the uncleared database entries. The lack of a configuration workaround means that organizations cannot mitigate this risk through policy adjustments alone; they must rely on either upgrading to the patched version which triggers an automatic cleanup migration or performing manual reviews and corrections of user permissions for affected Granted Projects where multiple roles were recently deleted.
In terms of industry standard classifications, this vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to properly restrict access to resources based on assigned privileges. Furthermore, the behavior can be mapped to MITRE ATT&CK techniques related to Privilege Escalation or Persistence, specifically where an actor might exploit lingering permissions to maintain unauthorized access after intended revocation attempts have failed. Security teams managing ZITADEL deployments should prioritize upgrading to version 4.16.0 or later as the primary remediation strategy. For environments unable to upgrade immediately due to operational constraints, a rigorous manual audit of user grants on all Granted Projects is required, focusing specifically on instances where bulk role deletions have occurred recently to identify and manually remove any orphaned permission entries that were missed by the flawed update logic.