Search for packages
| purl | pkg:npm/%40directus/api@27.1.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-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-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-kugb-dwxd-6fhe
Aliases: CVE-2025-55746 GHSA-mv33-9f6j-pfmc |
Directus allows unauthenticated file upload and file modification due to lacking input sanitization ## 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 `filename_disk` 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/) |
Affected by 4 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. | ||