deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-38hg-ww64-rrwc
Package: directus (NPM)
Severity: HIGH (CVSS 8.1)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-863: Incorrect Authorization
Vulnerable versions: < 11.17.0
Patched in: 11.17.0

Summary: Directus: Authenticated Users Can Extract Concealed Fields via Aggregate Queries

Details:
### Summary

Aggregate functions (`min`, `max`) applied to fields with the `conceal` special type incorrectly return raw database values instead of the masked placeholder. When combined with `groupBy`, any authenticated user with read access to the affected collection can extract concealed field values, including static API tokens and two-factor authentication secrets from `directus_users`.

### Details

Fields marked with `conceal` are protected by payload processing logic that replaces real values with a masked placeholder on read. This protection works correctly for standard item queries, but aggregate query results are structured differently, operations are nested under their function name rather than appearing as flat field keys. The masking logic does not account for this nested structure, causing it to silently skip concealed fields in aggregate responses and return their raw values to the client.

### Impact

- **Account Takeover** An authenticated attacker can harvest static API tokens for all users, including administrators, enabling immediate authentication as any account without credentials.

- **2FA Bypass** TOTP seeds stored in directus_users can similarly be extracted, allowing an attacker to bypass two-factor authentication for any account.
GitHub Security Advisory: GHSA-6q22-g298-grjh
Package: directus (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 11.17.0
Patched in: 11.17.0

Summary: Directus: Unauthenticated Denial of Service via GraphQL Alias Amplification of Expensive Health Check Resolver

Details:
## Summary

The GraphQL specification permits a single query to repeat the same field multiple times using aliases, with each alias resolved independently by default. Directus did not deduplicate resolver invocations within a single request, meaning each alias triggered a full, independent execution of the underlying resolver.

The health check resolver ran all backend checks (database connectivity, cache, storage writes, and SMTP verification) on every invocation. Combined with unauthenticated access to the system GraphQL endpoint, this allowed an attacker to amplify resource consumption significantly from a single HTTP request, exhausting the database connection pool, storage I/O, and SMTP connections.

## 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 an attacker includes in a query.

## Impact

- **Service degradation or outage:** Database connection pool exhaustion prevents all Directus operations for all users
- **Storage I/O saturation:** Concurrent file writes can overwhelm disk I/O
- **SMTP resource exhaustion:** Concurrent SMTP verification calls may overwhelm the mail server
- **No authentication required:** Any network-accessible attacker can trigger this condition
- **Single-request impact:** A single request is sufficient to cause significant resource consumption

## Credit

This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).
GitHub Security Advisory: GHSA-ph52-67fq-75wj
Package: directus (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 11.17.0
Patched in: 11.17.0

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

Details:
### 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
GitHub Security Advisory: GHSA-mvv8-v4jj-g47j
Package: directus (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: < 11.17.0
Patched in: 11.17.0

Summary: Directus: Sensitive fields exposed in revision history

Details:
### Summary

Directus stores revision records (in `directus_revisions`) whenever items are created or updated. Due to the revision snapshot code not consistently calling the `prepareDelta` sanitization pipeline, sensitive fields (including user tokens, two-factor authentication secrets, external auth identifiers, auth data, stored credentials, and AI provider API keys) could be stored in plaintext within revision records.

### Impact
Any user or service account with read access to `directus_revisions` (or flow logs) could retrieve values for fields that are supposed to be concealed or encrypted at rest, including:
- `token`, `tfa_secret`, `external_identifier`, `auth_data`, `credentials`
- `ai_openai_api_key`, `ai_anthropic_api_key`, `ai_google_api_key`, `ai_openai_compatible_api_key`

This could lead to account takeover (via stolen tokens or 2FA secrets) or unauthorized use of third-party API keys stored against users.

### Affected code paths

1. **Item create/update revisions** The data (snapshot) field written to directus_revisions was not processed through prepareDelta, so concealed/encrypted fields were stored without redaction. Relational fields were also included, which should have been excluded.
2. **Authentication service** When a user was auto-suspended after repeated failed login attempts, the revision record was created with the raw user object (including all sensitive fields) rather than the sanitized delta.
GitHub Security Advisory: GHSA-qqmv-5p3g-px89
Package: directus (NPM)
Severity: HIGH (CVSS 7.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 11.16.1
Patched in: 11.16.1

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

Details:
## 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).
GitHub Security Advisory: GHSA-wv3h-5fx7-966h
Package: directus (NPM)
Severity: HIGH (CVSS 7.7)
CWE: CWE-20: Improper Input Validation, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 11.16.0
Patched in: 11.16.0

Summary: Directus: SSRF Protection Bypass via IPv4-Mapped IPv6 Addresses in File Import

Details:
### 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).
GitHub Security Advisory: GHSA-wxwm-3fxv-mrvx
Package: directus (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 11.16.1
Patched in: 11.16.1

Summary: Directus: GraphQL Schema SDL Disclosure Setting

Details:
## 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).
GitHub Security Advisory: GHSA-cf45-hxwj-4cfj
Package: directus (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-20: Improper Input Validation, CWE-184: Incomplete List of Disallowed Inputs, CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 11.16.1
Patched in: 11.16.1

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

Details:
### 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.
GitHub Security Advisory: GHSA-q75c-4gmv-mg9x
Package: directus (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 11.16.1
Patched in: 11.16.1

Summary: Directus: Open Redirect in Admin 2FA Setup Page

Details:
### Summary

Directus is vulnerable to an Open Redirect via the redirect query parameter on the `/admin/tfa-setup` page. When an administrator who has not yet configured Two-Factor Authentication (2FA) visits a crafted URL, they are presented with the legitimate Directus 2FA setup page. After completing the setup process, the application redirects the user to the attacker-controlled URL specified in the `redirect` parameter without any validation.

This vulnerability could be used in phishing attacks targeting Directus administrators, as the initial interaction occurs on a trusted domain.

### Credits
Discovered by Neo by ProjectDiscovery (https://neo.projectdiscovery.io/)
GitHub Security Advisory: GHSA-393c-p46r-7c95
Package: directus (NPM)
Severity: HIGH (CVSS 8.5)
CWE: CWE-284: Improper Access Control, CWE-639: Authorization Bypass Through User-Controlled Key, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
Vulnerable versions: < 11.17.0
Patched in: 11.17.0

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

Details:
## 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.
GitHub Security Advisory: GHSA-8m32-p958-jg99
Package: directus (NPM)
Severity: HIGH (CVSS 8.7)
CWE: CWE-346: Origin Validation Error, CWE-693: Protection Mechanism Failure
Vulnerable versions: < 11.17.0
Patched in: 11.17.0

Summary: Directus: Missing Cross-Origin Opener Policy

Details:
## 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`
GitHub Security Advisory: GHSA-5226-3rvg-hp4x
Package: fast-filesystem-mcp (NPM)
Severity: LOW (CVSS 6.3)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: <= 3.5.0
Patched in: unpatched

Summary: fast-filesystem-mcp is vulnerable to command injection through handleGetDiskUsage function

Details:
A security flaw has been discovered in efforthye fast-filesystem-mcp up to 3.5.1. The affected element is the function handleGetDiskUsage of the file src/index.ts. Performing a manipulation results in command injection. The attack is possible to be carried out remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
GitHub Security Advisory: GHSA-5qhv-x9j4-c3vm
Package: @mobilenext/mobile-mcp (NPM)
Severity: HIGH (CVSS 8.3)
CWE: CWE-939: Improper Authorization in Handler for Custom URL Scheme
Vulnerable versions: < 0.0.50
Patched in: 0.0.50

Summary: @mobilenext/mobile-mcp: Arbitrary Android Intent Execution via mobile_open_url

Details:
### Summary

The `mobile_open_url` tool in mobile-mcp passes user-supplied URLs directly to Android's intent system without any scheme validation, allowing execution of arbitrary Android intents, including USSD codes, phone calls, SMS messages, and content provider access.

### Details

The vulnerable code passes URLs directly to `adb shell am start -a android.intent.action.VIEW -d <url>` without checking the URL scheme. This can enable malicious schemes such as `tel:`, `sms:`, `mailto:`, `content://`, and `market://` to be executed.

Since MCP servers are designed to be operated by AI agents, which are vulnerable to prompt injection attacks, a malicious document or website could inject instructions that cause the AI to execute dangerous intents on a connected mobile device.

### Impact

An attacker via prompt injection can:
- Execute USSD codes (e.g., `tel:*#06#` to display IMEI - confirmed on Pixel 7a, behavior varies by device; or device-specific factory reset codes)
- Initiate phone calls to premium rate numbers
- Draft SMS messages with attacker-controlled content
- Access content providers (contacts, SMS, call logs)
- Open app installation prompts

### Proof of Concept
```json
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"mobile_open_url","arguments":{"device":"<id>","url":"tel:*#06#"}}}
```

Result: IMEI displayed on device.
```json
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"mobile_open_url","arguments":{"device":"<id>","url":"sms:[PII_REDACTED]?body=HACKED"}}}
```

Result: SMS app opens with a pre-filled message.

### Remediation

Upgrade to version 0.0.50 or later, which restricts `mobile_open_url` to `http://` and `https://` schemes by default. Users who require other URL schemes can opt in by setting `MOBILEMCP_ALLOW_UNSAFE_URLS=1`.
GitHub Security Advisory: GHSA-prmx-7v35-7q82
Package: a11y-mcp (NPM)
Severity: LOW (CVSS 5.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.0.5
Patched in: 1.0.5

Summary: a11y-mcp: Server-Side Request Forgery (SSRF) vulnerability in A11yServer function

Details:
A vulnerability was found in priyankark a11y-mcp up to 1.0.5. This vulnerability affects the function A11yServer of the file src/index.js. The manipulation results in server-side request forgery. The attack must be initiated from a local position. The exploit has been made public and could be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. 

Upgrading to version 1.0.6 is able to resolve this issue. The patch is identified as e3e11c9e8482bd06b82fd9fced67be4856f0dffc. It is recommended to upgrade the affected component. The vendor acknowledged the issue but provides additional context for the CVSS rating: "a11y-mcp is a local stdio MCP server - it has no HTTP endpoint and is not network-accessible. The caller is always the local user or an LLM acting on their behalf with user approval."
GitHub Security Advisory: GHSA-5jg4-p4qw-cgfr
Package: @stablelib/cbor (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 2.0.3
Patched in: 2.0.3

Summary: @stablelib/cbor: Stack exhaustion Denial of Service via deeply nested CBOR arrays, maps, or tags

Details:
### Summary

`@stablelib/cbor` decodes nested CBOR structures recursively and does not enforce a maximum nesting depth. A sufficiently deep attacker-controlled CBOR payload can therefore crash decoding with `RangeError: Maximum call stack size exceeded`.

### Details

The decoder processes arrays, maps, and tagged values through recursive calls. Each nested container causes another descent into `_decodeValue()` until a leaf value is reached.

There is no depth limit, no iterative fallback, and no protection against pathological nesting. An attacker can therefore supply a payload made of thousands of nested arrays, maps, or tags and force the decoder to recurse until the JavaScript call stack is exhausted.

### PoC

```js
import { decode } from "@stablelib/cbor";

const depth = 12000;
const payload = new Uint8Array(depth + 1);

// Build [[[...[null]...]]]
payload.fill(0x81, 0, depth); // array(1)
payload[depth] = 0xf6;        // null

decode(payload);
// RangeError: Maximum call stack size exceeded
```

### Impact

Any application that decodes attacker-controlled CBOR can be forced into a reliable denial of service with a single crafted payload.

The immediate result is an exception during decoding. In services that do not catch that exception safely, the request fails and the worker or process handling the decode may terminate.


### Solution

Upgrade to version 2.0.4. The stack is limited to 128 by default, but can be configured using the `maxDepth` option. Catch the `CBORMaxDepthExceededError` exception.