@fastify/express CVE-2026-6556

Exploitation requires that the target application uses @fastify/express (≤4.0.6) and registers path-scoped middleware - specifically middleware performing authentication, authorization, rate limiting, or auditing - inside a Fastify plugin that is mounted under a path prefix, AND that this middleware is declared with a non-string mount path (an array of paths or a regular expression) rather than a string. The route handler behind that middleware must also exist and be matchable by Fastify. What limits exploitation: applications that only use string mount paths, that do not prefix their plugins, or that enforce auth via Fastify hooks/route handlers instead of mounted middleware are not affected. No authentication is required of the attacker (PR:N) and no user interaction is needed; the gating factor is this specific, non-default middleware configuration choice by the application developer rather than any attacker-controlled condition.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, base 9.1) describes a network-reachable, unauthenticated, low-complexity bypass with high confidentiality and integrity impact and no availability impact, which is consistent with an auth/authz control being skipped. However, the raw score overstates universal risk because exploitation is strictly conditional on application design: the targeted app must (a) use @fastify/express, (b) register security middleware in a prefixed plugin scope, and (c) mount that middleware with an array or RegExp path rather than a string. This is a real and serious bug for affected configurations but is not a blanket 'any deployment is exploitable' situation, which is why an independent assessment raises attack complexity. No EPSS score, KEV listing, POC, or SSVC decision data was supplied; absence of KEV means no confirmed active exploitation. Treat as high priority for teams that match the vulnerable pattern, and lower (but still patch-worthy) for those using only string mount paths.

A developer protects /api/admin routes by registering an authentication middleware in a prefixed plugin using a RegExp or array mount path; because the prefix is never applied, the middleware never matches and is skipped. An unauthenticated attacker simply sends a normal HTTP request to the real prefixed route (e.g. GET /api/admin/users) and reaches the handler with no auth check enforced. No public exploit code is required given the low complexity, though none has been identified at time of analysis.