CVE-2025-30351

Executive Summary

CVE-2025-30351 is a vulnerability in Directus, a real-time API and App dashboard for managing SQL database content. The flaw allows a suspended user to continue accessing the API using a previously obtained session token. This occurs because the verifySessionJWT function does not check if the user account is still active. The vulnerability affects versions 10.10.0 through 11.4.x. The CVSS score is 3.5 (Low), but the security impact is significant as it undermines user suspension controls. The patch is available in version 11.5.0.

Supply Chain & Package Security

Directus is distributed as an npm package (@directus/app and @directus/api). Organizations using Directus should verify their installed version and update to 11.5.0 or later. The vulnerability is in the server-side session validation logic, not in a dependency, so no transitive dependency issues are present.

CVSS Breakdown & Threat Level

• CVSS Score: 3.5 (Low)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (valid session token from an active user)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: Low (access to data the user was authorized to see before suspension)
• Integrity Impact: None
• Availability Impact: None

Threat Level: Low. The vulnerability requires a valid session token obtained before suspension. It does not allow privilege escalation or data modification. However, it can be used to maintain unauthorized access after administrative suspension.

Deep Dive & Mechanics

The vulnerability lies in the verifySessionJWT function within Directus’s authentication module. When a user logs in via session authentication, a JSON Web Token (JWT) is issued. This token is used for subsequent API requests. The verifySessionJWT function validates the token’s signature and expiration but does not check the user’s current status (active/suspended) in the database.

Attack Flow:

1. An attacker (or malicious insider) logs into Directus with a valid account.
2. The attacker obtains a session JWT.
3. An administrator suspends the user account.
4. The attacker continues to use the same JWT to make API requests.
5. The server accepts the token because it is still valid and the user status is not re-verified.

Root Cause: Missing authorization check in verifySessionJWT. The function should query the database to ensure the user is still active before accepting the token.

Vulnerable vs. Patched Code

Vulnerable Code (pre-11.5.0):

// In verifySessionJWT function
async function verifySessionJWT(token) {
  const payload = jwt.verify(token, secret);
  // Missing: check if user is active
  return payload;
}

Patched Code (11.5.0):

// In verifySessionJWT function
async function verifySessionJWT(token) {
  const payload = jwt.verify(token, secret);
  const user = await database('directus_users').where({ id: payload.id }).first();
  if (!user || user.status !== 'active') {
    throw new InvalidTokenException('User is not active');
  }
  return payload;
}

The patch adds a database lookup to verify the user’s status. If the user is not active, the token is rejected.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Directus instance (version 10.10.0 to 11.4.x)
• A valid user account with session authentication enabled
• Ability to obtain a session token (e.g., via login)

Steps:

1. Log in to Directus as a valid user.
2. Extract the session token from the browser’s cookies or local storage (e.g., directus_session_token).
3. Wait for an administrator to suspend the user account.
4. Use the token to make API requests:

   curl -H "Authorization: Bearer <token>" https://target.directus.example/api/items/articles
   

5. The request will succeed even though the user is suspended.

Note: No public exploit code is available. This is a logic flaw, not a code injection.

Blue Team

Detection:

• Monitor for API requests from suspended users.
• Look for session tokens that are used after the user’s status changes.
• Enable audit logging in Directus to track user activity.

Prevention:

• Apply the patch by upgrading to Directus 11.5.0.
• Implement additional monitoring on user status changes.
• Use short-lived session tokens to reduce the window of opportunity.

Indicators of Compromise (IOCs)

• Session Token: A JWT token issued before user suspension that continues to work.
• API Logs: Successful API requests from a user whose status is suspended in the database.
• User Activity: Suspicious activity from accounts that should be disabled.

Log Example:

2025-04-01 12:34:56 - user_id=123 - action=read - resource=/items/articles - status=200

If user_id=123 is suspended, this is an IOC.

Detection Engineering

YARA Rule

rule Detect_Directus_Suspended_User_Access {
  meta:
    description = "Detect session token usage by suspended Directus users"
    author = "Valters IT"
    date = "2025-04-01"
    reference = "CVE-2025-30351"
  strings:
    $token_prefix = "directus_session_token"
    $user_status = "suspended"
  condition:
    $token_prefix and $user_status
}

Sigma Rule

title: Directus Suspended User Session Token Usage
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects API requests from suspended Directus users using valid session tokens
author: Valters IT
date: 2025-04-01
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-30351
logsource:
  category: application
  product: directus
detection:
  selection:
    user_status: "suspended"
    http_response_code: 200
  condition: selection
falsepositives:
  - Legitimate token reuse before suspension is applied
level: medium

Suricata Rule

alert http any any -> any any (
  msg:"CVE-2025-30351 - Directus Suspended User Session Token";
  flow:to_server;
  content:"Authorization: Bearer";
  http_header;
  sid:1000001;
  rev:1;
  reference:cve,2025-30351;
)

Remediation & Mitigation

Immediate:

• Upgrade to Directus version 11.5.0 or later.
• If upgrade is not possible, manually apply the patch to verifySessionJWT to check user status.

Long-term:

• Implement additional session validation checks.
• Use short-lived tokens (e.g., 15 minutes) and refresh tokens.
• Monitor user status changes and invalidate sessions upon suspension.
• Conduct regular security audits of authentication logic.

Workaround:

• Disable session authentication and use token-based authentication with short expiration times.
• Implement a custom middleware to check user status on every request.

Valters IT
Securing Digital Frontiers