如何修复NodeJS调试器命令注入漏洞？附复现与检测方法

Hey there, let's walk through exactly how to fix, reproduce, and detect the Node.js debugger command injection vulnerability you've found in v9.4.0:

The most reliable fixes for this vulnerability are ordered by effectiveness:

• Upgrade Node.js to a patched version
  v9.4.0 is an outdated release, and this specific command injection flaw was fixed in later patches for the v9.x branch—specifically v9.11.2, the final security update for the v9 series. Since v9 is no longer maintained, it’s strongly recommended to upgrade to a supported Long-Term Support (LTS) version like v18.x or v20.x for ongoing security patches.

  • If you use nvm for version management:

    nvm install 9.11.2  # For a direct patch in the v9 branch
    nvm install --lts   # For a supported LTS version (better long-term choice)
    

  • For system-level installations, download the patched version from the official Node.js archives and replace your current binary.

• Restrict debugger access to local only
  If upgrading immediately isn’t possible, ensure the debugger only binds to the loopback address (127.0.0.1) so it’s not exposed to the public internet. Start your Node.js process with:

  node --inspect=127.0.0.1:9229 your-app.js
  

  Never enable the debugger in production environments unless absolutely necessary—use node --no-debug or run your app without debug flags in production.

• Block debug port via firewall
  If remote debugging is required for development, configure your server firewall to only allow incoming connections to port 9229 (the default debug port) from trusted IP addresses. This prevents unauthorized parties from reaching the debugger.

This vulnerability exploits the debugger’s eval functionality, which allows arbitrary code execution if an attacker can connect to the exposed debug port. Only perform this in a test environment—never on production servers:

1. Start a vulnerable Node.js process with the debugger exposed to all network interfaces:

   node --inspect=0.0.0.0:9229 test.js
   

2. Connect to the debugger using Chrome DevTools:
   • Open Chrome and navigate to chrome://inspect
   • Click "Configure" and add your server’s IP address and port (e.g., your-test-server-ip:9229)
   • The process should appear in the "Remote Target" list—click "Inspect" to open the debug console.
3. Execute a malicious eval command to run system commands:

   eval("require('child_process').exec('whoami', (err, stdout) => console.log(stdout.toString()))")
   

   If you see the output of the whoami command, the command injection was successful.

To verify if your server is vulnerable:

• Scan for open debug ports
  Use a port scanning tool to check if port 9229 (or any custom debug port you’re using) is open to the public. On Linux/macOS:

  nmap -p 9229 your-server-ip
  

  On Windows, you can use PowerShell:

  Test-NetConnection your-server-ip -Port 9229
  

  An "open" result means the debugger is exposed.

• Check Node.js process flags
  Inspect how your Node.js processes are started to see if debug flags are enabled and exposed. On Linux/macOS:

  ps aux | grep node
  

  Look for --inspect or --debug flags. If the binding address is 0.0.0.0 (or not specified, which defaults to 0.0.0.0 in older versions), the debugger is exposed to all interfaces.

• Test debugger access
  Try connecting to the debug port using Chrome DevTools (as described in the复现方法 section). If you can successfully connect and execute eval commands, the vulnerability is present.

• Use automated security scanners
  Tools like Nessus, OpenVAS, or Qualys can automatically detect this vulnerability by checking for exposed Node.js debug ports and verifying command injection capabilities.

内容的提问来源于stack exchange，提问作者Rathna Kumar