CVE-2026-3419

What it actually does

Fastify accepts syntactically invalid Content-Type headers that contain extra trailing characters after the media subtype, such as `application/json garbage`, instead of rejecting them with HTTP 415. When applications use Fastify's regex-based content-type parsers, the malformed full header value can still be matched and processed by a registered parser. The primary technical consequence is an input-validation bypass: requests that should be rejected at the HTTP content-type validation layer can reach application parsing and route logic, potentially undermining assumptions made by API handlers, middleware, or custom parsers about the request body format.

Why it matters to the business

This issue can allow unauthenticated remote clients to send malformed API requests that are processed when they should be rejected, which may lead to incorrect request handling, policy bypasses, or unintended data changes in applications that depend on strict content-type validation. The CVSS score is moderate, EPSS is low and stable, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported, so broad emergency response is not indicated; however, internet-facing APIs using Fastify and custom or regex content-type parsers should be prioritized because they are directly reachable over the network.

How an attack unfolds

An attacker identifies an HTTP endpoint served by a vulnerable Fastify version. They craft a request with a malformed Content-Type header that begins with a legitimate media type but appends invalid trailing data after the subtype token, for example `Content-Type: application/json garbage`. Instead of rejecting the request as an unsupported or invalid media type, vulnerable Fastify versions allow the value through validation. If the application has registered regex-based content-type parsers, Fastify evaluates the malformed full string against those parsers and may invoke a parser that should not have been reached. The request body is then parsed and handed to application logic, allowing the attacker to exercise API behavior under conditions the application expected to be blocked at the protocol-validation layer.

How to fix it

Upgrade Fastify to version 5.8.1 or later, where the Content-Type validation behavior is corrected. Review package manifests and lockfiles to ensure the running application actually resolves to the fixed Fastify version, including transitive dependency paths where applicable. If immediate upgrade is not possible, deploy a compensating control at the reverse proxy, API gateway, or WAF layer to reject malformed Content-Type values that contain trailing non-parameter data after the media subtype. Applications using regex-based content-type parsers should review parser patterns to ensure they are anchored, specific, and do not unintentionally match malformed header values. Avoid relying solely on application route logic for media-type enforcement; reject malformed headers before body parsing whenever possible.

How to confirm the fix worked

Confirm the deployed Fastify version is 5.8.1 or later using package manager output, lockfile inspection, and runtime artifact verification. Add a regression test that sends a request such as `Content-Type: application/json garbage` to an endpoint that normally accepts JSON and verify the response is `415 Unsupported Media Type` or another explicit rejection before application handler execution. For applications with regex-based content-type parsers, test representative malformed values against each parser and confirm invalid headers do not invoke the parser or route handler. Validate any WAF or gateway mitigation by sending both valid values such as `application/json` and invalid values such as `application/json garbage`, ensuring valid traffic is allowed and malformed traffic is blocked.

Typical attack path

1. Find an HTTP service or API running a vulnerable Fastify release.
2. Identify endpoints that accept request bodies and rely on Content-Type validation or custom content-type parsers.
3. Send requests with malformed Content-Type headers containing a valid-looking type/subtype followed by trailing junk, such as `application/json garbage`.
4. Observe whether the server processes the request instead of returning `415 Unsupported Media Type` or a comparable validation error.
5. If regex-based content-type parsers are present, tune the malformed header so it matches a registered parser and reaches application body parsing.
6. Use the accepted malformed requests to trigger unintended API behavior, bypass content-type based controls, or cause incorrect state changes where application logic depends on strict media type handling.

How to detect it

To assess prior exploitation or probing, review HTTP request logs from reverse proxies, API gateways, WAFs, load balancers, and application logging that capture request headers. Many default access logs do not include Content-Type, so header-level logging, WAF event logs, sampled request logs, or packet captures may be required. Look for Content-Type values that contain a valid-looking media type followed by unexpected trailing words or characters not introduced as a valid parameter, especially on endpoints that accept JSON, form, XML, or text bodies. Correlate suspicious malformed requests with successful 2xx, 3xx, or application-specific success responses, because exploitation depends on the malformed request being processed rather than rejected. For Fastify applications with custom or regex content-type parsers, inspect application logs for parser invocation, route handler execution, validation failures downstream of parsing, or unusual state-changing requests that used malformed Content-Type headers. There are no known public threat actors or KEV-associated campaigns for this vulnerability based on the provided intelligence, so detection should focus on malformed-header probing and successful processing anomalies rather than actor-specific infrastructure.

• Content-Type: application/json garbage
• Content-Type: text/plain garbage
• Content-Type: application/xml garbage
• Content-Type: application/x-www-form-urlencoded garbage
• Content-Type: multipart/form-data garbage
• application/json garbage
• text/plain garbage
• application/xml garbage
• (?i)Content-Type:\s*[A-Za-z0-9!#$&^_.+-]+/[A-Za-z0-9!#$&^_.+-]+[ \t]+[^;\r\n]

What your security team should do

• Inventory services and repositories using Fastify, prioritizing externally exposed APIs and applications with request-body parsing or custom content-type parsers.
• Upgrade affected Fastify deployments to 5.8.1 or later and redeploy rebuilt artifacts rather than only changing source manifests.
• Add automated tests for malformed Content-Type headers to prevent future regressions in API validation behavior.
• Temporarily enforce Content-Type syntax validation at WAF, reverse proxy, or API gateway layers where upgrade timelines are longer.
• Review custom and regex-based content-type parser registrations for overly broad matching and anchor patterns where feasible.
• Search recent HTTP, WAF, reverse proxy, and application logs for malformed Content-Type headers to determine whether suspicious probing occurred.
• Because EPSS is low, stable, and the issue is not listed in KEV, prioritize remediation based on exposure and parser usage rather than treating all internal deployments as emergency fixes.