fastify is vulnerable to header validation bypass via case-sensitive propertyNamesGHSA-389g-gv7q-r4x8
LOWFix: fastify/fastify#7104GHSA-389g-gv7q-r4x8 is a low-severity (CVSS 3.7) CWE-178 vulnerability in fastify. A fix is available for fastify — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-389g-gv7q-r4x8.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-389g-gv7q-r4x8 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
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.
fastifynpmDescription
Impact
Fastify lowercases header names in a headers schema before compilation, because Node.js stores request header names in lowercase. This normalization does not reach the header names held in a propertyNames subschema's enum and const. A header-name deny-list written in the canonical header case, such as propertyNames: { not: { enum: ['X-Debug-Override'] } }, therefore never matches the lowercased request headers, and the forbidden header reaches the handler. Any application that uses a propertyNames deny-list or allow-list to constrain request header names does not get the constraint it expects. The same rule written in lowercase works, and the not: { required: [...] } form is unaffected, so this is a gap in the built-in normalization rather than a wrong schema. This is an incomplete fix of CVE-2026-84428 (GHSA-9q9j-q6p8-xq58), whose normalization covered header names used as property keys but not those used as values inside propertyNames.
Patches
Users should upgrade to fastify 5.12.6 or later, which lowercases header names held in enum and const inside a propertyNames subschema so they match the lowercased request headers. Header-name constraints that cannot be normalized automatically, regular expressions (propertyNames pattern and patternProperties keys) and a $ref used inside propertyNames, are documented and, for the $ref case, warned at startup (FSTSEC003). Author those to match the lowercased request headers.
Workarounds
Write the propertyNames header-name constraint in lowercase (for example enum: ['x-debug-override']), or enforce the header check in an onRequest or preValidation hook instead of the schema.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | fastify | ≥ 5.12.2&&< 5.12.6 | 5.12.6npm install fastify@5.12.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for fastify, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update fastify to 5.12.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-389g-gv7q-r4x8 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.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A LOW severity vulnerability was found in fastify, a Node.js web framework used by components of Red Hat OpenShift AI and Red Hat OpenShift Dev Spaces. fastify's route schema validation does not normalize the casing of header names declared as enum or const values nested inside a propertyNames subschema. As a result,…
Applications can work around this issue by declaring header names in lowercase in the enum or const values of the route schema's propertyNames subschema, so the declared names match the lowercased incoming headers and the allow-list or deny-list validation applies as intended. The upstream fix is available in fastify 5.12.6 and later; for the affected Red Hat products the fix is currently deferred.Source: Red Hat security advisory for GHSA-389g-gv7q-r4x8 (CC BY 4.0)
Frequently Asked Questions
Is GHSA-389g-gv7q-r4x8 in your dependencies?
Find it across npm, including transitive dependencies.