How OS Command Injection Actually Works Under the Hood

Every web language has a function that says "run this string as a shell command." PHP has exec, system, shell_exec, passthru, popen. NodeJS has child_process.exec and child_process.spawn. Python has os.system and subprocess. Ruby has backticks and system. The names differ. The danger is identical.

What does the vulnerable code path look like?

The pattern is always the same: user input from a request parameter gets concatenated into a string that is then passed to a command execution function. No sanitization. No escaping. No allowlist validation. The interpreter receives the full concatenated string and executes everything in it.

That PHP snippet looks innocent. A developer wanted to create a PDF file with a user-chosen name. But the filename parameter goes straight into system() with zero filtering. An attacker supplies a filename like report; whoami and the shell executes touch /tmp/report; whoami.pdf. Two commands run. The server just told the attacker which user the web process runs as.

The NodeJS equivalent is equally broken

Template literals make this look modern and clean. They do not make it safe. The req.query.filename value is interpolated directly into the shell command string. Same vulnerability, different syntax. The exploitation payload is identical regardless of whether the backend is PHP, Node, Python, or .NET.

Why the shell interprets your payload

When system() or exec() receives a string, it hands that string to /bin/sh (on Linux) or cmd.exe (on Windows). The shell parses metacharacters like semicolons, pipes, ampersands, and backticks as control operators. Your injected payload exploits this parsing behavior to break out of the intended command and append a new one.

The shell saw the semicolon, treated everything before it as command one, and everything after as command two. It does not care that the semicolon came from user input. It just parses and executes. That is the entire vulnerability in one terminal output.

You now know the anatomy. Next, we compare vulnerable patterns side by side across languages so you can spot them during code review in under ten seconds.