Summary

When response caching is enabled (CACHEENABLED=true), the cache-key derivation in api/src/utils/get-cache-key.ts includes only version, path, query, and accountability.user (plus a conditional ip). Authorization context beyond user (share, role, roles, admin, app, policies) is not part of the key.

For share tokens this is load-bearing. Directus's share-authentication flow (api/src/services/shares.ts:100-105) issues a JWT without an id claim, so api/src/utils/get-accountability-for-token.ts never assigns accountability.user, leaving it null (the default from create-default-accountability.ts). Every share token, and every anonymous request, therefore reduces to user: null in the cache-key input. Two different shares (or an anonymous request and a share token) requesting the same URL with the same query produce identical cache keys. The first request populates the bucket with a permission-filtered response; subsequent hits from unrelated shares or anonymous clients receive that payload without any permission re-evaluation.

This is the web-cache pattern "authorization-dependent response cached under an unsegmented key" (cache key collision / missing authorization context in cache key, CWE-524 and CWE-639). Two adjacent read populations collide:

- Share to share: Share A populates the cache, Share B reads Share A's scoped response. - Share to anonymous (and the reverse): any unauthenticated client hitting the same URL retrieves cached share-scoped data without presenting any token.

Affected

- Config required: CACHEENABLED=true (any store: memory, redis, memcached) plus at least one active directusshares row. This is not a default-on bug: CACHEENABLED ships as false. The cache is documented as a production performance setting, so operators who enable it are the ones affected.

Vulnerability class

- CWE-524: Use of Cache Containing Sensitive Information - CWE-639: Authorization Bypass Through User-Controlled Key (the key here is the derived cache key, not the URL) - OWASP API3:2023: Broken Object Property Level Authorization

Impact

- Cross-share confidentiality breach. Any share's filtered response can be served to a holder of a different share token, or to an anonymous request, that hits the same URL and query. Shares are advertised as a mechanism to distribute scoped, read-only access to specific items; this bug makes every cached share response readable by any other share-token holder who can reach the URL (the item-detail admin UI uses a predictable pattern). - Anonymous request can read share data. Anonymous requests also compute user=null. An anonymous client hitting /items/articles?fields= after a share request has populated the cache receives the share's scoped payload with zero authentication. - Password-protected share, derivative effect. Password protection lives only at shares.login (JWT issuance). Once any share has populated the cache for a URL, an anonymous or alternate-share request to that URL retrieves the cached payload without exchanging the share password. This is the same cache-key collision surfacing as a password-protection bypass symptom, not a distinct mechanism. - Persistence. The leak persists for the CACHETTL window (commonly 5 to 30 minutes). CACHEAUTOPURGE clears on mutating writes to cached collections but does not purge per-user or per-share. With CACHESTORE=redis (common in production) the poisoned bucket survives server restarts. - No write impact. The bypass is read-only.

Scope of the leak depends on the share's permission surface. A share with no backing role (directusshares.role = null, the default) collapses visibility to the primary key, so the cache leaks only PKs. A share backed by a role with broader field access (the intended production setup for distributing useful content) leaks the full content that role can see on the scoped item.

Directus is a real-time API and App dashboard for managing SQL database content. Prior to 11.17.0, Directus stores revision records (in directusrevisions) 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. This vulnerability is fixed in 11.17.0.

Directus is a real-time API and App dashboard for managing SQL database content. Prior to 11.17.0, the PATCH /files/{id} endpoint accepts a user-controlled filenamedisk parameter. By setting this value to match the storage path of another user's file, an attacker can overwrite that file's content while manipulating metadata fields such as uploadedby to obscure the tampering. This vulnerability is fixed in 11.17.0.

Summary

A timing-based user enumeration vulnerability exists in the password reset functionality. When an invalid reseturl parameter is provided, the response time differs by approximately 500ms between existing and non-existing users, enabling reliable user enumeration.

Details

The password reset endpoint implements a timing protection mechanism to prevent user enumeration; however, URL validation executes before the timing protection is applied. This allows an attacker to distinguish between valid and invalid user accounts based on response timing differences.

Impact

This vulnerability violates user privacy and may facilitate targeted phishing attacks by allowing attackers to confirm the existence of user accounts.

Summary:

An observable difference in error messaging was found in the Directus REST API. The /items/{collection} API returns different error messages for these two cases: 1. A user tries to access an existing collection which they are not authorized to access. 2. A user tries to access a non-existing collection.

The two differing error messages leak the existence of collections to users which are not authorized to access these collections.

Details:

The following response returns an error message, when requesting a collection the user is not authorized to access.

GET /items/no-access { "errors": [ { "message": "You don't have permission to access collection \"no-access\" or it does not exist. Queried in root.", "extensions": { "reason": "You don't have permission to access collection \"no-access\" or it does not exist. Queried in root.", "code": "FORBIDDEN" } } ] }

