CVE-2025-64746: 
JavaScript vulnerability analysis and mitigation

CVE-2025-64746 is an improper permission handling vulnerability in Directus, a real-time API and App dashboard for managing SQL database content. When a field is deleted from a collection, its field-level permission entries in the directus_permissions table are not removed, and if a new field is created with the same name, it automatically inherits those stale permissions — potentially granting unauthorized read or write access. All versions of Directus prior to 11.13.0 (npm package) are affected. The vulnerability was published on November 13, 2025, with a fix released the same day. It carries a CVSS v3.1 base score of 4.6 (Moderate) (GitHub Advisory, Directus Advisory).

The root cause is classified under CWE-284 (Improper Access Control) and CWE-863 (Incorrect Authorization): when a field is deleted via the FieldsService, the corresponding rows in the directus_permissions table referencing that field are not cleaned up (Directus Advisory). The fix, applied in commit 84d7636, adds a post-deletion step that queries directus_permissions for any rows matching the deleted collection and field name, then removes the field reference from those rows or nullifies the entry if no other fields remain (Patch Commit). Exploitation requires that an administrator (or user with schema management privileges) first delete a field and later recreate a field with the same name — a common pattern in iterative development or multi-tenant environments. No complex attack chain or special tooling is needed beyond standard Directus API or UI access.

Successful exploitation results in low-privileged authenticated users gaining unintended read and/or write access to newly created fields that inherited stale permissions from previously deleted fields. The confidentiality and integrity impacts are both rated low, with no availability impact, as the vulnerability does not enable remote code execution or denial of service (GitHub Advisory). The risk is elevated in multi-tenant or production environments where field name reuse is common and administrators may incorrectly assume that deleting a field also removes its associated permissions (Directus Advisory).

A proof-of-concept scenario is documented in the official security advisory, demonstrating the step-by-step reproduction of the permission inheritance issue; however, no weaponized exploit code or active in-the-wild exploitation has been reported (Directus Advisory). The EPSS score is approximately 0.044% (14th percentile), indicating a low probability of exploitation in the near term (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been identified.

1. Identify target instance: Locate a Directus instance running a version prior to 11.13.0 with access to the admin UI or API.
2. Create a collection and sensitive field: As an administrator, create a collection (e.g., test_collection) and add a field (e.g., secret_field) containing sensitive data.
3. Assign field-level permissions: Grant a low-privileged role read (and/or write) permissions scoped specifically to secret_field in test_collection.
4. Delete the field: Remove secret_field from the collection. The permission entry in directus_permissions referencing this field remains intact.
5. Recreate the field with the same name: Create a new field named secret_field in the same collection, potentially with different intended access controls.
6. Access data as low-privileged user: Log in as a user with the previously assigned role and query the collection via the Directus API (e.g., GET /items/test_collection). The stale permission entry automatically grants access to the newly created secret_field, exposing data that should be restricted (Directus Advisory).

• Logs: Directus API access logs showing low-privileged roles successfully reading or modifying fields that were recently recreated after deletion; unexpected 200 OK responses to /items/<collection> requests from roles that should not have field access.
• Database: Orphaned rows in the directus_permissions table where the referenced field name no longer exists in the schema (detectable by cross-referencing directus_permissions.fields against directus_fields); permission rows with fields values matching recently deleted-and-recreated field names.
• Application Events: Directus activity logs (directus_activity) showing field deletion followed shortly by field creation with the same name, combined with access events from roles that were not explicitly granted permissions to the new field.

The primary remediation is to upgrade Directus to version 11.13.0 or later, which includes the fix that automatically removes stale field references from directus_permissions upon field deletion (Directus Advisory, Patch Commit). For environments that cannot immediately upgrade, administrators should manually audit the directus_permissions table to identify and remove any stale field references after deleting fields, particularly before recreating fields with the same name. Additionally, implementing a policy of reviewing and explicitly reconfiguring permissions whenever fields are recreated is recommended as a procedural control.