Directus has Improper Permission Handling on Deleted Fields
Collected exploitation and prediction evidence
Risk source coverageCISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.
No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.
cve-program · CVE-2025-64746
PublishedDirectus is a real-time API and App dashboard for managing SQL database content. Prior to version 11.13.0, Directus does not properly clean up field-level permissions when a field is deleted. When a field is removed from a collection, its reference in the permissions table remains intact. This stale reference creates a security gap: if another field is later created using the same name, it inherits the outdated permission entry. This behavior can unintentionally grant roles access to data they should not be able to read or modify. The issue is particularly risky in multi-tenant or production environments, where administrators may reuse field names, assuming old permissions have been fully cleared. Version 11.13.0 fixes the issue.
- Source published
- 13 Nov 2025 20:54:42 UTC
- Source modified
- 13 Nov 2025 21:19:01 UTC
- Observed here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS 3.1 · 4.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
euvd · EUVD-2025-175379
PublishedDirectus is a real-time API and App dashboard for managing SQL database content. Prior to version 11.13.0, Directus does not properly clean up field-level permissions when a field is deleted. When a field is removed from a collection, its reference in the permissions table remains intact. This stale reference creates a security gap: if another field is later created using the same name, it inherits the outdated permission entry. This behavior can unintentionally grant roles access to data they should not be able to read or modify. The issue is particularly risky in multi-tenant or production environments, where administrators may reuse field names, assuming old permissions have been fully cleared. Version 11.13.0 fixes the issue.
EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.
Original publisher date fields
datePublished: Nov 13, 2025, 8:54:42 PM
dateUpdated: Nov 13, 2025, 9:19:01 PM
- Source published
- Nov 13, 2025, 8:54:42 PM (timezone not stated)
- Source modified
- Nov 13, 2025, 9:19:01 PM (timezone not stated)
- Observed here
- 7 Nov 2026 03:29:43 UTC
- Source terms
- ENISA EUVD · source terms and attribution apply
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.
EUVD CVSS 3.1 · 4.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
nvd · CVE-2025-64746
PublishedDirectus is a real-time API and App dashboard for managing SQL database content. Prior to version 11.13.0, Directus does not properly clean up field-level permissions when a field is deleted. When a field is removed from a collection, its reference in the permissions table remains intact. This stale reference creates a security gap: if another field is later created using the same name, it inherits the outdated permission entry. This behavior can unintentionally grant roles access to data they should not be able to read or modify. The issue is particularly risky in multi-tenant or production environments, where administrators may reuse field names, assuming old permissions have been fully cleared. Version 11.13.0 fixes the issue.
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Analyzed
Weakness classifications: CWE-284 · CWE-863
Original publisher date fields
published: 2025-11-13T21:15:54.407
lastModified: 2026-10-19T13:10:00.110
1 source CPE criteria · context only
- cpe:2.3:a:monospace:directus:*:*:*:*:*:node.js:*:*
The original JSON retains the logical configuration operators, exclusions and version bounds.
- Source published
- 13 Nov 2025 21:15:54 UTC
- Source modified
- 19 Oct 2026 13:10:00 UTC
- Observed here
- 25 Oct 2026 03:17:36 UTC
- Source terms
- NIST NVD usage terms; underlying source attribution retained
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS 3.1 · [email protected] · Secondary · 4.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
CVSS 3.1 · [email protected] · Primary · 5.4 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
osv · GHSA-9x5g-62gj-wqf2
Published### Summary Directus does not properly clean up field-level permissions when a field is deleted. If a new field with the same name is created later, the system automatically re-applies the old permissions, which can lead to unauthorized access. ### Details When a field is removed from a collection, its reference in the permissions table remains intact. This stale reference creates a security gap: if another field is later created using the same name, it inherits the outdated permission entry. This behavior can unintentionally grant roles access to data they should not be able to read or modify. The issue is particularly risky in multi-tenant or production environments, where administrators may reuse field names, assuming old permissions have been fully cleared. 1. Create a collection named test_collection. 2. Add a field called secret_field. 3. Assign a role with read permissions specifically tied to secret_field. 4. Remove the secret_field from the collection. 5. Create a new field with the exact same name secret_field. 6. Notice that the previously assigned permissions are still active, granting access to the newly created field without reconfiguration. ### Impact When creating new fields with the same name as previously deleted fields it may inherit the permissions of that previously deleted field. This can potentially result in accidentally giving access to this new field in existing policies.
- Source published
- 14 Nov 2025 21:45:15 UTC
- Source modified
- 14 Nov 2025 21:45:15 UTC
- Observed here
- 24 Oct 2026 13:17:17 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
Publisher rating · MODERATE