The following response returns a different error message when requesting a collection which does not exist.

GET /items/does-not-exist { "errors": [ { "message": "You don't have permission to access this.", "extensions": { "code": "FORBIDDEN" } } ] }

Impact:

The difference in errors between non-existent collections and collections blocked by permissions leak the existence of a collection to a user which is not authorized to access this object.

Credit:

Sebastian Krause - Hackmanit GmbH

Summary

A vulnerability allows authenticated users to search concealed/sensitive fields when they have read permissions. While actual values remain masked (), successful matches can be detected through returned records, enabling enumeration attacks on sensitive data.

Details

The system permits search operations on concealed fields in the directususers collection, including token, tfasecret, password. Matching records are returned with masked values, but their presence confirms the searched value exists.

The "Recommended Defaults" for "App Access" grant users full read permissions to their role/user records, inadvertently enabling them to search for any user's tokens, TFA secrets, and password hashes. Attackers can leverage known password hashes from breach databases to identify accounts with compromised passwords.

Impact

This vulnerability enables: - Token enumeration - Verification of valid authentication tokens - Password hash matching - Identification of accounts using known compromised passwords - Information disclosure - Confirmation of sensitive value existence without viewing actual data - Increased attack surface - Default permissions automatically expose all deployments using recommended settings

The risk is particularly high for password fields, where attackers can cross-reference publicly available hash databases to identify vulnerable accounts.

Summary

A stored cross-site scripting (XSS) vulnerability exists that allows users with upload files and edit item permissions to inject malicious JavaScript through the Block Editor interface. Attackers can bypass Content Security Policy (CSP) restrictions by combining file uploads with iframe srcdoc attributes, resulting in persistent XSS execution.

Details

The vulnerability arises from insufficient sanitization in the Block Editor interface when processing JSON content containing HTML elements. The attack requires two permissions: - upload files - To upload malicious JavaScript files - edit item - To create or modify content with the Block Editor

Attack Vector:

1. JavaScript File Upload: Attackers upload a malicious JavaScript file via the files endpoint, obtaining a file ID accessible through the assets directory

2. Block Editor Exploitation: Using a JSON field with Block Editor interface, attackers inject raw HTML containing an iframe with srcdoc attribute that references the uploaded file

3. CSP Bypass: The iframe srcdoc technique circumvents existing CSP protections by creating a new document context that loads the uploaded script

The payload is injected through direct API manipulation (PATCH request) to bypass client-side validation, targeting the Block Editor's paragraph data structure within the JSON content field.

Impact

This vulnerability enables: - Persistent XSS - Malicious scripts execute whenever affected content is viewed - Session hijacking - Access to authentication tokens and cookies of users viewing the content - Administrative compromise - If administrators view infected content, their elevated privileges can be exploited - CSP bypass - Demonstrates ineffective security controls, potentially affecting other protections - Data exfiltration - Ability to steal sensitive information displayed in the application - Phishing attacks - Injection of convincing fake login forms or malicious redirects

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 testcollection. 2. Add a field called secretfield. 3. Assign a role with read permissions specifically tied to secretfield. 4. Remove the secretfield from the collection. 5. Create a new field with the exact same name secretfield. 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.

Summary

A vulnerability exists in the file update mechanism which allows an unauthenticated actor to modify existing files with arbitrary contents (without changes being applied to the files' database-resident metadata) and / or upload new files, with arbitrary content and extensions, which won't show up in the Directus UI.

Details

Directus exposes the CRUD operations for uploading or handling files under the /files route.

The endpoint handler is responsible for updating an existing file identified by the provided primary key specified through the pk parameter. Primary keys are UUID values such as /files/927b3abf-fb4b-4c66-bdaa-eb7dc48a51cb. Here the filenamedisk value is never sanitized, it's possible to pass a path containing traversal sequences (../) through it, but a fully arbitrary file write is not possible in case the "local" storage handler is used. (Other storage implementations haven't been checked during the research process). The packages/storage-driver-local/src/index.ts file defines two relevant functions: write and fullpath.

The write method uses the fullPath method to create the absolute path for the to-be-created file. The join method is used to create the final path string. As the fullPath method uses join to create a relative path starting with the separator to be added under the download dir, this call normalizes the path and further upwards traversal is not possible during the write operation. With that being said, it is still possible, to make the system "ignore" the temp prefix given to the file, resulting in an arbitrarily named file being placed in the upload folder.

As a summary for the vulnerability:

- It is possible, to change the contents of an existing file, as an existing UUID can be specified as the file name - The metadata won't change, so the mime type cannot be modified - This also makes the changes happen "silently", without directus knowing about the changes - A new, previously non-existent file can be created with arbitrary contents - The file won't show up in on the Directus UI, it can only be seen through other means (such as shell access) - An extension MUST be defined for the file to be modified - This prevents us from uploading executables or malware with no extensions, but these wouldn't be executable either way

