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
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 32.2.0 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 32.1.1 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 32.0.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 32.0.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 28.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 LOGSTYLE 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 LOGLEVEL="raw" in the environment. 2. Send a request with the accesstoken in the query string. 3. Notice that the accesstoken in req.query is not redacted. Impact It impacts systems where the LOGSTYLE is set to raw. The accesstoken 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.
Recommended action: Upgrade to 21.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Since the user status is not checked when verifying a session token a suspended user can use the token generated in session auth mode to access the API despite their status. Details There is a check missing in verifySessionJWT to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires. PoC Create an active user Log in with that user and note the session cookie Suspend the user (and don't trigger an /auth/refresh call, as that invalidates the session Access the API with Authorization: Bearer <token Impact This weakens the security of suspending users.
Recommended action: Upgrade to 24.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If there are two overlapping policies for the update action that allow access to different fields, instead of correctly checking access permissions against the item they apply for the user is allowed to update the superset of fields allowed by any of the policies. E.g. have one policy allowing update access to fielda if the id == 1 and one policy allowing update access to fieldb if the id == 2. The user with both these policies is allowed to update both fielda and fieldb for the items with ids 1 and 2. Details Before v11, if a user was allowed to update an item they were allowed to update the fields that the single permission, that applied to that item, listed. With overlapping permissions this isn't as clear cut anymore and the union of fields might not be the fields the user is allowed to update for that specific item. The solution that this PR introduces is to evaluate the permissions for each field that the user tries to update in the validateItemAccess DB query, instead…
Recommended action: Upgrade to 23.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When setting WEBSOCKETSGRAPHQLAUTH or WEBSOCKETSRESTAUTH to "public", an unauthenticated user is able to do any of the supported operations (CRUD, subscriptions) with full admin privileges. Details Accountability for unauthenticated WebSocket requests is set to null, which used to be "public permissions" until the Permissions Policy update which now defaults that to system/admin level access. So instead of null we need to make use of createDefaultAccountability() to ensure public permissions are used for unauthenticated users. PoC 1. Start directus with 2. Subscribe using GQL or REST or do any CRUD operation on a user created collection (system tables are not reachable with crud) or 3a. Open up the data studio as any user. Observe how the subscriber gets notified on each page navigation (because the users lastpage gets updated, the password fields is properly redacted here) 3b. Observe receiving all available items from the yourcollectionname collection. Impact This impacts…
Recommended action: Upgrade to 23.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 22.1.1 or 21.0.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:…
Recommended action: Upgrade to 22.2.0 or 21.0.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There was already a reported SSRF vulnerability via file import. 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…
Recommended action: Upgrade to 17.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.