Will It Vibe?'eval' on a variable or command substitution
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
eval executes its argument as freshly-parsed shell code. Passing it a variable or a $(...) / backtick substitution means anything that ends up in that value, an environment variable, a config file, a network response, runs with the full power of the script's own privileges. A hardcoded string literal argument does not trigger this rule.
Why it matters
eval re-parses its argument as brand new shell code. When that argument is a variable or a command substitution rather than a fixed string, anything that ends up inside it, an environment variable set by a caller, a config file value, a network response, executes with the full privileges of the running script. This is the shell equivalent of a code-injection vulnerability.
How to fix it
Remove eval and use the value directly wherever possible: an array plus "${arr[@]}" for a dynamic argument list, a case statement or an associative array lookup for dynamic dispatch, or "$@" for forwarding arguments. If eval is genuinely unavoidable (some legacy dynamic-variable-name patterns need it), validate the input against a strict allowlist pattern before it ever reaches eval.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo