If your agents call MCP servers you don't operate, here is the attack that costs less than lunch. OX Security's audit of 15,465 public MCP servers (deduplicated to 5,095 unique hostnames) found six sitting on expired domains, re-registerable for $4 to $12 a year. Buy one, stand up a server, and you inherit an established identity plus every agent still configured to call it. You see the queries those agents send, which often carry internal data and credentials. You control the tool descriptions that come back, which is a prompt-injection channel aimed straight at the model.
And it is not one scan. BlueRock scanned 12,000+ servers, AgentAvow statically analyzed 7,029, and the conclusions converge: somewhere between 30% and 82% of public MCP servers carry exploitable flaws, depending on method. Arguing about the exact number is a way of avoiding the work.
The rest of the greatest hits
- Jurisdiction drift. 15.6% of hostnames resolve outside the US, including 19 in China and 18 in Russia. Worse, an operator can launch on a clean US IP and reroute later. A one-time geolocation check at approval is a screenshot of a moving target.
- Servers running from somebody's house. 0.45% route through consumer tunnels like ngrok-free, roughly 70 servers in a dataset this size. Your agent calls a laptop in a spare bedroom with the same trust it gives your internal API.
- The repo you reviewed is not the code that runs. Remote servers can execute backend code that differs entirely from the public repo. AgentAvow flags fetch-then-exec rug pulls (see MCPoison, CVE-2025-54136) and prompt injection embedded in tool descriptions.
- The old web bugs moved into tool calls. BlueRock's numbers: about 33% allow unbounded URI fetch (SSRF), 42% have command injection. MCP servers are often thin wrappers around CLI tools, so the model's argument lands in a shell.
- Composition is the killer. Server A reads your drive, B ingests untrusted web content, C sends email. Each looks fine alone. In one agent, they are an exfiltration pipeline. Also: 492 servers sit on the open internet with zero auth, and only 8.5% of public servers use OAuth.
"Those percentages are tiny"
Your agent does not connect to 15,465 servers. It connects to a dozen. Each connection is a binary trust decision with the full blast radius of that agent's permissions. The attacker does not need most servers to be malicious. They need the one your analyst installed last Tuesday.
"We only use well-known servers." Popularity is exactly what makes a server worth hijacking, and reputation verifies nothing at runtime.
Do this week
- Inventory, then allowlist. Pull every MCP server any agent can reach: mcp.json, IDE and desktop agent configs, gateway routes. One named owner per server. No owner, no connection. Deny everything else at the egress layer.
- Vet domains like an attacker shopping for them. Registration date, expiry, resolution history, then keep checking weekly for anything touching sensitive data:
whois mcp-vendor.com | grep -iE "creat|expir|upd"
dig +short mcp-vendor.com # alert if this answer changes
- Egress proxy, deny by category. Then test the SSRF path: point any fetch-style tool your agent can call at the instance metadata URL and see what comes back.
deny 169.254.169.254/32 # cloud metadata
deny 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
deny *.ngrok-free.app # personal machines
- Stop treating repo review as proof. For remote servers it is a signal, nothing more. Watch runtime behavior and network destinations instead.
Question for the comments: if your agents talk to third-party MCP servers today, what actually detects a server changing its behavior or its IP after approval? Most answers I have heard so far are "nothing," and I would love to be wrong.
Longer writeup with the full ranked findings and methodology: https://axeploit.com/blog/15465-mcp-servers-six-expired-domains-and-the-checklist-your-team-skipped
