Shell (lucid-spark) MCP Server

Tools that read sensitive data ([readFile]) and tools that can send data out ([exec]) are exposed together. An agent can move private data to the sink.

Evidence: sources [readFile] → sinks [exec]

Fix: Keep secret-reading and egress capabilities on separate, separately-approved servers.

Location: flow readFile → exec

Tool "exec" appears to run shell commands or evaluate code (keyword "exec" in tool name, parameter "command"). 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 exec

In the server's implementation (`dist/main.js:295`): 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: t { exec, spawn } from "child_process"; import { promisify } from "util"; var execAsync = promisify(exec); var MAX_OUTPU

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 dist/main.js

Tool "writeFile" can write, overwrite or delete files (keyword "writefile" in tool name). Verify it is scoped to a safe directory.

Fix: Constrain file operations to an explicit, non-sensitive root; reject path traversal.

Location: tool writeFile

Tool "exec" takes a command-shaped parameter "command" with no enum/pattern constraint. Free-form, model- or attacker-controlled arguments reaching a shell is the command-injection precondition.

Fix: Constrain the parameter (enum/pattern), or build the command from a fixed template with escaped args.

Location: tool exec · inputSchema.properties.command

Tool "exec" 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 exec

Tool "writeFile" 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 writeFile

Shell command embedded in tool metadata detected in the description of tool "exec". Instruction-like content in tool metadata is executed by the model, not the human, and is the primary tool-poisoning vector.

Evidence: rm -rf

Fix: Tool descriptions should describe behavior, not instruct the assistant. Treat imperative / secrecy / sequencing language in metadata as hostile.

Location: tool exec · description

Tool "readFile" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.

Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.

Location: tool readFile · inputSchema.properties.path

Tool "writeFile" takes a path parameter "path" with no constraint. Without a canonicalize-and-contain check (not visible statically), this permits ../ traversal outside the intended root.

Fix: Resolve and verify the path stays within an allowed root; reject traversal sequences.

Location: tool writeFile · inputSchema.properties.path