Neurolisp MCP Server

Tool "nl_eval_sexpr" appears to run shell commands or evaluate code (keyword "eval" in tool name). Arbitrary execution driven by model input is one of the most dangerous MCP capabilities; combined with any untrusted input it becomes RCE.

Fix: Sandbox execution, allowlist commands/arguments, and never pass model output to a shell unescaped.

Location: tool nl_eval_sexpr

In the server's implementation (`neurolisp/self_optimize.py:349`): Evaluating strings as code is the most direct RCE primitive; if any tool input reaches it, the server executes attacker-chosen code. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: > result from sandboxed eval (skill-roi name) -> Number (try-self-optimize! name) -> Sy

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server neurolisp/self_optimize.py

Untrusted-input tools ([nl_load_template]) co-exist with external-action tools ([nl_eval_sexpr]). A prompt injection could cause unwanted external actions, though no direct sensitive-data leak path was found.

Evidence: untrusted [nl_load_template] → sinks [nl_eval_sexpr]

Fix: Require confirmation for state-changing/egress actions triggered after processing untrusted content.

Location: flow nl_load_template → nl_eval_sexpr

Tool "nl_eval_sexpr" can mutate/egress but declares no destructiveHint. Clients that don't default to spec-safe behavior may not prompt before running it.

Fix: Declare accurate annotations, and gate destructive tools on user confirmation regardless.

Location: tool nl_eval_sexpr

In a packaging/dev/install script (shipped, but not the server runtime) (`tests/test_v5_homoiconicity.py:43`): Evaluating strings as code is the most direct RCE primitive; if any tool input reaches it, the server executes attacker-chosen code. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: """ result = _run("(eval (list '+ 10 20))") assert result == Number(30) def test_eval_sees_global_env(): e

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server tests/test_v5_homoiconicity.py

In a packaging/dev/install script (shipped, but not the server runtime) (`tests/test_v5_sexpr_tools.py:100`): Evaluating strings as code is the most direct RCE primitive; if any tool input reaches it, the server executes attacker-chosen code. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: """ result = _run('(eval (string->sexpr "(+ 10 20)"))') assert result == Number(30) # ─── sexpr-walk ─────────

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server tests/test_v5_sexpr_tools.py

In a packaging/dev/install script (shipped, but not the server runtime) (`tests/test_v26_19_hash_cross_process_stability.py:27`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.

Evidence: ] = hashseed proc = subprocess.run( [sys.executable, "-c", code], capture_output=True, text=

Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.

Location: server tests/test_v26_19_hash_cross_process_stability.py