eval executes request-derived input
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 25 points from that category, once per scan, no matter how many places it turns up.
What it detects
eval, instance_eval, class_eval, and module_eval compile and run a string as Ruby code. Called with an argument built from params or request, whatever code the client provides in that value runs on the server: arbitrary code execution.
Why it matters
eval and its *_eval relatives compile a string and run it as Ruby code with the full power of the language: reading and writing any accessible state, shelling out, reading files. Building that string from params or request means the client supplies the code that runs on the server, which is remote code execution, not a lesser injection class.
How to fix it
Remove the dynamic eval entirely. Whatever the eval was trying to accomplish (dynamic dispatch, a computed rule, dynamic attribute access) almost always has a safer equivalent: an allowlist-checked send, a case/when, Hash#dig, or a small rules engine that interprets data rather than executing code. If truly dynamic behavior is required, define it as data (a hash of allowed operations) rather than as a string of Ruby source.
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