{"id":"CVE-2026-3419","aliases":["CLSA-2026-1789159896","CLSA-2026-1790110789","EUVD-2026-10056","GHSA-573f-x89g-hqp9"],"status":"published","title":"Fastify's Missing End Anchor in \"subtypeNameReg\" Allows Malformed Content-Types to Pass Validation","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.\n\nWhen 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.\n\nImpact:\nAn 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.\n\nWorkarounds:\nDeploy a WAF rule to protect against this\n\nFix:\n\nThe fix is available starting with v5.8.1.","severity":{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00388,"percentile":0.33131,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-185"],"published":"2026-03-05T21:29:54Z","modified":"2026-10-28T02:30:31Z","fixes":[{"ecosystem":"npm","package":"fastify","fixed_in":["5.8.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"fastify","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.7.2"},{"last_affected":"5.8.0"},{"fixed":"5.8.1"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"fastify","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.7.4-tuxcare.0"},{"fixed":"5.7.4-tuxcare.1"}]}],"versions":["5.7.4"],"bundled":2},{"source":"osv","ecosystem":"TuxCare:npm","package":"fastify","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.2.1-tuxcare.0"},{"fixed":"5.2.1-tuxcare.2"}]}],"versions":["5.2.1","5.2.1-tuxcare.1"],"bundled":3},{"source":"osv","ecosystem":"npm","package":"fastify","ranges":[{"type":"SEMVER","events":[{"introduced":"5.7.2"},{"fixed":"5.8.1"}]}]}],"products":[{"vendor":"@clerk","product":"fastify"},{"vendor":"fastify","product":"fastify"}],"references":[{"url":"https://github.com/fastify/fastify/security/advisories/GHSA-573f-x89g-hqp9","tags":["Vendor Advisory","advisory","web"]},{"url":"https://github.com/fastify/fastify/commit/67f6c9b32cb3623d3c9470cc17ed830dd2f083d7","tags":["Patch","fix","web"]},{"url":"https://httpwg.org/specs/rfc9110.html#field.content-type","tags":["Technical Description","web"]},{"url":"https://github.com/advisories/GHSA-573f-x89g-hqp9","tags":["Patch","Vendor Advisory","advisory"]},{"url":"https://cna.openjsf.org/security-advisories.html","tags":["Vendor Advisory","advisory","web"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-3419","tags":["VDB Entry","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-3419","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/3xxx/CVE-2026-3419.json","tags":["advisory"]},{"url":"https://github.com/fastify/fastify","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-3419","title":"Fastify's Missing End Anchor in \"subtypeNameReg\" Allows Malformed Content-Types to Pass Validation","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.\n\nWhen 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.\n\nImpact:\nAn 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.\n\nWorkarounds:\nDeploy a WAF rule to protect against this\n\nFix:\n\nThe fix is available starting with v5.8.1.","status":"published","published":"2026-03-06T17:50:58.714Z","modified":"2026-03-09T14:55:21.011Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-185"],"updated_at":"2026-11-02T13:49:09.229322Z"}],"euvd":[{"id":"EUVD-2026-10056","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.\n\nWhen 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.\n\nImpact:\nAn 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.\n\nWorkarounds:\nDeploy a WAF rule to protect against this\n\nFix:\n\nThe fix is available starting with v5.8.1.","status":"published","published":"2026-03-06T17:50:58Z","modified":"2026-03-09T14:55:21Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T19:48:07.128863Z"}],"ghsa":[{"id":"GHSA-573f-x89g-hqp9","title":"Fastify's Missing End Anchor in \"subtypeNameReg\" Allows Malformed Content-Types to Pass Validation","description":"# Description\n\nFastify 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`.\n\nWhen 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.\n\n## Impact\n\nAn 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.\n\n## Workarounds\n\nDeploy a WAF rule to protect against this\n\n## Fix\n\nThe fix is available starting with v5.8.1.","status":"published","published":"2026-03-05T21:29:54Z","modified":"2026-03-06T22:44:35Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-185"],"updated_at":"2026-11-02T14:39:32.329372Z"}],"nvd":[{"id":"CVE-2026-3419","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.\n\nWhen 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.\n\nImpact:\nAn 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.\n\nWorkarounds:\nDeploy a WAF rule to protect against this\n\nFix:\n\nThe fix is available starting with v5.8.1.","status":"published","published":"2026-03-06T18:16:22.213Z","modified":"2026-06-17T10:43:34.207Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-185"],"updated_at":"2026-11-02T14:12:08.279852Z"}],"osv":[{"id":"CVE-2026-3419","title":"Fastify's Missing End Anchor in \"subtypeNameReg\" Allows Malformed Content-Types to Pass Validation","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.\n\nWhen 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.\n\nImpact:\nAn 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.\n\nWorkarounds:\nDeploy a WAF rule to protect against this\n\nFix:\n\nThe fix is available starting with v5.8.1.","status":"published","published":"2026-03-06T17:50:58.714Z","modified":"2026-10-28T02:30:31.051888989Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-185"],"updated_at":"2026-11-02T15:45:02.247031Z"},{"id":"GHSA-573f-x89g-hqp9","title":"Fastify's Missing End Anchor in \"subtypeNameReg\" Allows Malformed Content-Types to Pass Validation","description":"# Description\n\nFastify 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`.\n\nWhen 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.\n\n## Impact\n\nAn 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.\n\n## Workarounds\n\nDeploy a WAF rule to protect against this\n\n## Fix\n\nThe fix is available starting with v5.8.1.","status":"published","published":"2026-03-05T21:29:54Z","modified":"2026-07-08T08:14:43.625968787Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-185"],"updated_at":"2026-11-02T15:46:37.864461Z"},{"id":"CLSA-2026-1789159896","title":"TuxCare security update for fastify (2 CVEs)","description":"TuxCare rebuilt fastify to address 2 CVEs. Fixed in 5.7.4-tuxcare.1.","status":"published","published":"2026-09-11T20:51:36Z","modified":"2026-10-15T09:48:03.816200884Z","updated_at":"2026-11-02T15:43:47.938828Z"},{"id":"CLSA-2026-1790110789","title":"TuxCare security update for fastify (3 CVEs)","description":"TuxCare rebuilt fastify to address 3 CVEs. Fixed in 5.2.1-tuxcare.2.","status":"published","published":"2026-09-22T20:59:49Z","modified":"2026-10-15T09:45:34.375513006Z","updated_at":"2026-11-02T15:43:48.28229Z"}]}}