CVE-2026-33011

What it actually does

CVE-2026-33011 is an authorization-bypass weakness in NestJS applications using @nestjs/platform-fastify where security-relevant middleware is registered specifically for GET requests. In affected versions 11.1.15 and earlier, Fastify can route a HEAD request to an existing GET handler while NestJS GET middleware is not executed for that HEAD request. The response body is suppressed because the request is HEAD, but the underlying GET route handler still runs. If the skipped middleware performs authentication, authorization, tenant isolation, rate limiting, request validation, auditing, or other access-control checks, an unauthenticated or unauthorized remote attacker can trigger protected handler logic without those controls.

Why it matters to the business

Applications that rely on GET middleware for access control may allow attackers to perform protected actions, retrieve side effects, trigger workflows, or manipulate application state without proper authorization. The risk is highest for APIs where GET handlers have side effects, initiate expensive operations, expose sensitive metadata through headers/status codes, or depend on middleware for user/session validation. Although EPSS is currently low and there is no CISA KEV listing or known ransomware association, the flaw is remotely reachable, requires no authentication, and affects a widely used Node.js framework pattern, so internet-facing NestJS services using the Fastify adapter should be reviewed and upgraded promptly.

How an attack unfolds

An attacker first identifies a NestJS application backed by @nestjs/platform-fastify and enumerates GET endpoints that appear to be protected by middleware such as authentication, authorization, or request filtering. Instead of sending a normal GET request, the attacker sends a HEAD request to the same path. In vulnerable versions, Fastify maps the HEAD request to the GET route handler, but NestJS middleware registered for GET is not invoked because the inbound method is HEAD. The route handler executes with the middleware controls skipped. The attacker may not receive a response body, but can still infer execution from status codes, headers, timing, logs, state changes, downstream calls, or observable workflow effects. Repeating this against sensitive routes can allow bypass of route-level controls that were implemented only as GET middleware.

How to fix it

Upgrade affected NestJS dependencies to version 11.1.16 or later, specifically ensuring @nestjs/platform-fastify and related NestJS packages are aligned on a fixed release. If immediate upgrade is not possible, avoid relying on method-specific GET middleware for security decisions. Move authentication and authorization into guards, interceptors, route handlers, or middleware that explicitly covers both GET and HEAD. Consider disabling or explicitly handling automatic HEAD behavior where feasible, and add explicit HEAD route handling for sensitive endpoints that rejects unauthorized requests before invoking GET logic. Review GET handlers for side effects and convert state-changing operations to appropriate non-GET methods protected by centralized authorization controls.

How to confirm the fix worked

Confirm package versions by inspecting package-lock.json, yarn.lock, pnpm-lock.yaml, or npm dependency output and verify NestJS packages are upgraded to 11.1.16 or later. Test representative protected GET endpoints by sending both GET and HEAD requests while unauthenticated or unauthorized; the HEAD request should be denied by the same security controls as GET and must not execute protected business logic. Review application tests to include HEAD coverage for protected GET routes. Validate that auth, authorization, rate-limiting, and audit middleware or guards are invoked for HEAD requests where a corresponding GET route exists.

Typical attack path

1. Find or fingerprint a NestJS application using the Fastify platform adapter.
2. Enumerate GET routes that require authentication, authorization, validation, or rate limiting.
3. Send HEAD requests to the same paths instead of GET requests.
4. Observe that the GET handler executes while GET-specific middleware is skipped.
5. Use response status, headers, timing, side effects, or backend state changes to confirm successful handler execution.
6. Repeat against protected GET endpoints to bypass middleware-enforced controls or trigger unauthorized operations.

How to detect it

Investigate whether protected GET endpoints received HEAD requests, especially from unauthenticated clients, unusual IPs, scanners, or clients that do not normally use HEAD. Review web server, load balancer, API gateway, CDN, WAF, and application logs for HEAD requests returning success, redirect, or application-specific status codes on routes that normally require authentication. Correlate these requests with authentication, authorization, middleware, and audit logs; exploitation is suggested when a HEAD request reaches a protected route but the expected middleware/auth log entry is missing. Examine application and business-event logs for state changes, job creation, cache invalidation, email dispatch, webhook calls, or downstream API calls occurring immediately after HEAD requests. Because HEAD responses do not include a body, do not rely only on response size; look at status code, headers, timing, and side effects. If available, compare historical baselines for HEAD traffic before and after publication and flag spikes to sensitive API paths.

• "method":"HEAD"
• "method":"HEAD","status":200
• "method":"HEAD","statusCode":200
• "method":"HEAD","status":204
• "method":"HEAD","statusCode":204
• "method":"HEAD","status":302
• "method":"HEAD","statusCode":302
• method=HEAD
• HEAD /
• HEAD /api/
• HEAD /admin
• HEAD /auth
• HEAD /user
• HEAD /users
• HEAD /account
• HEAD /accounts
• HEAD /profile
• HEAD /settings

What your security team should do

• Inventory NestJS applications using @nestjs/platform-fastify and identify those running NestJS 11.1.15 or earlier.
• Prioritize internet-facing APIs and services where GET middleware enforces authentication, authorization, rate limiting, validation, or audit logging.
• Upgrade affected NestJS packages to 11.1.16 or later and redeploy affected services.
• Add regression tests that send unauthenticated HEAD requests to protected GET endpoints and verify denial without handler execution.
• Review GET handlers for side effects, state changes, workflow triggers, or sensitive information leakage through headers and status codes.
• Search historical access logs for unusual HEAD requests to protected or rarely used API paths, especially where matching middleware/auth logs are absent.
• Centralize access control in framework guards or shared authorization components rather than relying solely on method-specific middleware.