MCP Server Launch - light-tools Default Dangerous Toolset
The @factor-i-o/light-tools MCP server ships with file access, shell execution, SSH/SCP, and service-log tools all enabled unless someone explicitly turns them off. Any AI agent that connects to a default-configured instance gets arbitrary file read/write and command execution on the host with no permission checks in between.
How the attack works
An operator or automated process starts the light-tools MCP server (via npx, bunx, a package manager's dlx command, node, or a direct binary invocation) without passing any tool-restriction or read-only flag. The server comes up with its full default toolset live: file access, shell execution, SSH/SCP, and log-reading tools. Once an AI agent connects to this server, it inherits all of that capability, effectively giving the model direct command execution and remote-host access on the underlying machine. No exploit or vulnerability is needed here — the danger is the default configuration itself.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7b3c1f5a-9d24-4e6b-8f01-2c5a7d9e4b38
- Severity
- Medium
Why it matters
An organisation that runs this server unrestricted exposes its host to arbitrary command execution, file tampering, and lateral movement over SSH/SCP to any agent — human-directed or autonomous — that can reach the server's connection endpoint. This is a configuration exposure that widens an AI agent's blast radius, not evidence of an active breach.
What you can do
- →Restrict the light-tools toolset explicitly at launch time (CLI flag, config file, or LIGHT_TOOLS_* environment variable) instead of relying on defaults.
- →Inventory every agent and service that can reach the MCP server's transport, and confirm none have unnecessary network exposure.
- →Run the server in a sandbox or container with least-privilege file and process permissions if full functionality is genuinely needed.
- →Treat any detected launch as a posture finding: verify it was intentional and authorised, and check whether the toolset was actually restricted even if the command line looks default.
Known benign look-alikes
- Platform or DevOps engineers intentionally running the server in a sandbox or container to evaluate it; the launch is real but authorised.
- CI jobs that boot the server as a fixture for integration tests without using a recognised test runner name or an npm/pnpm/yarn "test" script (the runner and script-name filters miss bespoke harnesses).
- A wrapper script that hardens the server through a config file rather than a CLI flag or LIGHT_TOOLS_* environment variable - the toolset is restricted but the command line looks default.
- A launch whose command line happens to include a path segment matching one of the inspection binaries (e.g. /opt/cat-tools/) would be suppressed, so the inverse false-negative also exists.