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.
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…
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.
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 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.
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 was always equal to STORAGECLOUDMAXSOCKETS making it impossible to have new connections causing assets to be inaccessible. After looking into this issue on AWS SDK I found that if the stream is requested, it needs to be consumed otherwise will hang forever. And as can be seen here the stream is not consumed, because sharp will throw an error on the invalid arguments. For example ?height=xyz The timeouts set here had no noticeable effect on tests made. PoC This can be easily reproduced with the following steps: - setup AWS S3 storage - set STORAGECLOUDMAXSOCKETS: "50" (this value is lower than default for easier reproduction) - upload a file to your project - run this file (Replace the the file…
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.
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 11.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, 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. 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 directusers preset. When the user visits the view that uses the directususers 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…
Recommended action: Upgrade to 11.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 11.2.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 11.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Comment feature has implemented a filter to prevent users from adding restricted characters, such as HTML tags. However, this filter operates on the client-side, which can be bypassed, making the application vulnerable to HTML Injection. Details The Comment feature implements a character filter on the client-side, this can be bypassed by directly sending a request to the endpoint. Example Request: Example Response: Example Result: Impact With the introduction of session cookies this issue has become exploitable as a malicious script is now able to do authenticated actions on the current users behalf.
Recommended action: Upgrade to 11.2.2 or 10.13.4 by release line, 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 11.1.0 or 10.13.3 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 11.1.0 or 10.13.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, 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 directusers preset. 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…
Recommended action: Upgrade to 10.13.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Directus =9.23.0, <=v10.5.3 improperly handles in, nin operators. It evaluates empty arrays as valid so expressions like {"role": {"in": $CURRENTUSER.somefield}} 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": $CURRENTUSER.somefield}} field validation would pass if $CURRENTUSER.somefield 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 (userroles.role is left with…
Recommended action: Upgrade to 10.6.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 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.
Recommended action: Upgrade to 10.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Currently session tokens function like the other JWT tokens where they are not actually invalidated when logging out. The directussession gets destroyed and the cookie gets deleted but if you captured the cookie value it will still work for the entire expiry time which is set to 1 day by default. Making it effectively a long lived unrevokable stateless token instead of the stateful session token it was meant to be. When authenticating a session token JWT, Directus should also check whether the associated directussession both still exists and has not expired (although the token should expire at the same time or before the session) to ensure leaked tokens are not valid indefinitely. Steps to reproduce - Copy the current session token from the cookie - Refresh and or log out - Use the saved session token to check if it is still valid Impact The lack of proper session expiration may improve the likely success of certain attacks. For example, a user might access a web site from a…
Recommended action: Upgrade to 10.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 10.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/:providerid?redirect=http://malicious-fishing-site.com, login and get taken to…
Recommended action: Upgrade to 10.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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?
Recommended action: Upgrade to 10.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 10.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 10.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It seems that any Directus installation that has websockets enabled can be crashed if the websocket server receives an invalid frame. This could probably be posted as an issue and I might even be able to put together a pull request for a fix (if only I had some extra time...), but I decided to instead post as a vulnerability just for the maintainers, since this seemingly can be used to crash any live Directus server if websockets are enabled, so public disclosure is not a good idea until the issue is fixed. Details The fix for this seems quite simple; the websocket server just needs to properly catch the error instead of crashing the server. See for example: https://github.com/websockets/ws/issues/2098 PoC - Start a fresh Directus server (using for example the compose file here: https://docs.directus.io/self-hosted/docker-guide.html). Enable websockets by setting WEBSOCKETSENABLED: 'true' environment variable. - run a separate node app somewhere else to send an invalid frame…
Recommended action: Upgrade to 10.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 10.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Access to information you should not have access to when the permissions rely on $CURRENTUSER for filtering. Details The permission filters (i.e. usercreated IS $CURRENTUSER) are not properly checked when using GraphQL subscription resulting in unauthorized users getting event on their subscription which they should not be receiving according to the permissions. This can be any collection but out-of-the box the directususers collection is configured with such a permissions filter allowing you to get updates for other users when changes happen. An example: Patches https://github.com/directus/directus/pull/19155 Workarounds Disable GraphQL Subscriptions References
Recommended action: Upgrade to 10.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue found in Directus API v.2.2.0 allows a remote attacker to cause a denial of service via a great amount of HTTP requests.
Recommended action: Upgrade to 2.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The directusrefreshtoken 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 directusrefreshtoken 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…
Recommended action: Upgrade to 9.23.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with read access to the password field in directususers can extract the argon2 password hashes by brute forcing the export functionality combined with a startswith filter. This allows the user to enumerate the password hashes. Patches The problem has been patched by preventing any hashed/concealed field to be filtered against with the startswith or other string operator. Workarounds Ensuring that no user has read access to the password field in directususers is sufficient to prevent this vulnerability. For more information If you have any questions or comments about this advisory: Open a Discussion in directus/directus Email us at security@directus.io
Recommended action: Upgrade to 9.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.