NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

directus vulnerable to Insertion of Sensitive Information into Log FileGHSA-8vg2-wf3q-mwv7

MEDIUMFix: directus/directus@3495363

GHSA-8vg2-wf3q-mwv7 is a medium-severity (CVSS 4.2) CWE-284 vulnerability in directus. 1 public exploit or proof-of-concept reference is indexed, so weaponization risk is real. A fix is available for directus — see the affected versions and patch details below.

Also known asCVE-2023-28443
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
1 known
Exploitation data as of Nov 6, 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-8vg2-wf3q-mwv7.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs24th percentile — riskier than 24% of all scored CVEsHighest risk
0.00%0.27%0.54%0.81%0.1%0.3%May 26Sep 26Nov 26

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

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg 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.

12other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
directusnpm
35Kdownloads / week

Description

Summary

CWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The directus_refresh_token is not redacted properly from the log outputs and can be used to impersonate users without their permission.

Details

Using v9.23.1, I am seeing that the directus_refresh_token is not properly redacted as indicated by https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13

I'm classifying this as a security vulnerability because if someone has access to the log outputs, for example with a shared Cloud account or Splunk implementation, they could exchange the refresh token using /auth/refresh for an access token and use the token to perform actions on behalf of an unsuspecting user. This situation creates issues with accountability and non-repudiation because we can no longer have confidence that actions taken in the application were authorized or even performed by the logged-in user.

A couple of examples of this are:

  • A disgruntled employee deletes all of the data to get even with a target team member before logging off on their last day
  • Under the guise of their unsuspecting boss, a mischievous engineer uploads questionable images that get displayed on internal or external facing content sites

The list could go on but I think these communicate the risk of an internal threat that has access to this information 😆

PoC

  1. Set LOG_STYLE="raw" and run Directus v9.23.1

  2. Log in to the application

  3. Look at the shell output and see that directus_refresh_token is logged

    Note: This is different from the standard raw output format. I intentionally ran this with npx directus start | pino-pretty so logs would be easier to read. It can also be reproduced by running npx directus start alone.

    image

  4. Exchange the directus_refresh_token for an access_token

     curl -X POST \
   'http://0.0.0.0:8055/auth/refresh' \
   --header 'Accept: */*' \
   --header 'Cookie: directus_refresh_token=$shh'

Impact

Because this can be used to exploit other threats related to CWE-284: Improper Access Control I rank it with a Moderate severity. An insider with knowledge of this could do many mischievous things and get away with them for a long time without victims knowing about it.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmdirectusall versions9.23.3npm install directus@9.23.3

Affected Products

1 product · 1 configurations
Application
directusmonospace
< 9.23.3
range
Exploits & PoCs
1

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

Directus is a real-time API and App dashboard for managing SQL database …

github.comNVDMar 2023

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 9.23.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8vg2-wf3q-mwv7 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### Summary CWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The `directus_refresh_token` is not redacted properly from the log outputs and can be used to impersonate users without their permission. ### Details Using `v9.23.1`, I am seeing that the `directus_refresh_token` is not properly redacted as indicated by https://github.com/directus/directus/blob/7c479c5161639aac466c763b6b958a9524201d74/api/src/logger.ts#L13 I'm classifying this as a security vulnerability because if someone has access to the log outputs, for example with a shared Cloud account or S
O3 Security · Impact-Aware SCA

Is GHSA-8vg2-wf3q-mwv7 in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works
directus vulnerable to Insertion of Sensitive Information…