al-ice.ai

Backslash — MCP NeighborJack and over-privileged tool exposure

Security by al-ice.ai Editorial

AI relevance: MCP servers sit directly in agent tool paths, so exposing them on the network or wiring them to shell-capable tools turns a “local helper” into a practical compromise path for AI workstations and agent hosts.

  • Backslash says it analyzed thousands of publicly available MCP servers and found two recurring failure modes: network exposure and excessive host privileges.
  • The most common issue was MCP services bound to 0.0.0.0, making them reachable from the same local network instead of only from the local machine.
  • Backslash labels this pattern “NeighborJack”: a nearby attacker on shared Wi-Fi or office LAN can connect to your MCP server if it is listening broadly.
  • A second recurring problem was arbitrary command execution capability embedded in MCP tools through unsafe subprocess usage or missing input validation.
  • The dangerous combination is obvious: if the MCP server is network-reachable and also exposes shell-ish tools, an attacker may be able to run commands on the host without touching the primary AI client.
  • The research also flags tool poisoning, tool shadowing, rug-pull updates, data exfiltration, and backdoor patterns as things worth scanning for in the MCP ecosystem.
  • Backslash says it did not find clearly malicious MCPs in this sweep, but it did find many servers that were insecure by design or carelessly implemented.
  • The report matters because MCP risk is not just about prompt injection inside the model; it is also about plain old host exposure, command execution, and bad trust boundaries around agent tools.

Why it matters

MCP adoption is expanding faster than its operational hygiene. Many teams still treat MCP servers like harmless local adapters, but they often hold the exact permissions that matter most in agent workflows: file access, shell access, API tokens, and the ability to move data between systems. If those servers listen on the wrong interface or expose overly powerful tools, the attack path stops being theoretical and starts looking like classic lateral movement into an AI operator’s workstation or a developer’s local agent stack.

What to do

  • Bind locally: for local MCP use, prefer stdio transport; if HTTP/SSE is unavoidable, bind to 127.0.0.1, not 0.0.0.0.
  • Kill shell footguns: review MCP tools for direct exec/spawn usage, command templating, and unsanitized arguments.
  • Reduce privileges: run MCP servers with the minimum filesystem, token, and OS permissions needed for the task.
  • Audit tool metadata and updates: treat MCP tool descriptions, registries, and package updates as supply-chain inputs that can influence agent behavior.
  • Segment agent hosts: assume an exposed MCP can become an entry point; restrict east-west access and monitor unusual outbound connections from AI workstations and agent nodes.

Sources