CVE-2026-33806

What it actually does

Fastify versions affected by the regression in the 5.x line can skip request body validation when an application uses schema.body.content for per-content-type validation and the request's Content-Type header is prefixed with whitespace. The body is still parsed as the intended media type, but the schema validator is not applied, allowing malformed, unexpected, or policy-violating request bodies to reach route handlers. The primary impact is integrity loss: application logic may process data that developers expected Fastify to reject.

Why it matters to the business

Public APIs built on affected Fastify versions may accept invalid or unauthorized input, which can lead to incorrect transactions, broken business rules, data corruption, abuse of privileged workflows, or downstream processing errors. The issue is remotely triggerable without authentication if vulnerable routes are exposed, although current public exploitation signals are low: EPSS is low and stable, no known KEV listing is present, and no ransomware association is reported. Because Fastify is a common Node.js web framework, organizations should still treat internet-facing API services as priority upgrade targets.

How an attack unfolds

An attacker identifies a Fastify endpoint that validates request bodies using per-content-type schemas under schema.body.content. The attacker crafts a request with a body that would normally fail schema validation, such as missing required fields, using disallowed values, supplying extra fields, or violating type and format constraints. The attacker then sends the request with a Content-Type header whose value has a leading space, for example a whitespace-prefixed application/json value. Affected Fastify versions still parse the body as that content type, but fail to match the corresponding schema validation rule, so the route handler receives and processes the unvalidated body. Exploitation impact depends on the endpoint logic: the attacker may be able to bypass business validation, manipulate state, trigger unsafe downstream behavior, or submit data the application was designed to reject.

How to fix it

Upgrade Fastify to version 5.8.5 or later. The advisory states there is no workaround, so dependency upgrades are the primary remediation. Review package manifests and lockfiles for affected Fastify versions, especially versions greater than or equal to 5.3.2 and earlier than 5.8.5. Rebuild and redeploy applications after updating dependencies, and ensure transitive dependency resolution does not retain a vulnerable Fastify version. If immediate upgrade is delayed, reduce exposure by restricting access to affected API routes, enforcing strict header normalization or rejection at an upstream proxy or WAF for Content-Type values with leading whitespace, and adding explicit application-level validation in handlers for critical routes; these mitigations should not be treated as substitutes for upgrading.

How to confirm the fix worked

Confirm the deployed application resolves Fastify to version 5.8.5 or later using package manager output, lockfile review, or software composition analysis. In running services, verify the packaged dependency version in the deployed artifact rather than only in source control. For behavioral validation, test a route that uses schema.body.content by sending a request that should fail validation with a normal Content-Type header, then repeat with the same invalid body and a whitespace-prefixed Content-Type value. A fixed service should reject both requests consistently with a validation error. Also confirm that upstream proxies, gateways, and logging preserve enough request-header detail to detect malformed Content-Type attempts.

Typical attack path

1. Find a Fastify-based API endpoint that accepts POST, PUT, or PATCH request bodies.
2. Determine or infer that the endpoint uses content-type-specific body validation, commonly for JSON or other structured request bodies.
3. Create a request body that violates the expected schema but is useful to the attacker.
4. Send the request with a whitespace-prefixed Content-Type header value, such as a value equivalent to " application/json".
5. Observe that the request body is parsed but schema validation is skipped.
6. Repeat against sensitive workflows to bypass input constraints or alter application state.

How to detect it

Look for evidence of requests with Content-Type header values beginning with a space or tab, especially successful POST, PUT, or PATCH requests to API routes. Useful sources include raw web server logs, API gateway logs, WAF logs, reverse proxy logs, load balancer HTTP logs, Fastify application logs that record request headers, and distributed tracing telemetry that captures inbound headers. Pay special attention to requests that returned 2xx or application-level success responses when similar requests normally produce 4xx validation errors. Because many logging systems normalize or omit header whitespace, raw request capture or gateway-level header logging may be required. Also compare request bodies from suspicious traffic against the expected schemas: exploitation is more likely when the body contains missing required fields, wrong data types, unexpected properties, invalid enum values, overlong strings, or structurally unusual JSON that should have failed validation.

• Content-Type: application/json
• Content-Type: application/json
• content-type: application/json
• content-type: application/json
• "content-type":" application/json"
• "content-type":"\tapplication/json"
• Content-Type: application/
• content-type: application/
• req.headers["content-type"]=" application/json"
• req.headers['content-type']=' application/json'

What your security team should do

• Inventory Node.js services using Fastify and prioritize internet-facing APIs and services handling state-changing requests.
• Upgrade Fastify to 5.8.5 or later and redeploy all affected applications.
• Search package-lock.json, yarn.lock, pnpm-lock.yaml, and deployed artifacts for Fastify versions >=5.3.2 and <5.8.5.
• Add regression tests for routes using schema.body.content to ensure validation is not bypassed by leading whitespace in Content-Type.
• Create WAF, API gateway, or SIEM detections for POST, PUT, and PATCH requests with Content-Type values beginning with whitespace.
• Review recent API traffic for successful requests with malformed Content-Type headers and payloads that would normally violate schema expectations.
• For critical APIs, add defense-in-depth validation close to business logic so framework-level validation bypasses do not directly affect sensitive operations.