CVE-2026-33011: 
JavaScript vulnerability analysis and mitigation

CVE-2026-33011 is a middleware bypass vulnerability in NestJS applications using the @nestjs/platform-fastify adapter, allowing attackers to circumvent GET middleware by sending HTTP HEAD requests. Because Fastify automatically routes HEAD requests to the corresponding GET handlers, any middleware registered for GET routes is completely skipped while the handler itself still executes. The vulnerability affects @nestjs/platform-fastify versions ≤ 11.1.15 (NestJS nest package versions prior to 11.1.16). It was published on March 16, 2026, and assigned a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (Github Advisory, NestJS Security Advisory).

The root cause is classified as CWE-670 (Always-Incorrect Control Flow Implementation): the NestJS middleware dispatch logic in packages/core/middleware/middleware-module.ts only checked whether the incoming request method matched the registered middleware's target method, without accounting for Fastify's built-in behavior of forwarding HEAD requests to GET handlers. As a result, when a HEAD request arrives, the method comparison (actualRequestMethod === requestMethod) fails for GET-registered middleware, causing next() to be called and middleware to be skipped entirely, while Fastify still routes the request to the GET handler. The fix (commit cbdf737) adds an additional condition so that HEAD requests also trigger GET-registered middleware (NestJS Commit, Github Advisory). No authentication or special privileges are required to exploit this flaw — any unauthenticated network attacker can send a crafted HEAD request.

Successful exploitation allows an attacker to bypass authentication, authorization, rate-limiting, logging, or any other middleware applied to GET routes by simply issuing a HEAD request to the same endpoint. The GET handler executes normally on the server side (including any backend logic such as database reads or state changes), while the HTTP response body is suppressed per HEAD semantics — meaning the attacker receives no response body but the server-side operation completes. This can result in unauthorized access to protected operations and sensitive data, and may allow attackers to trigger privileged backend logic without detection by middleware-based security controls (Github Advisory, NestJS Security Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.04% (14th percentile), indicating a low near-term probability of exploitation. However, the attack requires no authentication, no user interaction, and no special conditions beyond the target running a vulnerable NestJS Fastify application, making it trivially exploitable if discovered.

1. Reconnaissance: Identify target applications using NestJS with the @nestjs/platform-fastify adapter (versions ≤ 11.1.15). Indicators include HTTP response headers such as x-powered-by: fastify or NestJS-specific API patterns.
2. Identify protected GET endpoints: Map the application's API surface to find GET endpoints that are protected by middleware (e.g., authentication guards, rate limiters, audit loggers). This can be done via passive observation, API documentation, or fuzzing.
3. Craft a HEAD request: Instead of sending a standard GET /protected-endpoint, send HEAD /protected-endpoint with the same headers and parameters. Example using curl: curl -X HEAD https://target.example.com/protected-endpoint -v
4. Observe middleware bypass: The server processes the request through the GET handler without invoking any registered GET middleware. The response will have no body (per HEAD semantics) but will return HTTP headers indicating the handler executed (e.g., 200 OK).
5. Trigger backend logic: If the GET handler performs sensitive operations (e.g., data retrieval, state changes, token generation), those operations execute server-side without middleware-enforced security checks, achieving the attacker's objective (Github Advisory, NestJS Commit).

• Network: Unusual volume of HTTP HEAD requests to endpoints that are not typically accessed via HEAD; HEAD requests to API paths that normally only receive GET traffic; HEAD requests returning 200 OK on endpoints expected to require authentication.
• Logs: Application access logs showing HEAD method requests to protected routes without corresponding authentication tokens or session identifiers; absence of middleware-generated log entries (e.g., auth audit logs) for requests that resulted in handler execution.
• Application Behavior: Backend operations (database queries, file reads, state mutations) triggered by HEAD requests with no corresponding authenticated session; discrepancies between middleware audit logs and handler execution logs for the same endpoints.

The vulnerability is fixed in @nestjs/platform-fastify version 11.1.16 (released as part of NestJS v11.1.17 on March 16, 2026). Upgrade to @nestjs/platform-fastify@11.1.16 or later immediately. No configuration-based workaround is documented; upgrading is the only reliable remediation. Security teams should also audit applications running affected versions to determine whether any unauthorized access may have occurred via HEAD requests prior to patching (Github Advisory, NestJS Release).

The advisory was published by NestJS maintainer Kamil Mysliwiec (@kamilmysliwiec) on March 16, 2026, with a same-day patch release. The fix received positive community reception on GitHub, with 18 reactions on the v11.1.17 release notes. No significant broader media coverage or notable external researcher commentary has been identified beyond standard vulnerability database aggregation (NestJS Release).