Package Instance

Directus: GraphQL Alias Amplification Denial of Service Due to Missing Query Cost/Complexity Limits
### Summary

Directus' GraphQL endpoints (`/graphql` and `/graphql/system`) did not deduplicate resolver invocations within a single request. An authenticated user could exploit GraphQL aliasing to repeat an expensive relational query many times in a single request, forcing the server to execute a large number of independent complex database queries concurrently, multiplying database load linearly with the number of aliases. The existing token limit on GraphQL queries still permitted enough aliases for significant resource exhaustion, while the relational depth limit applied per alias without reducing the total number executed. Rate limiting is disabled by default, meaning no built-in throttle prevented this from causing CPU, memory, and I/O exhaustion that could degrade or crash the service. Any authenticated user, including those with minimal read-only permissions, could trigger this condition.

### Fix

A request-scoped resolver deduplication mechanism was introduced and applied broadly across all GraphQL read resolvers, both system and items endpoints. When multiple aliases in a single request invoke the same resolver with identical arguments, only the first call executes; all subsequent aliases share its result. This eliminates the amplification factor regardless of how many aliases a query contains.

### Impact

- **Service degradation or outage:** Concurrent complex database queries exhaust the connection pool and server resources, affecting all users
- **Low privilege required:** Any authenticated user, including those with read-only access to a single collection, can trigger this condition
- **Linear scaling:** Impact scales with the number of aliases and depth of relational queries
- **Compounded by concurrency:** Multiple simultaneous requests multiply the effect further

Directus' exact version number is exposed by the OpenAPI Spec
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.

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.

Directus's S3 assets become unavailable after a burst of HEAD requests
There's some tools that use Directus to sync content and assets.
Some of those tools use HEAD method, like Shopify, to check the existence of files.
Although, when making many HEAD requests at once, at some point, all assets are being served as 403.

Directus: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses in File Import
### Summary
A Server-Side Request Forgery (SSRF) protection bypass has been identified and fixed in Directus. The IP address validation mechanism used to block requests to local and private networks could be circumvented using IPv4-Mapped IPv6 address notation.

### Details
Directus implements an IP deny-list to prevent server-side requests to internal/private network ranges. The validation logic failed to normalize IPv4-Mapped IPv6 addresses (e.g., the IPv6 representation of `127.0.0.1`) before checking them against the deny-list. Because the deny-list check did not recognize these mapped addresses as equivalent to their IPv4 counterparts, an attacker could bypass the restriction while the underlying HTTP client and operating system still resolved and connected to the intended private target.

This has been fixed by adding a normalization step that converts IPv4-Mapped IPv6 addresses to their canonical IPv4 form prior to validation.

### Impact
An authenticated user (or an unauthenticated user if public file-import permissions are enabled) could exploit this bypass to perform SSRF attacks against internal services on the same host (databases, caches, internal APIs) or cloud instance metadata endpoints (e.g., AWS/GCP/Azure IMDS).

Directus's webhook trigger flows can leak sensitive data
### Describe the Bug

 In Directus, when a **Flow** with the "_Webhook_" trigger and the "_Data of Last Operation_" 
 response body encounters a ValidationError thrown by a failed condition operation, the API 
 response includes sensitive data. This includes environmental variables, sensitive API keys, 
 user accountability information, and operational data.

This issue poses a significant security risk, as any unintended exposure of this data could  lead to potential misuse.

