CVE-2026-33011

High

Published: 20 March 2026

Published

20 March 2026

Modified

23 March 2026

KEV Added

—

Patch

—

CVSS Score 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

EPSS Score 0.0004 12.5th percentile

Risk Priority 15 60% EPSS · 20% KEV · 20% CVSS

Summary

CVE-2026-33011 is a high-severity Always-Incorrect Control Flow Implementation (CWE-670) vulnerability in Nestjs Nest. Its CVSS base score is 7.5 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 12.5th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified are NIST 800-53 SI-2 (Flaw Remediation) and CM-6 (Configuration Settings).

Threat & Defense at a Glance

What attackers do: exploitation maps to Exploit Public-Facing Application (T1190). What defenders deploy: see the NIST 800-53 controls recommended below.

Threat & Defense Details

Mitigating Controls (NIST 800-53 r5)AI

SI-2 Flaw Remediation good match

prevent

Directly mitigates the vulnerability by requiring remediation through upgrading NestJS to version 11.1.16 or later, where the Fastify HEAD-to-GET redirection bypass is fixed.

CM-6 Configuration Settings partial match

prevent

Enforces secure configuration settings for the NestJS Fastify adapter to prevent middleware bypasses due to automatic HTTP method redirections.

SC-7 Boundary Protection partial match

preventdetect

Monitors and controls communications at system boundaries to block or detect anomalous HEAD requests that bypass GET middleware protections.

MITRE ATT&CK Enterprise TechniquesAI

T1190 Exploit Public-Facing Application Initial Access

Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.

attack.mitre.org →

Why these techniques?

The CVE describes a remote, unauthenticated logic flaw in a public-facing NestJS web application (Fastify adapter) that bypasses intended middleware controls (e.g., auth/validation) via HEAD-to-GET redirection, directly enabling exploitation of the server-side application per T1190.

Confidence: HIGH · MITRE ATT&CK Enterprise v18.1

NVD Description

Nest is a framework for building scalable Node.js server-side applications. In versions 11.1.15 and below, a NestJS application using @nestjs/platform-fastify GET middleware can be bypassed because Fastify automatically redirects HEAD requests to the corresponding GET handlers (if they exist). As…

a result: middleware will be completely skipped, the HTTP response won't include a body (since the response is truncated when redirecting a HEAD request to a GET handler), and the actual handler will still be executed. This issue is fixed in version 11.1.16.

Deeper analysisAI

CVE-2026-33011 affects the Nest framework, a platform for building scalable Node.js server-side applications, specifically in versions 11.1.15 and prior when using the @nestjs/platform-fastify adapter. The vulnerability arises because Fastify automatically redirects HEAD requests to corresponding GET handlers if they exist. This redirection causes GET middleware to be entirely skipped, results in an HTTP response without a body due to truncation during the HEAD-to-GET redirect, and still executes the underlying handler. The issue has a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) and is associated with CWE-670 (Always-Incorrect Control Flow Implementation).

Attackers can exploit this vulnerability remotely over the network with no privileges or user interaction required. By sending a HEAD request to a route protected by GET middleware—such as authentication or validation checks—an attacker bypasses those middleware entirely while triggering execution of the target GET handler. This enables unauthorized access or manipulation of application logic, leading to high integrity impacts without compromising confidentiality or availability.

The NestJS security advisory (GHSA-wf42-42fg-fg84) and related GitHub resources detail the fix implemented in version 11.1.16, with a subsequent release at v11.1.17. Practitioners should upgrade to NestJS 11.1.16 or later to mitigate the issue, as evidenced by the patching commit cbdf737cd6e7cefa52d05ecea2ae4af95c464614.