GHSA-8vg2-wf3q-mwv7
MEDIUMdirectus vulnerable to Insertion of Sensitive Information into Log File
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
directusnpmDescription
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
-
Set
LOG_STYLE="raw"and run Directus v9.23.1 -
Log in to the application
-
Look at the shell output and see that
directus_refresh_tokenis loggedNote: This is different from the standard
rawoutput format. I intentionally ran this withnpx directus start | pino-prettyso logs would be easier to read. It can also be reproduced by runningnpx directus startalone.
-
Exchange the
directus_refresh_tokenfor anaccess_tokencurl -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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | directus | all versions | 9.23.3 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for directus. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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.
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.
How O3 protects you
O3 pinpoints whether GHSA-8vg2-wf3q-mwv7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-8vg2-wf3q-mwv7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-8vg2-wf3q-mwv7 in your dependencies?
O3 detects GHSA-8vg2-wf3q-mwv7 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.