![Image](https://github.com/user-attachments/assets/fb894347-cd10-4e79-9469-8fc1b2289794)
![Image](https://github.com/user-attachments/assets/a20337a2-005f-4cfd-ba30-fc5f579ed6c4)
![Image](https://github.com/user-attachments/assets/9b776248-4a20-46f0-92a4-3760d8e53df9)


### To Reproduce

**Steps to Reproduce:**
1. Create a Flow in Directus with:
   - Trigger: Webhook
   - Response Body: Data of Last Operation
2. Add a condition that is likely to fail.
3. Trigger the Flow with any input data that will fail the condition.
4. Observe the API response, which includes sensitive information like:
   - Environmental variables (`$env`)
   - Authorization headers
   - User details under `$accountability`
   - Previous operational data.

**Expected Behavior:**
In the event of a ValidationError, the API response should only contain relevant error messages  and details, avoiding the exposure of sensitive data.

**Actual Behavior:**
The API response includes sensitive information such as:
- Environment keys (`FLOWS_ENV_ALLOW_LIST`)
- User accountability (`role`, `user`, etc.)
- Operational logs (`current_payments`, `$last`), which might contain private details.

Directus: GraphQL Schema SDL Disclosure Setting
## Summary

When `GRAPHQL_INTROSPECTION=false` is configured, Directus correctly blocks standard GraphQL introspection queries (`__schema`, `__type`). However, the `server_specs_graphql` resolver on the `/graphql/system` endpoint returns an equivalent SDL representation of the schema and was not subject to the same restriction. This allowed the introspection control to be bypassed, exposing schema structure (collection names, field names, types, and relationships) to unauthenticated users at the public permission level, and to authenticated users at their permitted permission level.

## Impact

Administrators who set `GRAPHQL_INTROSPECTION=false` to hide schema structure from clients would have had a false sense of security, as equivalent schema information remained accessible via the SDL endpoint without authentication.

## Credit

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

Directus: Open Redirect via Parser Bypass in OAuth2/SAML Authentication Flow
### Summary

An open redirect vulnerability exists in the login redirection logic. The `isLoginRedirectAllowed` function fails to correctly identify certain malformed URLs as external, allowing attackers to bypass redirect allow-list validation and redirect users to arbitrary external domains upon successful authentication.

### Details

A parser differential exists between the server-side URL validation logic and how modern browsers interpret URL path segments containing backslashes. Specifically, certain URL patterns are incorrectly classified as safe relative paths by the server, but are normalized by browsers into external domain references.

This is particularly impactful in SSO authentication flows (e.g., OAuth2 providers), where an attacker can craft a login URL that redirects the victim to an attacker-controlled site immediately after successful authentication, without any visible indication during the login process.

### Impact

- **Phishing:** Users may be silently redirected to attacker-controlled sites impersonating legitimate services after authenticating.
- **Credential/token theft:** The redirect can be chained to capture OAuth tokens or authorization codes.
- **Trust erosion:** Users lose confidence in the application after being redirected to unexpected domains post-login.

Directus allows unauthenticated file upload and file modification due to lacking input sanitization
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.

Directus: Missing Cross-Origin Opener Policy
## Summary

Directus's Single Sign-On (SSO) login pages lacked a `Cross-Origin-Opener-Policy` (COOP) HTTP response header. Without this header, a malicious cross-origin window that opens the Directus login page retains the ability to access and manipulate the `window` object of that page. An attacker can exploit this to intercept and redirect the OAuth authorization flow to an attacker-controlled OAuth client, causing the victim to unknowingly grant access to their authentication provider account (e.g. Google, Discord).

## Impact

A successful attack allows the attacker to obtain an OAuth access token for the victim's third-party identity provider account. Depending on the scopes authorized, this can lead to:
- Unauthorized access to the victim's linked identity provider account
- Account takeover of the Directus instance if the attacker can authenticate using the stolen credentials or provider session

## Patches

This issue has been addressed by adding the `Cross-Origin-Opener-Policy: same-origin` HTTP response header to SSO-related endpoints. This header instructs the browser to place the page in its own browsing context group, severing any reference the opener window may hold.

## Workarounds

Users who are unable to upgrade immediately can mitigate this vulnerability by configuring their reverse proxy or web server to add the following HTTP response header to all Directus responses: `Cross-Origin-Opener-Policy: same-origin`

Suspended Directus user can continue to use session token to access API
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.

Directus is vulnerable to sensitive data exposure as user data is not being redacted when logged
When using Directus Flows to handle CRUD events for users it is possible to log the incoming data to console using the "Log to Console" operation and a template string.

Directus tokens are not redacted in flow logs, exposing session credentials to all admin
When using Directus Flows with the WebHook trigger, all incoming request details are logged including security sensitive data like access and refresh tokens in cookies.

Directus is Vulnerable to Stored Cross-site Scripting
A stored cross-site scripting (XSS) vulnerability exists that allows users with `upload files` and `edit item` permissions to inject malicious JavaScript through the Block Editor interface. Attackers can bypass Content Security Policy (CSP) restrictions by combining file uploads with iframe srcdoc attributes, resulting in persistent XSS execution.

Directus's S3 assets become unavailable after a burst of malformed transformations
When making many malformed transformation requests at once, at some point, all assets are being served as 403.