Search for packages
| purl | pkg:npm/%40directus/api@13.2.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
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-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 6 other vulnerabilities. Affected by 8 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 7 other vulnerabilities. Affected by 8 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-amyt-vrj6-hycd
Aliases: CVE-2024-47822 GHSA-vw58-ph65-6rxp |
Directus inserts access token from query string into logs ### Summary Access token from query string is not redacted and is potentially exposed in system logs which may be persisted. ### Details The access token in `req.query` is not redacted when the `LOG_STYLE` is set to `raw`. If these logs are not properly sanitized or protected, an attacker with access to it can potentially gain administrative control, leading to unauthorized data access and manipulation. ### PoC 1. Set `LOG_LEVEL="raw"` in the environment. 2. Send a request with the `access_token` in the query string. 3. Notice that the `access_token` in `req.query` is not redacted. ### Impact It impacts systems where the `LOG_STYLE` is set to `raw`. The `access_token` in the query could potentially be a long-lived static token. Users with impacted systems should rotate their static tokens if they were provided using query string. |
Affected by 7 other vulnerabilities. |
|
VCID-n8k6-qyn6-s7c5
Aliases: CVE-2024-39699 GHSA-8p72-rcq4-h6pw |
Directus Blind SSRF On File Import ### Summary There was already a reported SSRF vulnerability via file import. [https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h](https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h) It was fixed by resolving all DNS names and checking if the requested IP is an internal IP address. However it is possible to bypass this security measure and execute a SSRF using redirects. Directus allows redirects when importing file from the URL and does not check the result URL. Thus, it is possible to execute a request to an internal IP, for example to 127.0.0.1. However, it is blind SSRF, because Directus also uses response interception technique to get the information about the connect from the socket directly and it does not show a response if the IP address is internal (nice fix, by the way :) ). But the blindness does not fully mitigate the impact of the vulnerability. The blind SSRF is still exploitable in the real life scenarios, because there could be a vulnerable software inside of the network which can be exploited with GET request. I will show the example in the PoC. Also, you can check [HackTricks](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/ssrf-vulnerable-platforms) page with some known cases. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ ### PoC For testing I used the docker compose with the latest directus version. Here is my docker compose file ``` version: "3" services: directus: image: directus/directus:10.8.3 ports: - 8055:8055 volumes: - ./database:/directus/database - ./uploads:/directus/uploads - ./extensions:/directus/extensions environment: KEY: "redacted" SECRET: "redacted" ADMIN_EMAIL: "admin@example.com" ADMIN_PASSWORD: "redacted" DB_CLIENT: "sqlite3" DB_FILENAME: "/directus/database/data.db" ``` As a first step it is needed to setup a redirect server which will redirect the incoming request to some internal URL. I did it on my VPS with the public IP. <img width="1035" alt="image" src="https://user-images.githubusercontent.com/156416961/296198555-870898b2-7b8a-4857-a8fe-5e28e85241b0.png"> After it I setup a simple HTTP Server emulating the vulnerable application inside the internal network. It just execute any shell command provided in the cmd GET-parameter. <img width="454" alt="image" src="https://user-images.githubusercontent.com/156416961/296198963-4465fa15-c6d6-4e8c-92a0-a2ae334ba79f.png"> After it the directus import functionality was used <img width="930" alt="image" src="https://user-images.githubusercontent.com/156416961/296199457-d5d8eb2d-1ca8-442e-b1bf-15ddb0f1947d.png"> It initiates the following HTTP request ``` POST /files/import HTTP/1.1 Host: 127.0.0.1:8055 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Authorization: Bearer redacteed Content-Type: application/json Content-Length: 44 Origin: http://127.0.0.1:8055 Connection: close Referer: http://127.0.0.1:8055/admin/files/+ Cookie: directus_refresh_token=redacted Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin {"url":"http://94.103.84.233:801","data":{}} ``` It can be seen on the redirect server that the request came to it.  And we can also see the request in the localhost server (the same host as directus), which confirms the bypass and the SSRF. <img width="437" alt="image" src="https://user-images.githubusercontent.com/156416961/296201651-a9b61f5d-0ccd-4e3e-b137-e82fda8f5347.png"> And the rce_poc file was created. <img width="538" alt="image" src="https://user-images.githubusercontent.com/156416961/296201869-fed5fa94-ece5-497d-a091-c422b1f540a0.png"> ### Impact The impact is Blind SSRF. Using it an attacker can initiate HTTP GET requests to the internal network. For example, it can be used to exploit some GET-based vulnerabilities of other software in the internal network. ### Fix proposition I think there are two ways to fix this vulnerability: - Disallow redirects for the import requests - Check the Location header in the import request response if it is present. Drop the request if the Location url points to the internal IP. |
Affected by 8 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 |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||