CVE-2023-28443 is a medium-severity (CVSS 4.2) CWE-284 vulnerability in directus. 1 public exploit reference exists, so weaponization risk is real. A fix is available for directus — see the affected versions and patch details below.
directus vulnerable to Insertion of Sensitive Information into Log File
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 CVE-2023-28443.
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.
How urgent is this, really
CVE-2023-28443 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,333 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
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.
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.3npm install directus@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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update directus to 9.23.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2023-28443 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2023-28443 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2023-28443. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2023-28443 in your dependencies?
O3 Security finds CVE-2023-28443 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.