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.
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.
Metrics
Affected Vendors & Products
No data.
No data.
No data.
No data.
Advisories
| Source | ID | Title |
|---|---|---|
 Github GHSA |
GHSA-573f-x89g-hqp9 | Fastify's Missing End Anchor in "subtypeNameReg" Allows Malformed Content-Types to Pass Validation |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Fri, 06 Mar 2026 18:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Fastify's Missing End Anchor in "subtypeNameReg" Allows Malformed Content-Types to Pass Validation | |
| Weaknesses | CWE-185 | |
| References |
|
|
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: openjs
Published:
Updated: 2026-03-06T17:54:33.542Z
Reserved: 2026-03-01T18:56:49.613Z
Link: CVE-2026-3419
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-03-06T18:16:22.213
Modified: 2026-03-06T18:16:22.213
Link: CVE-2026-3419
Redhat
No data.
OpenCVE Enrichment
No data.
Weaknesses