GHSA-mvv8-v4jj-g47j: Sensitive Field Exposure in Directus Revision History

Directus operates as a headless CMS and heavily relies on database tracking for content versioning. The directus_revisions table is designed to store incremental changes (deltas) whenever an item is created or modified. This feature allows administrators to track modifications and revert changes if necessary.

However, the implementation of this tracking mechanism contained a significant logic flaw regarding sensitive data sanitization. When processing specific item updates, the application failed to filter out concealed or encrypted fields before writing the snapshot to the database.

This vulnerability, tracked as GHSA-mvv8-v4jj-g47j, results in the cleartext storage of sensitive information. Authentication tokens, two-factor authentication (2FA) secrets, and third-party API keys were inadvertently committed to the revision history.

Consequently, any user or service account with read privileges to the directus_revisions table or Directus Flows execution logs could extract these secrets. The exposure compromises the fundamental security boundaries of the application and its integrated third-party services.

The vulnerability stems from three distinct failures in the data sanitization pipeline within the Directus core. First, during standard item creation and update operations, the resulting data snapshot bypassed the prepareDelta utility. This function is explicitly responsible for stripping sensitive and relational fields from the payload before database insertion.

Second, the authentication service contained an independent flaw within its auto-suspension logic. When a user account triggered automatic suspension—typically due to excessive failed login attempts—the service generated an automated revision record. The codebase erroneously passed the entire raw user object into this revision, rather than a sanitized delta payload, dumping all account secrets into the table.

Third, the Directus Flows execution engine maintained an incomplete redaction list for operational logging. When workflows processed payloads containing data from the directus_users collection, the system logged the operations for debugging and audit purposes. Due to missing field definitions in the redaction configuration, sensitive keys bypassed the filter and were written to the logs in plain text.

These independent vectors converge on a single architectural weakness: the lack of a mandatory, centralized data sanitization enforcement layer at the database write boundary.

Prior to version 11.17.0, the codebase handled revision writes asynchronously, often prioritizing performance over strict data validation. The primary commit resolving this issue (26c6985c742593d081f8b58450f463a584a4203a) introduces mandatory checks using the prepareDelta function across all identified vulnerable paths.

In the vulnerable implementation, the revision service accepted the raw payload object directly from the request context. The fix alters this behavior by intercepting the payload and routing it through prepareDelta or an equivalent sanitization routine. This ensures that any field explicitly marked as sensitive in the schema is pruned from the delta object before the SQL INSERT statement is constructed.

For the Directus Flows component, the remediation required updating the internal redaction schema. The developers appended the missing sensitive fields, including the AI provider keys (ai_openai_api_key, ai_anthropic_api_key, etc.) and the external authentication identifiers, to the global exclusion list. This ensures that the logger scrubs these keys and replaces them with a generic redaction string before writing to the execution logs.

The fix for the authentication service involved refactoring the suspension logic. Instead of passing the complete user model to the revision service, the code now explicitly constructs a minimal payload containing only the modified status field. This eliminates the risk of inadvertently logging the tfa_secret or token during an auto-suspension event.

Exploitation of this vulnerability requires an attacker to possess read access to either the directus_revisions table or the Directus Flows execution logs. This access is typically restricted to administrative users, developers, or specific service accounts. However, an attacker could chain this vulnerability with a separate flaw, such as an SQL Injection or a Server-Side Request Forgery (SSRF), to query the table indirectly.

Once access is achieved, the attacker executes a basic database query against the directus_revisions table. They target the data or delta JSON columns, searching for keys such as tfa_secret, token, or ai_openai_api_key. The application stores these payloads in plaintext JSON, making extraction trivial without any decryption requirements.

With the extracted tfa_secret or authentication token, the attacker can bypass existing access controls. By generating valid Time-based One-Time Passwords (TOTP) or injecting the hijacked session token, they can impersonate high-privileged users. This leads to a complete account takeover without triggering standard brute-force protections.

If the attacker targets the integrated AI API keys, they can exfiltrate these credentials for use outside the Directus environment. The attacker executes requests directly against the OpenAI, Anthropic, or Google APIs using the stolen keys. This behavior operates completely independently of the Directus application infrastructure, complicating detection and incident response efforts.

The vulnerability carries a CVSS v3.1 base score of 6.5, categorized as Medium severity. The vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) highlights the primary risk as a high confidentiality impact. The exposure of raw credentials fundamentally breaks the security model of the affected deployments.

The exposure of Two-Factor Authentication secrets (tfa_secret) is particularly critical. It nullifies the protection offered by multi-factor authentication, allowing an attacker to persist access even if the primary password is changed. The inclusion of external identifiers and authentication data further expands the attack surface to federated identity providers connected to the Directus instance.

The financial impact is a significant secondary consequence of this vulnerability. Third-party API keys, specifically those for AI services like OpenAI and Anthropic, are billed based on usage. An attacker leveraging stolen keys can incur substantial unauthorized charges on the victim's accounts. These attacks are highly automated and can drain prepaid balances or generate massive invoices rapidly.

Furthermore, the exposure of these secrets within historical revision logs means the risk persists even after the vulnerability is patched. Organizations that upgrade the application without manually purging the affected database records remain completely vulnerable to credential extraction.

The primary remediation strategy requires upgrading the directus package to version 11.17.0 or later. Administrators should execute npm update directus or modify their package.json to ensure the correct version is deployed. This patch addresses the root cause by enforcing data sanitization on all new writes to the revision and logging systems.

However, the software update does not modify historical database records. System administrators must manually audit the directus_revisions table and the Directus Flow logs to identify and remove exposed secrets. This requires executing SQL UPDATE or DELETE statements to purge any JSON payloads containing sensitive keys like token, tfa_secret, or the ai_*_api_key suite.

Due to the uncertainty regarding potential prior exposure, organizations must implement a comprehensive secret rotation policy. Administrators should force a reset of all user authentication tokens and mandate the regeneration of 2FA secrets for all administrative accounts. Relying solely on database cleanup is insufficient if the credentials were theoretically accessible prior to discovery.

Finally, organizations must regenerate all affected third-party API keys through their respective provider portals (OpenAI, Anthropic, Google). The old keys must be explicitly revoked to prevent ongoing unauthorized usage. Administrators should verify the updated keys are functioning correctly within the patched Directus instance to restore full functionality.