Recommendations for fixing the vulnerability can be found in later chapters.

Requirements

As providing a primary key is required for successful exploitation, at least one asset with a known UUID must be available for an attacker. This can usually be achieved by browsing an application that uses the given Directus instance to provide images.

Naturally, the instance needs to be accessible over the network used by the attacker as well.

Once network access and knowledge of at least one file UUID is available for the attacker, exploitation can be done by sending a single request.

Potential impacts

The impact of successful exploitation is highly dependent on how Directus is set up to be used by a different application. Many different configurations can be created, but the following are likely the most noteworthy:

1. Setting up a phishing site

SVGs can be used to set up very sophisticated looking pages, as it allows the embedding of HTML, CSS and scripts. The issue is once again with the default-src: none CSP settings. This setting prevents the use of CSS in the SVG file, so the created page will look strange.

While the page obviously looks strange, it's important to notice that since the domain checks out, the browser could fill out the login forms, making for a much more convincing page as shown below:

An error message can be used to make it look like an error in the system!

2. Server serves files directly from the upload directory:

In this setup, a server such ash nginx serves files in a static manner. The served files are loaded from a "public" folder made accessible through Directus as it's recommended in the files API docs. Quoting: "make a public folder and allow access to this", except the upload folder is directly served by the server:

Since the files loaded by the server are sourced directly from the file storage, the arbitrary file write might allow an attacker to upload a webshell into the folder, giving it an arbitrary file extension. As the extension checks out as a valid PHP file for instance, and the contents are correct code, an attacker can achieve unauthenticated code execution on the server.

3. Poisoning hosted files

The previous examples focused on active exploitation, but it's important to mention that the vulnerability allows for arbitrary changes in files. This can be used for many different attack primitives. Let's consider the following scenario: Directus is used not only to serve contents on a company's web page, but internally as well. Onboarding documents for new entries are hosted on the instance. Manuals with links to internal services are provided through PDF files. If the file can be accessed and modified by an attacker, it would be trivial to set up a spoofed instance which receives credentials for internal services but redirects to the original, internal service right after.

Credits

The bug was discovered by Zombor Máté, a security researcher at PCA Cyber Security (https://pcacybersecurity.com/)

Summary

Directus Flows with a manual trigger are not validating whether the user triggering the Flow has permissions to the items provided as payload to the Flow. Depending on what the Flow is set up to do this can lead to the Flow executing potential tasks on the attacker's behalf without authenticating.

Impact

Bad actors could execute the manual trigger Flows without authentication, or access rights to the said collection(s) or item(s).

Users with manual trigger Flows configured are impacted as these endpoints do not currently validate if the user has read access to directusflows or to the relevant collection/items. The manual trigger Flows should have tighter security requirements as compared to webhook Flows where users are expected to perform do their own checks.

Workarounds Users have to implement permission checks for read access to Flows and read access to relevant collection/items.

Summary

The exact Directus version number is incorrectly being used as OpenAPI Spec version this means that it is being exposed by the /server/specs/oas endpoint without authentication.

Impact

With the exact version information a malicious attacker can look for known vulnerabilities in Directus core or any of its shipped dependencies in that specific running version.

Summary

When using Directus Flows with the WebHook trigger, all incoming request details are logged including security sensitive data like access and refresh tokens in cookies.

Impact

Malicious admins with access to the logs can hijack the user sessions within the token expiration time of them triggering the Flow.

Summary

When using Directus Flows to handle CRUD events for users it is possible to log the incoming data to console using the "Log to Console" operation and a template string.

Impact

Malicious admins can log sensitive data from other users when they are created or updated.

Workarounds Avoid logging sensitive data to the console outside the context of development.

Summary When sharing an item, user can specify an arbitrary role. It allows user to use a higher-privileged role to see fields that otherwise the user should not be able to see.

Details Specifying role on share should be available only for admins. The current flow has a security flaw.

Each other role should allow to share only in the context of the same role. As there is no role hierarchy in Directus, it is impossible to tell which role is higher or lower, so only admins should be able to specify the role for share.

Optionally, instead of specifying a role, shareer should be able to specify which fields (limited to fields shareer sees) are available on shared item. Similarily to import.

shareer - a person that creates a share link to item

PoC 1. Create a collection with a secret field. 2. Create role A that sees the secret field 3. Create role B that does not see the secret field, but can use share feature. 4. Create item with secret field filled. 5. Use account with role B to share the object as role A and gain unauthorized access to secret value.

Here's video example: https://www.youtube.com/watch?v=DbV4IxbWzN4 I had to upload it to YouTube, because GitHub allows only 10MB videos.

Impact Impacted are instances that use the share feature and have specific roles hierarchy and fields that are not visible for certain roles.