GHSA-qw9g-7549-7wg5
HIGHDirectus has MySQL accent insensitive email matching
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
Password reset vulnerable to accent confusion
The password reset mechanism of the Directus backend is implemented in a way where combined with (specific, need to double check if i can work around) configuration in MySQL or MariaDB. As such, it allows attackers to receive a password reset email of a victim user, specifically having it arrive at a similar email address as the victim with a one or more characters changed to use accents.
This is due to the fact that by default MySQL/MariaDB are configured for accent-insenstive and case-insensitve comparisons.
MySQL weak comparison:
select 1 from directus_users where '[email protected]' = 'julian@cüre53.de';
This is exploitable due to an error in the API using the supplied email address for sending the reset password mail instead of using the email from the database.
Steps to reproduce:
- If the attacker knows the email address of the victim user, i.e.,
[email protected]. (possibly just the domain could be enough for an educated guess) - A off-by-one accented domain
cüre53.decan be registered to be able to receive emails. - With this email the attacker can request a password reset for
julian@cüre53.de.
POST /auth/password/request HTTP/1.1
Host: example.com
[...]
{"email":"julian@cüre53.de"}
- The supplied email (julian@cüre53.de) gets checked against the database and will match the non-accented email
[email protected]and will continue to email the password reset link to the provided email address instead of the saved email address. - With this email the attacker can log into the target account and use it for nefarious things
Workarounds
Should be possible with collations but haven't been able to confirm this.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | directus | all versions | 10.8.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 10.8.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qw9g-7549-7wg5 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-qw9g-7549-7wg5 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-qw9g-7549-7wg5. 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-qw9g-7549-7wg5 in your dependencies?
O3 detects GHSA-qw9g-7549-7wg5 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.