CVE-2026-54281

What it actually does

CVE-2026-54281 is an authentication bypass in NestJS applications using @nestjs/platform-fastify before version 11.1.24. When route-protecting middleware is registered with MiddlewareConsumer.forRoutes() on the Fastify adapter, the middleware can be skipped if the requester appends a trailing slash to the URL. For example, a route protected as /resource may be reachable as /resource/ without executing the intended Nest middleware. The issue affects the default Fastify adapter behavior and can allow access to endpoints that developers expected to be protected by authentication, authorization, tenant checks, rate limiting, or other security middleware.

Why it matters to the business

Applications relying on NestJS Fastify middleware for access control may expose protected API functionality to unauthorized users. Depending on what the affected routes do, this could lead to data disclosure, unauthorized changes, abuse of privileged operations, or disruption of application workflows. Although this issue is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the provided data, it is straightforward to test remotely and should be prioritized for internet-facing APIs, administrative routes, and services handling sensitive data.

How an attack unfolds

An attacker first identifies a NestJS application using the Fastify adapter and probes for routes that appear protected by authentication or authorization middleware. The attacker then requests the canonical protected route and observes the expected denial, redirect, or authentication challenge. Next, the attacker repeats the request with a trailing slash appended to the same path. In vulnerable versions, if the route’s protection was implemented through MiddlewareConsumer.forRoutes(), the Fastify/Nest routing mismatch can cause the registered middleware not to execute, allowing the request to reach the route handler. If the handler itself does not perform independent authorization checks, the attacker may read protected data, invoke state-changing API actions, or interact with functionality intended only for authenticated users.

How to fix it

Upgrade @nestjs/platform-fastify and related NestJS packages to version 11.1.24 or later. Where package managers allow it, pin or override transitive NestJS dependencies so all runtime instances resolve to the fixed version. Rebuild and redeploy affected applications after dependency updates. As a defense-in-depth measure, ensure sensitive route handlers perform explicit authorization checks and do not rely solely on route middleware. Consider normalizing or rejecting trailing slashes at the edge proxy, API gateway, load balancer, or application layer until all services are patched. Review MiddlewareConsumer.forRoutes() usage on Fastify-backed applications and confirm that protected routes behave identically with and without trailing slashes.

How to confirm the fix worked

Confirm the deployed dependency tree resolves @nestjs/platform-fastify to 11.1.24 or later using package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls, yarn why, pnpm why, SBOM output, or container image scans. In application testing, identify routes protected through MiddlewareConsumer.forRoutes() and send paired requests to the canonical path and the same path with a trailing slash. The fixed or mitigated application should enforce the same authentication and authorization outcome for both forms. Include GET and state-changing methods such as POST, PUT, PATCH, and DELETE where applicable. Validate behavior through integration tests, API gateway logs, and runtime smoke tests after redeployment.

Typical attack path

1. Reconnaissance: identify a Node.js/NestJS API, especially one using Fastify behavior such as Fastify-specific headers, responses, or error formats.
2. Route discovery: enumerate API paths through application behavior, documentation, OpenAPI specs, client-side code, or brute-force wordlists.
3. Baseline access check: request a protected route without credentials and confirm that the normal path returns an authentication or authorization failure.
4. Bypass attempt: repeat the same request with a trailing slash appended to the URL path.
5. Access validation: compare response codes, response bodies, redirects, and side effects between the canonical path and trailing-slash path.
6. Post-bypass activity: access sensitive data or invoke protected API actions if the trailing-slash variant reaches the route handler without middleware enforcement.
7. Persistence or automation: script requests against multiple protected routes that differ only by a trailing slash.

How to detect it

To determine whether exploitation already occurred, review web server, reverse proxy, API gateway, CDN, WAF, and application access logs for paired requests where a request to a protected canonical path returned 401, 403, or a login redirect, followed shortly by a request to the same path with a trailing slash returning 2xx or 3xx success. Prioritize sensitive endpoints, administrative APIs, user or account data routes, and state-changing HTTP methods such as POST, PUT, PATCH, and DELETE. Correlate successful trailing-slash requests with missing or invalid authentication tokens, absent session cookies, anonymous identities, unusual source IPs, user agents associated with scanners, and abnormal response sizes. Application logs should be checked for handler execution on protected routes without corresponding middleware authentication events. Source-code and CI logs can help identify whether vulnerable services used MiddlewareConsumer.forRoutes() with @nestjs/platform-fastify before 11.1.24. Because there are no public exploit-specific artifacts in the provided data, detection should focus on behavioral evidence: authorization failures on non-slash paths followed by successful access to slash-suffixed equivalents.

• MiddlewareConsumer.forRoutes(
• @nestjs/platform-fastify
• requests to protected paths ending with / returning HTTP 200 after the same path without / returned HTTP 401
• requests to protected paths ending with / returning HTTP 200 after the same path without / returned HTTP 403
• POST requests to protected API paths ending with / from unauthenticated clients
• PUT requests to protected API paths ending with / from unauthenticated clients
• PATCH requests to protected API paths ending with / from unauthenticated clients
• DELETE requests to protected API paths ending with / from unauthenticated clients
• same client IP requesting /<protected-route> then /<protected-route>/ within a short interval
• successful trailing-slash request with missing Authorization header
• successful trailing-slash request with missing session cookie

What your security team should do

• Inventory NestJS applications and prioritize those using the Fastify adapter, especially internet-facing APIs and administrative services.
• Upgrade @nestjs/platform-fastify to 11.1.24 or later and redeploy all affected services.
• Search source code for MiddlewareConsumer.forRoutes() and review whether it protects sensitive routes without handler-level authorization checks.
• Add regression tests that compare authorization behavior for protected routes with and without trailing slashes.
• Temporarily normalize or block trailing-slash variants for sensitive API paths at the gateway, reverse proxy, WAF, or application routing layer if immediate patching is not possible.
• Review recent access logs for successful requests to protected endpoints where the only path difference is an appended trailing slash.
• Monitor for route enumeration patterns, repeated 401/403 followed by 200 responses on the same path with a trailing slash, and unauthenticated state-changing requests.