# MCP Server Launch - light-tools Default Dangerous Toolset

- **Severity:** Medium
- **Signature ID:** `7b3c1f5a-9d24-4e6b-8f01-2c5a7d9e4b38`
- **OWASP:** LLM03 (Supply Chain), LLM06 (Excessive Agency)

## Summary

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.

## 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.

## References

- https://www.npmjs.com/package/@factor-i-o/light-tools
- https://modelcontextprotocol.io/docs/concepts/tools
- https://attack.mitre.org/techniques/T1195/002/

---
Source: https://www.netzilo.com/threats/mcp-light-tools-default-dangerous-tools