Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
56 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 12.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSRF protection on Directus's file-import-from-URL feature can be bypassed using the address 0.0.0.0. While 127.0.0.1 and other internal addresses are denied, 0.0.0.0 is not added to the blocklist. On Linux and macOS, connecting to 0.0.0.0 reaches localhost, so an authenticated user with file-upload rights can make the server fetch internal services and retrieve the response as a downloadable file (full-read SSRF). Affected Versions - Affected: Directus <= 12.0.0 (confirmed on directus/directus:latest, v11.17.3, with default configuration) - Patched: Directus = 12.0.0 Details Directus uses a deny-list config, IMPORTIPDENYLIST, whose default value is ['0.0.0.0', '169.254.169.254']. The issue is in how api/src/request/is-denied-ip.ts processes this list. When it encounters the entry 0.0.0.0, it treats it as a special keyword meaning "block all local network interfaces," but it never blocks the literal address 0.0.0.0 itself. The handler sets the network-interface flag and…
Recommended action: Upgrade to 12.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Aggregate functions (min, max) applied to fields with the conceal special type incorrectly return raw database values instead of the masked placeholder. When combined with groupBy, any authenticated user with read access to the affected collection can extract concealed field values, including static API tokens and two-factor authentication secrets from directususers. Details Fields marked with conceal are protected by payload processing logic that replaces real values with a masked placeholder on read. This protection works correctly for standard item queries, but aggregate query results are structured differently, operations are nested under their function name rather than appearing as flat field keys. The masking logic does not account for this nested structure, causing it to silently skip concealed fields in aggregate responses and return their raw values to the client. Impact - Account Takeover An authenticated attacker can harvest static API tokens for all users,…
Recommended action: Upgrade to 11.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GraphQL specification permits a single query to repeat the same field multiple times using aliases, with each alias resolved independently by default. Directus did not deduplicate resolver invocations within a single request, meaning each alias triggered a full, independent execution of the underlying resolver. The health check resolver ran all backend checks (database connectivity, cache, storage writes, and SMTP verification) on every invocation. Combined with unauthenticated access to the system GraphQL endpoint, this allowed an attacker to amplify resource consumption significantly from a single HTTP request, exhausting the database connection pool, storage I/O, and SMTP connections. Fix A request-scoped resolver deduplication mechanism was introduced and applied broadly across all GraphQL read resolvers, both system and items endpoints. When multiple aliases in a single request invoke the same resolver with identical arguments, only the first call executes; all…
Recommended action: Upgrade to 11.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Directus' GraphQL endpoints (/graphql and /graphql/system) did not deduplicate resolver invocations within a single request. An authenticated user could exploit GraphQL aliasing to repeat an expensive relational query many times in a single request, forcing the server to execute a large number of independent complex database queries concurrently, multiplying database load linearly with the number of aliases. The existing token limit on GraphQL queries still permitted enough aliases for significant resource exhaustion, while the relational depth limit applied per alias without reducing the total number executed. Rate limiting is disabled by default, meaning no built-in throttle prevented this from causing CPU, memory, and I/O exhaustion that could degrade or crash the service. Any authenticated user, including those with minimal read-only permissions, could trigger this condition. Fix A request-scoped resolver deduplication mechanism was introduced and applied broadly across…
Recommended action: Upgrade to 11.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact Any user or service account with read access to directusrevisions (or flow logs) could retrieve values for fields that are supposed to be concealed or encrypted at rest, including: - token, tfasecret, externalidentifier, authdata, credentials - aiopenaiapikey, aianthropicapikey, aigoogleapikey, aiopenaicompatibleapikey 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 1. Item create/update revisions The data (snapshot) field written to directusrevisions was not…
Recommended action: Upgrade to 11.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Directus' TUS resumable upload endpoint (/files/tus) allows any authenticated user with basic file upload permissions to overwrite arbitrary existing files by UUID. The TUS controller performs only collection-level authorization checks, verifying the user has some permission on directusfiles, but never validates item-level access to the specific file being replaced. As a result, row-level permission rules (e.g., "users can only update their own files") are completely bypassed via the TUS path while being correctly enforced on the standard REST upload path. Impact - Arbitrary file overwrite: Any authenticated user with basic TUS upload permissions can overwrite any file in directusfiles by UUID, regardless of row-level permission rules. - Permanent data loss: The victim file's original stored bytes are deleted from storage and replaced with attacker-controlled content. - Metadata corruption: The victim file's database record is updated with the attacker's filename, type, and…
Recommended action: Upgrade to 11.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) protection bypass has been identified and fixed in Directus. The IP address validation mechanism used to block requests to local and private networks could be circumvented using IPv4-Mapped IPv6 address notation. Details Directus implements an IP deny-list to prevent server-side requests to internal/private network ranges. The validation logic failed to normalize IPv4-Mapped IPv6 addresses (e.g., the IPv6 representation of 127.0.0.1) before checking them against the deny-list. Because the deny-list check did not recognize these mapped addresses as equivalent to their IPv4 counterparts, an attacker could bypass the restriction while the underlying HTTP client and operating system still resolved and connected to the intended private target. This has been fixed by adding a normalization step that converts IPv4-Mapped IPv6 addresses to their canonical IPv4 form prior to validation. Impact An authenticated user (or an unauthenticated user if…
Recommended action: Upgrade to 11.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When GRAPHQLINTROSPECTION=false is configured, Directus correctly blocks standard GraphQL introspection queries (schema, type). However, the serverspecsgraphql resolver on the /graphql/system endpoint returns an equivalent SDL representation of the schema and was not subject to the same restriction. This allowed the introspection control to be bypassed, exposing schema structure (collection names, field names, types, and relationships) to unauthenticated users at the public permission level, and to authenticated users at their permitted permission level. Impact Administrators who set GRAPHQLINTROSPECTION=false to hide schema structure from clients would have had a false sense of security, as equivalent schema information remained accessible via the SDL endpoint without authentication. Credit This vulnerability was discovered and reported by bugbunny.ai.
Recommended action: Upgrade to 11.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An open redirect vulnerability exists in the login redirection logic. The isLoginRedirectAllowed function fails to correctly identify certain malformed URLs as external, allowing attackers to bypass redirect allow-list validation and redirect users to arbitrary external domains upon successful authentication. Details A parser differential exists between the server-side URL validation logic and how modern browsers interpret URL path segments containing backslashes. Specifically, certain URL patterns are incorrectly classified as safe relative paths by the server, but are normalized by browsers into external domain references. This is particularly impactful in SSO authentication flows (e.g., OAuth2 providers), where an attacker can craft a login URL that redirects the victim to an attacker-controlled site immediately after successful authentication, without any visible indication during the login process. Impact - Phishing: Users may be silently redirected to…
Recommended action: Upgrade to 11.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Directus is vulnerable to an Open Redirect via the redirect query parameter on the /admin/tfa-setup page. When an administrator who has not yet configured Two-Factor Authentication (2FA) visits a crafted URL, they are presented with the legitimate Directus 2FA setup page. After completing the setup process, the application redirects the user to the attacker-controlled URL specified in the redirect parameter without any validation. This vulnerability could be used in phishing attacks targeting Directus administrators, as the initial interaction occurs on a trusted domain. Credits Discovered by Neo by ProjectDiscovery (https://neo.projectdiscovery.io/)
Recommended action: Upgrade to 11.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A broken access control vulnerability was identified in the Directus file management API that allows authenticated users to overwrite files belonging to other users by manipulating the filenamedisk parameter. Details 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. Impact - Unauthorized File Overwrite: Attackers can replace legitimate files with malicious content, creating significant risk of malware propagation and data corruption. - Remote Code Execution: If the storage backend is shared with the extensions location, attackers can deploy malicious extensions that execute arbitrary code when loaded. - Data Integrity Compromise: Files can be tampered with or replaced without visible indication in the application interface. Mitigation The filenamedisk…
Recommended action: Upgrade to 11.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Directus's Single Sign-On (SSO) login pages lacked a Cross-Origin-Opener-Policy (COOP) HTTP response header. Without this header, a malicious cross-origin window that opens the Directus login page retains the ability to access and manipulate the window object of that page. An attacker can exploit this to intercept and redirect the OAuth authorization flow to an attacker-controlled OAuth client, causing the victim to unknowingly grant access to their authentication provider account (e.g. Google, Discord). Impact A successful attack allows the attacker to obtain an OAuth access token for the victim's third-party identity provider account. Depending on the scopes authorized, this can lead to: - Unauthorized access to the victim's linked identity provider account - Account takeover of the Directus instance if the attacker can authenticate using the stolen credentials or provider session Patches This issue has been addressed by adding the Cross-Origin-Opener-Policy: same-origin…
Recommended action: Upgrade to 11.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 11.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Security Advisory: Open Redirect in Directus SAML Authentication Summary An open redirect vulnerability exists in the Directus SAML authentication callback endpoint. The RelayState parameter is used in redirects without proper validation against an allowlist of permitted domains. Vulnerability Description During SAML authentication, the RelayState parameter is intended to preserve the user's original destination. However, while the login initiation flow validates redirect targets against allowed domains, this validation is not applied to the callback endpoint. This allows an attacker to craft a malicious authentication request that redirects users to an arbitrary external URL upon completion. The vulnerability is present in both the success and error handling paths of the callback. Impact - Phishing: Users can be redirected to attacker-controlled sites that mimic legitimate login pages - Credential theft: Chained attacks may leverage the redirect to capture OAuth tokens or…
Recommended action: Upgrade to 11.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 11.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 11.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. The following response returns a different error message when requesting a collection which does not exist. 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
Recommended action: Upgrade to 11.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 11.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 11.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 11.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 11.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 11.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 11.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Describe the Bug In Directus, when a Flow with the "Webhook" trigger and the "Data of Last Operation" response body encounters a ValidationError thrown by a failed condition operation, the API response includes sensitive data. This includes environmental variables, sensitive API keys, user accountability information, and operational data. This issue poses a significant security risk, as any unintended exposure of this data could lead to potential misuse. To Reproduce Steps to Reproduce: 1. Create a Flow in Directus with: - Trigger: Webhook - Response Body: Data of Last Operation 2. Add a condition that is likely to fail. 3. Trigger the Flow with any input data that will fail the condition. 4. Observe the API response, which includes sensitive information like: - Environmental variables ($env) - Authorization headers - User details under $accountability - Previous operational data. Expected Behavior: In the event of a ValidationError, the API response should only contain relevant…
Recommended action: Upgrade to 11.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.