Potential OS Command Injection Vulnerability in node-express-spawn

[SunLingrui]

Potential OS Command Injection Vulnerability in node-express-spawn

Hello,

I am writing to report a critical OS Command Injection vulnerability in the node-express-spawn example project. Because user-supplied input is passed directly to the child_process.spawn function without adequate validation or sanitization, an unauthenticated attacker can execute arbitrary system commands on the host server.

Location of Issue

The vulnerability is located in the routing logic of the Express application, specifically where the requested URL path is used to determine the program to execute.

File: apex/up-examples/aa866c6/oss/node-express-spawn/app.js

Vulnerable Snippet 1 (/cmd/* route):

app.get('/cmd/*', function (req, res) {
  const pgm = req.path.split('/cmd/')[1]; // [!] Untrusted input directly determines the executable
  const args = req.query.args ? req.query.args.split(',') : [];
  
  spawnPgm(pgm, args, (code, output) => { ... });
});

Steps to Reproduce (PoC)

To demonstrate and verify this vulnerability, I have created and attached an automated Proof of Concept (PoC) script (poc_app.js).
poc_app.js

How the PoC works:
Instead of manually starting the server and sending HTTP requests, this script programmatically stubs the Express application to capture the vulnerable route handler. It then simulates an injection attack by passing the touch command to create an empty .txt file (poc_test_file.txt). Crucially, the script includes an automated testing function that asserts whether the new file was successfully written to the filesystem. This provides definitive, programmatic proof of the arbitrary command execution.

Usage Instructions:

1. Download the attached poc_app.js file.
2. Place the file in the exact same directory as the vulnerable target (apex/up-examples/aa866c6/oss/node-express-spawn/).
3. Run the script directly using Node.js:

   node poc_app.js
   

Expected Output (Vulnerable State):
If the application is vulnerable, the script will successfully execute the OS injection, create the file, pass the internal assertion, and output the following confirmation:

Plaintext
[TEST] Executing OS injection vulnerability test...
[TEST PASSED] OS Injection vulnerability confirmed!
 File successfully created via touch command: /<your-absolute-path>/poc_test_file.txt

Proposed Solution

The most robust way to prevent OS Command Injection when allowing users to specify commands is to implement a strict Allowlist (Whitelist). Additionally, POSIX utilities like ls should use the -- separator to explicitly mark the end of command-line options.

In this Pull Request, I have introduced the following fixes:
Defined an ALLOWED_COMMANDS array containing only the intentionally supported executables. Added a check to return a 403 Forbidden status if the requested pgm is not in the allowlist.

Once the proposed Allowlist patch is applied, running this identical PoC script will result in a [TEST FAILED / EXPLOIT BLOCKED] message with a 403 status code, as the script's internal assertion will confirm the malicious file was never created.

[TEST] Executing OS injection vulnerability test...
 [TEST FAILED / EXPLOIT BLOCKED] Assertion failed.
Reason: OS Injection failed: File was not created.
HTTP Status Code returned: 403