Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
LOW severity

GHSA-56p6-qw3c-fq2g — directus

LOWFix: directus/directus@ef17993

GHSA-56p6-qw3c-fq2g is a low-severity (CVSS 3.5) CWE-672 vulnerability in directus. A fix is available for directus — see the affected versions and patch details below.

Suspended Directus user can continue to use session token to access API

Also known asCVE-2025-30351
Published
Mar 26, 2025
Updated
Sep 10, 2026
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed
Exploitation data as of Sep 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-56p6-qw3c-fq2g.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs28th percentile — riskier than 28% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-56p6-qw3c-fq2g by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

3 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

11other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
directusnpm
19Kdownloads / week
@directus/apinpm
19Kdownloads / week
@directus/typesnpm
68Kdownloads / week

Description

Summary

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.

Details

There is a check missing in verifySessionJWT to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires.

PoC

  • Create an active user
  • Log in with that user and note the session cookie
  • Suspend the user (and don't trigger an /auth/refresh call, as that invalidates the session
  • Access the API with Authorization: Bearer <token>

Impact

This weakens the security of suspending users.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
📦npmdirectus≥ 10.10.0&&< 11.5.011.5.0npm install directus@11.5.0
📦npm@directus/api≥ 18.0.0&&< 24.0.124.0.1npm install @directus/api@24.0.1
📦npm@directus/types≥ 11.0.7&&< 13.0.013.0.0npm install @directus/types@13.0.0

Affected Products

1 product · 1 configurations
Application
directusmonospace
≥ 10.10.0 && < 11.5.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for directus, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update directus to 11.5.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-56p6-qw3c-fq2g is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Summary 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. ### Details There is a check missing in `verifySessionJWT` to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires. ### PoC * Create an active user * Log in with that user and note the session cookie *
O3 Security · Impact-Aware SCA

Is GHSA-56p6-qw3c-fq2g in your dependencies?

Find it across npm, including transitive dependencies.

GHSA-56p6-qw3c-fq2g: directus (Low 3.5) | O3 Security