CVE-2025-27089 in Directus
Summary
by MITRE • 02/19/2025
Directus is a real-time API and App dashboard for managing SQL database content. In affected versions if there are two overlapping policies for the `update` action that allow access to different fields, instead of correctly checking access permissions against the item they apply for the user is allowed to update the superset of fields allowed by any of the policies. E.g. have one policy allowing update access to `field_a` if the `id == 1` and one policy allowing update access to `field_b` if the `id == 2`. The user with both these policies is allowed to update both `field_a` and `field_b` for the items with ids `1` and `2`. Before v11, if a user was allowed to update an item they were allowed to update the fields that the single permission, that applied to that item, listed. With overlapping permissions this isn't as clear cut anymore and the union of fields might not be the fields the user is allowed to update for that specific item. The solution that this PR introduces is to evaluate the permissions for each field that the user tries to update in the validateItemAccess DB query, instead of only verifying access to the item as a whole. This is done by, instead of returning the actual field value, returning a flag that indicates if the user has access to that field. This uses the same case/when mechanism that is used for stripping out non permitted field that is at the core of the permissions engine. As a result, for every item that the access is validated for, the expected result is an item that has either 1 or null for all the "requested" fields instead of any of the actual field values. These results are not useful for anything other than verifying the field level access permissions. The final check in validateItemAccess can either fail if the number of items does not match the number of items the access is checked for (ie. the user does not have access to the item at all) or if not all of the passed in fields have access permissions for any of the returned items. This is a vulnerability that allows update access to unintended fields, potentially impacting the password field for user accounts. This has been addressed in version 11.1.2 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/19/2025
The vulnerability described in CVE-2025-27089 affects Directus, a real-time API and application dashboard designed for managing SQL database content. This security flaw exists in versions prior to v11.1.2 and stems from a critical flaw in the permission validation mechanism that governs user access to database fields. The issue manifests when overlapping policies exist for the update action, where users with multiple permissions that grant access to different fields can inadvertently gain access to fields beyond what their specific policy should allow. This represents a significant deviation from the expected behavior where access permissions should be strictly enforced per item and per field, rather than allowing a union of all permitted fields across different items. The vulnerability fundamentally undermines the principle of least privilege that is essential for maintaining data integrity and security in database management systems.
The technical implementation of this vulnerability occurs within the validateItemAccess database query where the permission checking logic fails to properly evaluate field-level access for individual items. Instead of verifying access permissions against each specific field that a user attempts to update, the system incorrectly aggregates field permissions from multiple policies, allowing users to modify fields that should remain restricted. This flaw specifically impacts the permissions engine's core functionality, where the system should utilize a case/when mechanism to strip out non-permitted fields but instead returns flags indicating field access rather than actual values. The validation process now requires that for every item being accessed, the system returns either 1 or null for all requested fields, with the actual field values being irrelevant for the access verification process. This change in behavior represents a fundamental shift from the previous implementation where users could only update fields explicitly permitted by their single applicable policy for each item.
The operational impact of this vulnerability is substantial, as it creates a pathway for unauthorized data modification that could compromise sensitive information within database systems. The most concerning aspect is the potential exposure of password fields for user accounts, which could lead to complete account compromise and unauthorized access to systems. This vulnerability affects the core security model of Directus, potentially allowing attackers to escalate privileges and access data they should not be permitted to modify. The issue is particularly dangerous because it operates silently, with users gaining access to unintended fields without triggering any explicit security alerts. The union of permissions across different items creates a scenario where legitimate users might unknowingly gain access to fields that should be restricted to administrators or specific roles, undermining the security controls that organizations rely upon for data protection.
The mitigation strategy for this vulnerability involves upgrading to Directus version 11.1.2 or later, which implements a corrected permission validation mechanism that properly evaluates field-level access for each item being modified. This update ensures that the validateItemAccess query correctly validates access permissions on a per-field basis rather than allowing aggregate field access across multiple policies. The solution addresses the underlying architectural flaw by implementing a more granular permission checking approach that maintains the case/when mechanism but uses it to verify field access rather than strip fields from results. Organizations using older versions of Directus should prioritize this upgrade as there are no known workarounds for this vulnerability. The fix aligns with security best practices outlined in CWE-284, which addresses improper access control, and supports the ATT&CK technique T1078 for valid accounts and privilege escalation. This vulnerability demonstrates the critical importance of field-level access controls in database management systems and highlights how seemingly minor permission evaluation flaws can lead to significant security breaches. The corrected implementation ensures that users can only update fields explicitly permitted by their specific policy for each item, maintaining the integrity of the permission model and preventing unauthorized data modifications that could compromise system security.