Critical NestJS Vulnerability Allows Remote Code Execution on Developer Machines

A critical Remote Code Execution (RCE) vulnerability has been discovered in the NestJS development tools package, allowing malicious websites to execute arbitrary commands on developers’ local machines.

The vulnerability, tracked as CVE-2025-54782, affects the @nestjs/devtools-integration package and has been assigned a critical CVSS score.

The issue was published by Kamil Mysliwiec, the creator of NestJS, just two days ago and represents a significant security threat to the JavaScript development community.

The security vulnerability resides in the @nestjs/devtools-integration package versions 0.2.0 and earlier, which exposes a local development HTTP server during NestJS application development.

The vulnerable endpoint /inspector/graph/interact accepts JSON input containing executable code and processes it through an unsafe JavaScript sandbox implementation that closely resembles the abandoned safe-eval library.

The core problem stems from the Node.js vm.runInNewContext sandbox, which is explicitly documented by Node.js as not providing adequate security mechanisms for executing untrusted code.

The vulnerable sandbox implementation attempts to disable dangerous constructors but can be trivially bypassed using well-known escape techniques.

The package’s unsafe code execution occurs when developers enable the devtools integration in their local development environment, creating an attack surface that malicious actors can exploit remotely.

NestJS Vulnerability

Attackers can exploit this vulnerability by combining Cross-Site Request Forgery (CSRF) techniques with sandbox escape methods.

The devtools server sets an Access-Control-Allow-Origin header to a fixed domain but fails to validate the request’s Origin or Content-Type headers properly.

This oversight allows attackers to craft malicious POST requests using simple HTML forms or XMLHttpRequest calls with text/plain content type, effectively bypassing CORS preflight security checks.

A successful attack requires minimal user interaction – developers need only visit a malicious website while running their NestJS development server locally  the same payload can be sent via a simple XHR request with text/plain content type:

The attack payload leverages JavaScript sandbox escape techniques, specifically exploiting the propertyIsEnumerable function to access the process object and subsequently execute system commands through Node.js child_process module.

Proof-of-concept demonstrations show attackers can launch applications like Calculator on macOS or execute more dangerous commands with the same privileges as the development server.

Security Recommendations

The NestJS maintainers have released version 0.2.1 of @nestjs/devtools-integration, which addresses all identified security issues.

The patch implements three critical security improvements: replacement of the unsafe sandbox with @nyariv/sandboxjs, addition of proper origin and content-type validation for incoming requests, and introduction of authentication mechanisms for devtools connections.

Developers using NestJS with devtools integration should immediately upgrade to version 0.2.1 or later.

The vulnerability’s critical nature stems from its low attack complexity and the minimal user interaction required for successful exploitation.

Security researchers emphasize that this incident highlights the broader risks associated with development tools that expose local services without adequate security controls.

Organizations should audit their development environments for similar vulnerabilities and implement security policies that govern the use of development packages in local environments.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.