Three eval-related findings are confirmed because the skill recommends executing LLM-generated expressions, despite restricted builtins and a sandbox. The remaining static findings are false positives caused by markdown backticks, headings, prose, or legitimate web and RPC guidance.
3
Files scanned
587
Lines analyzed
6
Review items
0
False positives ignored
Capability review items (3)
These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.
LLMs can't reliably inspect characters in their input (they hallucinate em dashes, miscount characte
The skill explicitly recommends evaluating expressions generated by an LLM. A sandbox and restricted builtins reduce exposure, but dynamically executing generated code remains a real escape and resource-exhaustion risk.
# Step 2: eval() all checks in one sandbox — deterministic, no hallucination
The example executes LLM-produced checks with eval inside a sandbox. The isolation is a mitigation, not proof that arbitrary generated expressions are safe.
The example directly calls eval on c["expression"]. The globals restrict builtins and expose only text and basic functions, but attacker-influenced rules could still abuse parser or sandbox weaknesses.
Most static command findings are false positives caused by Markdown inline-code markers in documentation. One example evaluates LLM-generated expressions and is a high-risk code-execution pattern; a separate RPC example accepts an endpoint parameter and warrants endpoint controls.
2
Files scanned
565
Lines analyzed
5
Review items
0
False positives ignored
Capability review items (2)
These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.
The example evaluates expressions generated by an LLM. Restricting builtins does not make eval safe, because attacker-controlled expressions can exploit exposed objects or consume sandbox resources.
The sample performs an HTTP POST to rpc_url, which is a function parameter. Generated contracts must constrain this endpoint to avoid arbitrary outbound requests.
The audit confirmed the eval guidance in SKILL.md lines 393-412 as a real dynamic code execution risk because it recommends evaluating LLM-generated Python expressions. The cross-chain RPC example also introduces low-risk outbound network access. The remaining backtick, key, and reconnaissance detections are Markdown or terminology false positives, and no prompt injection attempt was found.
2
Files scanned
565
Lines analyzed
7
Review items
0
False positives ignored
Capability review items (4)
These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.
LLMs can't reliably inspect characters in their input (they hallucinate em dashes, miscount characte
The guidance recommends eval() on Python expressions generated by an LLM from natural-language rules. Even with sandboxing, it encourages generated contracts to execute attacker-influenced code.
# Step 2: eval() all checks in one sandbox — deterministic, no hallucination
The example explicitly instructs evaluating all LLM-generated checks in a sandbox. Sandbox confinement reduces impact, but dynamic evaluation remains a real attack surface.
The code directly calls eval(c["expression"]) on expressions generated from user-controlled rule text. The builtins allowlist helps, but arbitrary expression evaluation is still unsafe.
The surrounding example performs an external RPC POST using a caller-provided rpc_url. This is legitimate for cross-chain verification, but it can create network abuse risk without endpoint controls.