Vulnerability record · CVE-2026-3419 · published 6 March 2026
CVE-2026-3419: Fastify vulnerability
Fastify · Fastify
Fastify incorrectly accepts malformed `Content-Type` headers containing trailing characters after the subtype token, in violation of RFC 9110 §8.3.1(https://httpwg.org/specs/rfc9110.html#field.content-type). For example, a request sent with Content-Type: application/json garbage passes validation and is processed normally, rather than being rejected with 415 Unsupported Media Type. When regex-based content-type parsers are in use (a documented Fastify feature), the malformed value is matched against registered parsers using the full string including the trailing garbage. This means a request with an invalid content-type may be routed to and processed by a parser it should never have reached. Impact: An attacker can send requests with RFC-invalid Content-Type headers that bypass validity checks, reach content-type parser matching, and be processed by the server. Requests that should be rejected at the validation stage are instead handled as if the content-type were valid. Workarounds: Deploy a WAF rule to protect against this Fix: The fix is available starting with v5.8.1.
Description
Fastify incorrectly accepts malformed `Content-Type` headers containing trailing characters after the subtype token, in violation of RFC 9110 §8.3.1(https://httpwg.org/specs/rfc9110.html#field.content-type). For example, a request sent with Content-Type: application/json garbage passes validation and is processed normally, rather than being rejected with 415 Unsupported Media Type. When regex-based content-type parsers are in use (a documented Fastify feature), the malformed value is matched against registered parsers using the full string including the trailing garbage. This means a request with an invalid content-type may be routed to and processed by a parser it should never have reached. Impact: An attacker can send requests with RFC-invalid Content-Type headers that bypass validity checks, reach content-type parser matching, and be processed by the server. Requests that should be rejected at the validation stage are instead handled as if the content-type were valid. Workarounds: Deploy a WAF rule to protect against this Fix: The fix is available starting with v5.8.1.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Affected products
1 vulnerable configurations from NVD's CPE data, grouped by vendor and product.
References
| Link | Tags |
|---|---|
| https://cna.openjsf.org/security-advisories.html | Vendor Advisory |
| https://github.com/advisories/GHSA-573f-x89g-hqp9 | PatchVendor Advisory |
| https://github.com/fastify/fastify/commit/67f6c9b32cb3623d3c9470cc17ed830dd2f083d7 | Patch |
| https://github.com/fastify/fastify/security/advisories/GHSA-573f-x89g-hqp9 | Vendor Advisory |
| https://httpwg.org/specs/rfc9110.html#field.content-type | Technical Description |
| https://www.cve.org/CVERecord?id=CVE-2026-3419 | VDB Entry |
Track CVE-2026-3419 inside VULONE
Watch it alongside the ransomware crews, C2 infrastructure and forum chatter that reference it, query it through the API and pull it into your SIEM over TAXII.
Related vulnerabilities
Same products first, then exploited flaws of the same weakness class.
Source: NIST National Vulnerability Database (record CVE-2026-3419), CISA KEV, FIRST EPSS (scores of 2026-09-27). This page is refreshed as NVD updates the record.
