CVE-2026-107832: fastify vulnerable to header validation bypass via case-sensitive propertyNames
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.
Other sources
fastify is a fast and low overhead web framework for Node.js. In versions 5.12.2 through 5.12.5, the routine that lowercases header names declared in a route schema does not lowercase the enum or const header names nested inside a propertyNames subschema. As a result, a header allow-list or deny-list written with canonical (non-lowercase) casing never matches the incoming lowercased header, so a restricted header passes validation and reaches the route handler. An attacker can therefore bypass a case-sensitive header validation rule and smuggle a forbidden header past the schema, affecting the integrity of request handling. The issue is fixed in fastify 5.12.6, and users should upgrade to 5.12.6 or later. There is no workaround other than upgrading, though applications can declare header names in lowercase to avoid the mismatch.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/fastifyto a version that resolves this vulnerability.Fixed in 5.12.6 - Upgrade
Upgrade
fastifyto a version that resolves this vulnerability.Fixed in 5.12.6 - Configuration
Write header names in propertyNames enum or const constraints in lowercase, for example enum: ['x-debug-override'], so they match lowercased request headers.
fastify header schema propertyNames header-name constraint casing = lowercase
Event History
Frequently Asked Questions
Which applications are exposed to this bypass?
Applications using Fastify versions 5.12.2 through 5.12.5 are affected when a route schema uses a propertyNames subschema with enum or const values to allow-list or deny-list request headers using non-lowercase header names. The bypass matters only where the route handler relies on that validation to restrict headers.
What does an attacker need to exploit the issue?
An attacker needs to send a request to an affected route with a header that the application intends to restrict through the affected case-sensitive propertyNames validation rule. No authentication or user interaction is required, but the schema must contain the vulnerable non-lowercase enum or const header declaration.
How can teams mitigate the issue if they cannot immediately upgrade?
There is no complete workaround other than upgrading to Fastify 5.12.6 or later. As a temporary mitigation, declare header names in lowercase in the affected propertyNames enum or const schema values.
How can I determine whether an existing schema is vulnerable?
Review route header schemas for propertyNames subschemas containing enum or const values. If those values name headers with canonical or other non-lowercase casing, validation may fail to match the incoming lowercased header and allow it through.