LowGHSA-389g-gv7q-r4x8CVE-2026-107832

fastify is vulnerable to header validation bypass via case-sensitive propertyNames

Published 22 Oct 2026 · Updated 22 Oct 2026

Affected package

Affected
>=5.12.2 <5.12.6
Fixed in
5.12.6
Update to the fixed version for your release line, for example:npm install fastify@5.12.6

Details

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.

Is GHSA-389g-gv7q-r4x8 in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected fastify, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.