CVE-2025-69211: NestJS Fastify Auth Bypass Vulnerability

CVE-2025-69211 Overview

CVE-2025-69211 is a middleware bypass vulnerability in NestJS, a framework for building scalable Node.js server-side applications. The flaw affects applications using @nestjs/platform-fastify prior to version 11.1.11. Attackers can craft URL-encoded request paths that the Fastify middie middleware engine fails to match against route patterns, allowing requests to skip middleware bound through MiddlewareConsumer or app.use(). Exploitation lets unauthenticated users reach protected routes, allows lower-privileged users to invoke restricted administrative endpoints, and bypasses sanitization or validation logic enforced by middleware. The issue is tracked under [CWE-367] Time-of-Check Time-of-Use race conditions related to path decoding.

Critical Impact
Authentication, authorization, and input-validation middleware bound to specific routes can be silently skipped, exposing protected NestJS endpoints to unauthenticated or unauthorized callers.

Affected Products

NestJS @nestjs/platform-fastify versions prior to 11.1.11
NestJS applications relying on NestMiddleware via MiddlewareConsumer for security checks
NestJS applications applying middleware via app.use() to string paths or controllers (e.g., .forRoutes('admin'))

Discovery Timeline

2025-12-29 - CVE-2025-69211 published to NVD
2026-02-20 - Last updated in NVD database

Technical Details for CVE-2025-69211

Vulnerability Analysis

NestJS supports two HTTP adapters: Express and Fastify. When developers use @nestjs/platform-fastify, middleware registered through MiddlewareConsumer.forRoutes() is internally wired through the middie plugin and matched against the incoming request URL. The matching logic compared the raw request path against route patterns without consistently decoding percent-encoded characters. An attacker can submit a request whose path contains URL-encoded characters that match a protected route after decoding but do not match the middleware pattern during the check.

The result is a path-handling mismatch: Fastify's router still resolves the encoded URL to the protected controller handler, while the middleware layer treats the same URL as a non-matching route and skips execution. This lets attackers reach controller methods without traversing the security middleware that was supposed to gate them.

Root Cause

The root cause is inconsistent URL decoding between the Fastify route resolver and the middie middleware matcher inside the NestJS Fastify adapter. The matcher used the raw path while the underlying router used a decoded path, creating a [CWE-367] time-of-check/time-of-use style discrepancy. The patch introduces safeDecodeURI from find-my-way/lib/url-sanitizer so middleware matching uses the same sanitized representation as route resolution.

Attack Vector

The vulnerability is exploited remotely over the network with no authentication or user interaction. An attacker sends an HTTP request to a NestJS endpoint protected by middleware bound to a string path such as 'admin'. By percent-encoding one or more characters in the path (for example %61dmin instead of admin), the attacker bypasses the middleware while the controller still receives and processes the request.

typescript

// Security patch in packages/platform-fastify/adapters/fastify-adapter.ts
// fix(platform-fastify): middie bypassing through decoded chars
 import { pathToRegexp } from 'path-to-regexp';
 // Fastify uses `fast-querystring` internally to quickly parse URL query strings.
 import { parse as querystringParse } from 'fast-querystring';
+import { safeDecodeURI } from 'find-my-way/lib/url-sanitizer';
 import {
   FASTIFY_ROUTE_CONFIG_METADATA,
   FASTIFY_ROUTE_CONSTRAINTS_METADATA,
// Source: https://github.com/nestjs/nest/commit/c4cedda15a05aafec1e6045b36b0335ab850e771

The patch imports safeDecodeURI and applies it before route pattern matching so encoded paths are normalized prior to middleware comparison.

Detection Methods for CVE-2025-69211

Indicators of Compromise

HTTP access logs containing requests to protected routes (e.g., /admin, /api/users) where the path segment contains percent-encoded alphabetic characters such as %61, %64, or %6d.
Successful HTTP 2xx responses from administrative endpoints without preceding authentication or authorization log entries from NestJS middleware.
Application logs showing controller handler invocation without corresponding NestMiddleware log entries for routes bound via .forRoutes().

Detection Strategies

Inventory all NestJS services and identify those importing @nestjs/platform-fastify at versions below 11.1.11.
Audit MiddlewareConsumer.forRoutes() and app.use() registrations for string-path or controller-based bindings used to enforce security checks.
Replay representative requests against staging environments using percent-encoded variants of protected route segments and compare middleware execution traces.

Monitoring Recommendations

Forward Fastify access logs and NestJS application logs to a centralized SIEM and alert on requests to sensitive paths that contain percent-encoded ASCII letters in the route portion.
Track anomalous ratios of controller invocations to middleware executions per route as a behavioral signal of bypass attempts.
Add web application firewall rules that normalize URL encoding before policy evaluation so encoded variants of protected paths are blocked or flagged.

How to Mitigate CVE-2025-69211

Immediate Actions Required

Upgrade @nestjs/platform-fastify to version 11.1.11 or later across all affected NestJS services.
Review middleware bindings that enforce authentication, authorization, or input validation and confirm they cover all sensitive controllers.
Re-test protected routes with percent-encoded path variants after upgrading to verify middleware now executes consistently.

Patch Information

The fix is included in @nestjs/platform-fastify@11.1.11. The patch adds safeDecodeURI from find-my-way/lib/url-sanitizer to the Fastify adapter so middleware route matching uses the same decoded path representation as Fastify's router. See the GitHub Security Advisory GHSA-8wpr-639p-ccrj and the GitHub commit for full technical details.

Workarounds

If immediate upgrade is not possible, enforce security checks inside Guards or interceptors rather than NestMiddleware, since Guards execute after route resolution and are not subject to the middie matcher bypass.
Deploy a reverse proxy or WAF rule that decodes and normalizes request paths before they reach the NestJS application, rejecting requests whose decoded path differs from the raw path on sensitive route prefixes.
Restrict access to administrative routes at the network layer (e.g., internal-only listener, mTLS) until the upgrade is deployed.

bash

# Upgrade the vulnerable package to the patched version
npm install @nestjs/platform-fastify@^11.1.11

# Verify the installed version
npm ls @nestjs/platform-fastify