GHSA-mvv8-v4jj-g47j CVE-2026-39943
Directus: Sensitive fields exposed in revision history
- Severity
- 6.5 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 0.17%
- Chance of exploitation in the next 30 days. Higher than 6.30% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
- CWE-312 Cleartext Storage of Sensitive Information
- Fix
11.17.0- Upgrade directus to this version or later
Description
Summary
Directus stores revision records (in directus_revisions) whenever items are created or updated. Due to the revision snapshot code not consistently calling the prepareDelta sanitization pipeline, sensitive fields (including user tokens, two-factor authentication secrets, external auth identifiers, auth data, stored credentials, and AI provider API keys) could be stored in plaintext within revision records.
Impact
Any user or service account with read access to directus_revisions (or flow logs) could retrieve values for fields that are supposed to be concealed or encrypted at rest, including:
token,tfa_secret,external_identifier,auth_data,credentialsai_openai_api_key,ai_anthropic_api_key,ai_google_api_key,ai_openai_compatible_api_key
This could lead to account takeover (via stolen tokens or 2FA secrets) or unauthorized use of third-party API keys stored against users.
Affected code paths
- Item create/update revisions The data (snapshot) field written to directus_revisions was not processed through prepareDelta, so concealed/encrypted fields were stored without redaction. Relational fields were also included, which should have been excluded.
- Authentication service When a user was auto-suspended after repeated failed login attempts, the revision record was created with the raw user object (including all sensitive fields) rather than the sanitized delta.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| directus | < 11.17.0 |
11.17.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
directus npm → 11.17.0
- npm
npm install directus@11.17.0- yarn
yarn add directus@11.17.0- pnpm
pnpm add directus@11.17.0
Severity breakdown
CVSS 3.1 6.5
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
How to prevent it
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CWE-312: Cleartext Storage of Sensitive Information
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
How to prevent it
- Implementation, System Configuration, Operation: When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
- Implementation, System Configuration, Operation: In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-c6w9-5g5j-jh2p Directus: Authorization-dependent response served from unsegmented cache key | High | Also affects directus |
| GHSA-j5h6-vqc3-phqh Directus: SSRF Protection Bypass via 0.0.0.0 in File Import | High | Also affects directus |
| GHSA-38hg-ww64-rrwc Directus: Authenticated Users Can Extract Concealed Fields via Aggregate Queries | High | Also affects directus |
| GHSA-6q22-g298-grjh Directus: Unauthenticated Denial of Service via GraphQL Alias Amplification of Expensive Health Check Resolver | High | Also affects directus |
| GHSA-ph52-67fq-75wj Directus: GraphQL Alias Amplification Denial of Service Due to Missing Query Cost/Complexity Limits | Medium | Also affects directus |
| GHSA-qqmv-5p3g-px89 Directus: TUS Upload Authorization Bypass Allows Arbitrary File Overwrite | High | Also affects directus |
| GHSA-wv3h-5fx7-966h Directus: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses in File Import | High | Also affects directus |
| GHSA-wxwm-3fxv-mrvx Directus: GraphQL Schema SDL Disclosure Setting | Medium | Also affects directus |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor