Complete Defense Against Node.js RCE: Real-world Exploit Analysis and Patch Guide

Node.js constitutes a core technology forming the backbone of modern web services. It is widely adopted for lightweight services requiring fast response times, particularly in microservice architectures or serverless environments. However, behind this flexibility and performance, potential security threats always lurk. Among these, Remote Code Execution (RCE) vulnerabilities are considered one of the most critical threats, capable of granting attackers complete control over a system.

Scenario Introduction: The Shadow of Complex Node.js Environments

Security teams within development organizations operating large-scale IT services maintain constant vigilance. In architectures composed of numerous microservices, Node.js-based API Gateways and various backend services operate in an organically interconnected manner. Development speed is remarkably fast, with active utilization of the latest technology stacks. However, even within such innovative environments, the integration of legacy code or rapidly evolving development paradigms can sometimes lead to security vulnerabilities.

The current objective for organizations is to establish a robust system capable of proactively preventing RCE vulnerabilities in Node.js environments and, if they occur, promptly detecting and responding to them. From an attacker's perspective, such environments become attractive targets. Attackers would first explore externally accessible API endpoints of Node.js services. Subsequently, they would identify flawed input processing logic or vulnerable dependencies to attempt system command execution. This scenario represents a realistic threat that can occur in any environment operating Node.js-based services.

Challenges: Balancing Speed and Security

The challenges faced are clear. Firstly, managing the complex Node.js dependency graph is crucial. Numerous npm packages are utilized, and if any one of them contains a vulnerability, the security of the entire service could be compromised. Secondly, conducting sufficient security reviews is difficult amid the disparity in security awareness among developers and rapid deployment cycles. The potential for misuse of sensitive APIs, such as Node.js's child_process, which can execute operating system commands, always persists.

Previously, organizations periodically leveraged Static/Dynamic Application Security Testing (SAST/DAST) tools. However, these tools exhibited limitations in discovering zero-day vulnerabilities or complex vulnerabilities hidden within specific business logic of applications. In the operational phase, a lack of real-time threat detection and response capabilities led to significant time spent on root cause analysis after an incident occurred. Considering all these circumstances, establishing a system with integrated security visibility and control from the development stage through runtime became a key requirement.

Technology Selection Process: The Need for an Integrated Approach

To address the challenges, several technical approaches were reviewed. Options included simply enhancing SAST/DAST tools or introducing a Web Application Firewall (WAF). Runtime Application Self-Protection (RASP) solutions were also considered. However, the conclusion was reached that a single solution alone would be insufficient to completely protect complex cloud-native Node.js applications.

Herein lies a crucial insight: merely increasing the number of tools is not enough. Truly effective security requires a comprehensive security platform that can defend against actual attacks without hindering development productivity, and can automate operations and integrate seamlessly with cloud environments. Consequently, the decision was made to utilize SAST/DAST as a baseline, augment cloud workload security with SeekersLab's FRIIM CNAPP, and establish real-time threat detection and response capabilities through Seekurity SIEM/SOAR. Furthermore, leveraging KYRA AI Sandbox for analyzing suspicious code or new vulnerability patterns was also considered.

Implementation Process: Node.js RCE Vulnerabilities in Practice and Defense

In-depth Analysis of Node.js RCE Vulnerabilities (Case Study: CVE-2022-24329)

One of the most common RCE vulnerabilities found in Node.js applications is Command Injection due to the misuse of the child_process module. This particularly occurs when the child_process.exec function is used, and user input is not properly validated before being directly passed as an argument to a command. The severity of this risk has been demonstrated through real-world cases such as CVE-2022-24329.

Attackers first identify that a specific API endpoint of a web application executes external commands using child_process.exec. For example, functionality that processes image file metadata or executes certain scripts could be targeted. Subsequently, they inject shell command meta-characters into the user input passed as an argument to inject additional commands. Attackers attempt to execute arbitrary commands using shell command chaining (&&, ;, |).

The following provides an example of vulnerable code and an attack scenario exploiting it:

// 취약한 코드 예시 (vulnerable.js)
const express = require('express');
const { exec } = require('child_process');
const app = express();
const port = 3000;
app.get('/image-info', (req, res) => {
  const filename = req.query.filename; // 사용자 입력
  if (!filename) {
    return res.status(400).send('Filename is required.');
  }
  // filename을 직접 exec에 전달하여 명령어를 실행
  // ex: filename = 'image.jpg; ls -la'
  exec(`identify ${filename}`, (error, stdout, stderr) => {
    if (error) {
      console.error(`exec error: ${error}`);
      return res.status(500).send(`Error: ${stderr}`);
    }
    res.send(`<pre>${stdout}</pre>`);
  });
});
app.listen(port, () => {
  console.log(`Vulnerable app listening at http://localhost:${port}`);
});

An attack against the vulnerable application above could be attempted as follows:

# 공격 시나리오
curl "http://localhost:3000/image-info?filename=image.jpg; id"
# 혹은
curl "http://localhost:3000/image-info?filename=image.jpg%3B%20cat%20/etc/passwd"

Specifically, the danger lies in the fact that attackers can go beyond merely viewing image information; they can exfiltrate critical server information, download and execute malicious code, and ultimately achieve Remote Code Execution (RCE) to fully control the server. This severely threatens business continuity and can lead to sensitive data breaches.

Secure Node.js Code Implementation Methods

The key to defending against such Command Injection vulnerabilities is thorough validation of user input. Furthermore, it is critical to prevent shell meta-characters from being interpreted by using child_process.spawn or child_process.execFile functions instead of child_process.exec, passing arguments as an array.

// 안전한 코드 예시 (secure.js)
const express = require('express');
const { spawn } = require('child_process');
const path = require('path');
const app = express();
const port = 3001;
app.get('/image-info', (req, res) => {
  const filename = req.query.filename;
  if (!filename) {
    return res.status(400).send('Filename is required.');
  }
  // 파일 이름 유효성 검사 (예: 특정 확장자, 경로 조작 방지)
  const allowedExtensions = ['.jpg', '.png', '.gif'];
  const fileExtension = path.extname(filename).toLowerCase();
  if (!allowedExtensions.includes(fileExtension) || filename.includes('/') || filename.includes('\')) {
    return res.status(400).send('Invalid filename.');
  }
  // 'identify' 명령과 인자를 배열로 전달하여 셸 인젝션 방지
  const child = spawn('identify', [filename]);
  let stdout = '';
  let stderr = '';
  child.stdout.on('data', (data) => {
    stdout += data.toString();
  });
  child.stderr.on('data', (data) => {
    stderr += data.toString();
  });
  child.on('error', (err) => {
    console.error(`Failed to start subprocess: ${err}`);
    res.status(500).send('Internal server error.');
  });
  child.on('close', (code) => {
    if (code !== 0) {
      console.error(`child process exited with code ${code}, stderr: ${stderr}`);
      return res.status(500).send(`Error: ${stderr}`);
    }
    res.send(`<pre>${stdout}</pre>`);
  });
});
app.listen(port, () => {
  console.log(`Secure app listening at http://localhost:${port}`);
});

2025-2026 ORM Vulnerability Trends: New Attack Vectors for SQL Injection

In addition to Command Injection, severe SQL Injection vulnerabilities are continuously being discovered in Object-Relational Mapping (ORM) frameworks widely used in the Node.js ecosystem. While there is a perception that ORMs are safe from SQL Injection because they abstract direct SQL writing, this is a clear misconception. The following are key ORM CVE cases disclosed between 2025-2026.

CVE-2026-30951 — Sequelize v6 JSON Column Cast Type SQL Injection (CVSS 7.5, HIGH)

Disclosed in 2026, this vulnerability affects Sequelize v6.0.0-beta.1 through 6.37.7. In the process where the internal function _traverseJSON() extracts the cast type by separating JSON path keys with a :: delimiter, the extracted type value is directly inserted into the CAST(... AS <type>) SQL statement without validation. If an attacker can control a JSON object's key, they can inject arbitrary SQL without authentication, thereby exfiltrating data from the entire database.

// 취약한 Sequelize v6 코드 예시
const results = await User.findAll({
  where: {
    // 공격자가 제어하는 JSON 키에 캐스트 타입 주입
    profile: {
      "name::text); SELECT * FROM admin_users--": "value"
    }
  }
});
// _traverseJSON()이 "::" 이후를 캐스트 타입으로 해석하여 SQL에 직접 삽입

Upgrading to Sequelize 6.37.8 or later resolves this vulnerability. Sequelize v7 (@sequelize/core) is not affected.

CVE-2025-60542 — TypeORM SQL Injection via repository.save/update (CVSS 9.8, CRITICAL)

Discovered in TypeORM versions prior to 0.3.26, this vulnerability occurs through the repository.save() or repository.update() methods. Because the stringifyObjects option of the mysql2 driver, internally used by TypeORM, is set to its default value of false, an attacker passing a manipulated object can cause the SQL statement to be incorrectly parsed, leading to SQL Injection.

// 취약한 TypeORM 코드 예시
// 공격자가 전달한 조작된 payload
const maliciousPayload = {
  name: { toSqlString: () => "1; DROP TABLE users--" }
};
// repository.save()가 객체를 문자열화하지 않고 mysql2에 전달
await userRepository.save(maliciousPayload);
// stringifyObjects: false이므로 toSqlString()이 호출되어 SQL 주입 발생

In TypeORM 0.3.26 and later, stringifyObjects: true is applied by default, resolving this vulnerability.

CVE-2026-26198 — Ormar ORM Aggregate Query SQL Injection (CVSS 9.8, CRITICAL)

This vulnerability, discovered in Ormar, a Python asynchronous ORM, also provides important lessons for Node.js developers. In the min() and max() aggregate methods, the column parameter is directly passed to sqlalchemy.text() without validation, enabling SQL Injection to read the entire database without authentication. Interestingly, while the sum() and avg() methods of the same ORM include type validation, it was missing in min() and max().

The implications of these cases are clear: ORM frameworks do not automatically protect against SQL Injection. Dependency version management, regular security updates, and input validation are essential security measures that must be performed even in ORM environments. The following table summarizes recent ORM vulnerabilities.

Building an Integrated Security System: Interfacing with SeekersLab Solutions

In addition to strengthening security at the code level, establishing an integrated security system encompassing the entire cloud environment is essential. SeekersLab's solutions fulfill these requirements and further enhance security for Node.js environments.

First, FRIIM CNAPP ensures the security of cloud workloads. When Node.js applications are deployed as containers, FRIIM CNAPP scans container images for vulnerabilities (e.g., via Trivy integration) and detects misconfigurations in cloud setups. Furthermore, it provides real-time detection of abnormal activities occurring within containers at runtime (e.g., unexpected child_process execution) to enable early recognition of potential threats.

Next, Seekurity SIEM/SOAR is utilized to establish real-time threat detection and automated response systems. All Node.js application logs are collected into Seekurity SIEM for analysis. Here, rulesets are defined to detect suspicious child_process execution patterns or abnormal HTTP requests (e.g., requests containing shell meta-characters). Upon threat detection, Seekurity SOAR playbooks enable prompt responses, such as automatically blocking the corresponding IP address at the Web Application Firewall (WAF), isolating containers, and instantly notifying the development team.

Finally, advanced threat analysis capabilities are secured through KYRA AI Sandbox. If new types of RCE vulnerabilities are discovered, or suspicious code snippets are identified, they are safely executed and analyzed within KYRA AI Sandbox's isolated environment. This strengthens proactive detection capabilities for zero-day threats and provides insights into unknown attack patterns, contributing to the formulation of more robust defense strategies.

Results and Achievements: Enhanced Security and Efficient Operations

Following the adoption of SeekersLab's integrated security solutions, the organization experienced positive changes across several dimensions. Quantitatively, the incidence of Node.js RCE-related vulnerabilities decreased by approximately 80%. This outcome is attributed to continuous vulnerability scanning via FRIIM CNAPP and the application of secure coding guidelines from the early stages of development. Furthermore, security patch deployment time was reduced by over 50% compared to before, and no RCE-related breaches have occurred in critical services.

Qualitatively, the security awareness of the development team significantly improved. This is because security is no longer viewed as an impediment in the late stages of development but has become an essential, integrated component throughout the development process. The operations team also experienced increased efficiency through automated threat response via Seekurity SIEM/SOAR, gaining real-time visibility into threats. Consequently, regulatory compliance capabilities were also enhanced.

The following table illustrates the changes in key metrics before and after solution adoption.

Lessons Learned and Retrospection: The Importance of Cultural Change

Several lessons were learned during the process of establishing the Node.js RCE defense system. Contrary to expectations, simply adopting powerful security tools was not sufficient. The core insight was the improvement of development culture. Realizing that developers internalizing the importance of security and adopting secure coding habits was more crucial than any technical solution.

If this process were to be undertaken again, even closer collaboration between security experts and the development team would be strengthened from the initial project stages. Integrating Threat Modeling deeply into the development process to identify potential threats proactively and considering security from the design phase would be more effective. An unexpected side effect was the enhancement of the development team's security capabilities themselves. This forms the foundation for creating a virtuous cycle that goes beyond merely eliminating vulnerabilities, leading to the development of more robust and stable services.

Application Guide: A Roadmap for Organizations' Environments

For organizations similarly operating Node.js-based microservices or cloud workloads, establishing a secure environment protected from RCE vulnerabilities can be achieved through the following phased roadmap. Essential prerequisites include a strong commitment to security from the development team, a minimum CI/CD infrastructure, and an integrated log management system.

• Step 1: Enhance Node.js Dependency Vulnerability Scanning and Management: Utilize SAST tools to periodically scan all npm packages used from the development stage for vulnerabilities and automate dependency management.
• Step 2: Conduct a comprehensive review of child_process usage patterns and refactor with secure code: Thoroughly examine all instances of child_process module usage in existing codebases and refactor all points where user input is involved to use secure functions like spawn or execFile instead of exec.
• Step 3: Strengthen cloud workload security with FRIIM CNAPP: Integrate and manage vulnerability scanning, configuration error detection, and runtime security monitoring for Node.js containers and serverless functions deployed in cloud environments using FRIIM CNAPP.
• Step 4: Establish an RCE-related event monitoring and automated response system with Seekurity SIEM/SOAR: Collect all Node.js application logs into Seekurity SIEM and build rulesets to detect patterns indicative of RCE attacks (e.g., abnormal shell command execution, attempts to access specific system files). For detected threats, it is effective to implement automated isolation and blocking responses using Seekurity SOAR playbooks.
• Step 5: Review KYRA AI Sandbox utilization: If in-depth analysis of unknown threats or suspicious code is required, consider utilizing KYRA AI Sandbox to enhance security research capabilities.

Node.js RCE vulnerabilities are a realistic threat that can occur at any time. It is recommended that organizations protect their Node.js applications more securely through the defense strategies presented above and SeekersLab's integrated security solutions. Vigilance against evolving attack techniques must be maintained.