Agentic AI is on the rise, and Model Context Protocol (MCP) servers are fast proving to be essential tools for providing AI models greater context for reasoning. But security researchers warn that a large number of these publicly shared servers, which link large language models (LLMs) to a variety of third-party services, data sources, and tools, have insecure configurations that could be abused by attackers to compromise systems or leak sensitive data.
Researchers from application security firm Backslash recently scanned thousands of MCP servers in public repositories and found hundreds that had dangerous misconfigurations, including default exposure to untrusted networks and OS command injection paths.
“Beyond code execution, MCPs can serve as stealthy pathways for prompt injection and context poisoning,” Backslash researchers wrote in a report on the MCP server vulnerabilities. “Malicious or manipulated public content can change what an LLM sees — returning misleading data, or rerouting agent logic.”
MCP servers: Vital AI agent infrastructure
The Model Context Protocol, developed by AI company Anthropic, aims to standardize how LLMs interact with external data sources and tools bidirectionally and in a memory-persistent way to improve their context for reasoning. This is critical for building AI agents and for vibe coding, a development practice in which LLMs are guided to build entire applications based on natural language prompts from humans.
Released less than a year ago, the protocol has seen rapid adoption with tens of thousands of servers — applications that link LLMs to specific services and proprietary tools — now published online. Anthropic itself has published reference implementations of MCP servers for interacting with Google Drive, Slack, GitHub, Git, Postgres, Puppeteer, Stripe, and other popular services. In March, OpenAI adopted MCP, and Google announced plans in April to integrate MCP with its Gemini models and infrastructure.
There are also MCPs that integrate with popular AI-assisted integrated development environments (IDEs) such as Cursor, Windsurf, and Zed. In addition to accessing external tools, MCPs can interact with local file systems, build knowledge graphs in system memory, fetch web content using local command line tools, and execute system commands, among other tasks.
‘NeighborJack’: Opening MCP servers to the internet
Many MCP servers lack strong authentication by default. Deployed locally on a system, anyone with access to their communication interface can potentially issue commands through the protocol to access their functionality. This is not necessarily a problem when the MCP server listens only to the local address 127.0.0.1, also known as localhost, which ensures it can be accessed only by applications running on the same machine.
But Backslash researchers found hundreds of MCP servers configured by default to bind their communication interface to 0.0.0.0, meaning all network interfaces. As a result, such servers are exposed to the internet as well if no additional firewall is in place — a configuration issue the researchers have dubbed “NeighborJack.”
“Imagine you’re coding in a shared coworking space or café,” the researchers suggested. “Your MCP server is silently running on your machine. The person sitting near you, sipping their latte, can now access your MCP server, impersonate tools, and potentially run operations on your behalf. It’s like leaving your laptop open — and unlocked for everyone in the room.”
Unauthenticated OS command execution
The extent of abuse to an MCP server depends on its specific functionality. In many cases an attacker might be able to query a proprietary data source or access a third-party service through credentials configured on the MCP.
For dozens of MCP servers, however, the researchers were able to identify attack paths that resulted in arbitrary command execution on the underlying operating system with the privileges of the server. Examples of identified issues include careless use of a subprocess, a lack of input sanitization, or security bugs, such as path traversal.
“When network exposure meets excessive permissions, you get the perfect storm,” the researchers said. “Anyone on the same network can take full control of the host machine running the MCP server — no login, no authorization, no sandbox. Simply full access to run any command, scrape memory, or impersonate tools used by AI agents. And yes, we found several servers with this exact combination.”
Prompt injection and context poisoning
Because MCP servers are built to access data sources, such as databases, and to scrape documents and web content using a variety of tools, they have a large remote attack surface via malicious input.
In one proof-of-concept, the Backslash researchers built an MCP server that used the Cheerio library to extract metadata from web pages. They then pointed it to a website that contained hidden text in the title tag designed to read like a system prompt for an LLM.
The MCP was linked to the Cursor IDE, so when it executed the web scraping, Cursor interpreted the prompt, which instructed it to send the user’s locally configured OpenAI key back to the website controlled by the researchers. This is an attack known as prompt injection and context poisoning.
“In a yet-to-be-released finding, we identified an exploit path involving a seemingly benign public document that becomes the trigger for a cascading compromise — because the MCP silently connected it into the LLM agent’s logic without proper boundaries,” the researchers added. “The issue wasn’t a vulnerability in the MCP code itself, but rather in the configuration of the data source it accessed. This issue affects a very popular tool with 10,000s of users, and we’re currently working with the vendor to coordinate responsible disclosure.”
Mitigation
The Backslash team published its risk assessments of the tested MCPs in a free searchable database called the Backslash MCP Server Security Hub. The researchers also offer a free web-based service for evaluating IDE configurations for MCPs, LLMs, and active vibe coding rules that could introduce security risks, however the tool requires registration.
For MCP server developers, the team has several recommendations, including validating and sanitizing all external input, restricting filesystem access, avoiding the leak of sensitive data such as tokens and internal logs in LLM responses, implementing access controls on API calls and tool functionality, validating the source of the data, and relying on standard input/output (stdio) transport for local MCP tools instead of server-sent events (SSE).