MCPJacking: How Expired Domains Take Over Registry MCP Servers
MCPJacking is AIR Security's name for a takeover needing no vulnerability, no stolen account and no edited registry entry: the service behind a listed MCP server goes offline, the domain its listing resolves to lapses, and whoever registers that domain next inherits the listing's trust. Published 27 August 2026, the research reports 155 hijackable MCP entries in the official MCP registry. No CVE has been published; there is no code to patch. It is dangling DNS, aimed at an agent's tool endpoint. Background: the MCP Server Security guide.
What AIR Security reported
AIR's chain, in its own words: the service behind a legitimate listed entry "went offline, and the domain its listing resolves to has expired"; "the official registry kept the entry live"; "we registered the domain"; "we published our own MCP behind it, answering as the original"; "every agent that connects through that entry now connects to us."
Read that as a researcher demonstration. AIR describes registering the lapsed domains and publishing its own servers behind them - "we simply registered them, published our own MCPs" - and claims the team "gained full remote prompt execution on every agent that trusted them." It publishes a video demo of the technique but no list of affected servers, no domains and no logs; it names no agent or operator and reports no incident response, so the claim of reaching live agents stands as the vendor's, not a verified result. AIR names no affected server, author, domain or entry, so there is nothing to check yourself against, and the 155 is one vendor's own scanner output - the case for an owner-assigned internal MCP registry. No CVE or independent reproduction has been published since.
What the registry verifies, and what MCPJacking slips past
The official MCP Registry - itself still in preview, per its own documentation ("Breaking changes or data resets may occur before general availability") - does verify, but the precise version matters. Its documentation says namespace authentication ensures "that servers come from their claimed sources," with reverse-DNS naming that "ties them to verified GitHub accounts or domains." The challenge proves the namespace, not the address: server.json carries "where to locate the server (e.g., npm package name, remote server URL)" as separate metadata the registry never challenges. And that proof is taken once, at publication, while namespace control itself transfers by expiry and re-registration. It covers the name, not the endpoint behind it - which puts MCPJacking, on Anomity's reading, alongside the abandoned-namespace reclaims in the AI supply-chain defender's guide.
What differs from the web version is review cadence: a dangling CNAME is found when a human loads the page, while an MCP endpoint is loaded by an agent at session start, from a config written once. Agents, in AIR's words, "treat the endpoints defined during the first installation as permanently valid" - the argument in scan-time vetting versus runtime governance. Only remote entries resolving through a domain are in reach, and MCP Queen's July 2026 survey puts roughly half the registry's listings at local-install only. Where OAuth for MCP is involved it sharpens: a reclaimed endpoint inherits an authorization already granted.
The second vector, and what each measurement counted
AIR describes two vectors. The lapsed-domain reclaim is the loud one. The quieter is "a more patient pivot: publishing a perfectly functional, benign tool to gain a foothold, only to quietly update the server later to perform malicious actions" - server-side and, AIR says, "invisible to users and traditional security gateways." Same shape as MCPoison, CVE-2025-54136.
| Source | What it counted | Figure | What it does not establish |
|---|---|---|---|
| AIR Security, 27 Aug 2026 | Entries judged hijackable in the official MCP registry, via AIR's scanner | 155 | No CVE, no published list, no reproduction |
| Li and Gao, arXiv 2510.16558 (DSN 2026) | Invalid server links in four decentralized registries (mcp.so, MCP Market, MCP Store, Pulse MCP), within a 67,057-server survey of six registries | 1,379 invalid; 212 (15.37%) with re-registrable GitHub accounts, plus 304 redirected | GitHub accounts, not expired domains; not the official registry |
| MCP Queen, State of the MCP Ecosystem, July 2026 (data as of 28 Jul 2026) | Remote servers that "advertise an endpoint that does not answer" | 1,603 of 9,326 (17.2%) dead; 18,650 of 18,849 listings marked active | Whether those domains are registrable |
Neither corroborates AIR's 155, and the two reach the mechanism to different depths. Both show entries outliving the service behind them; only Li and Gao show the identifier itself being reclaimable, with 212 of their 1,379 invalid links resting on GitHub accounts free to re-register and 304 more on redirected names. MCP Queen counted endpoints that stopped answering and did not test whether anything behind them could be claimed. The registry itself does no continuous re-verification and no automatic retirement of entries whose service has died: listings carry a status field, and manual takedown is the documented removal path.
Why MCPJacking is an agentic-endpoint risk
The point is position: "hijacking an MCP server places you directly within its execution loop." AIR names four capabilities, one under a name it coined:
- ToolJacking, AIR's word for defining the tools yourself so behavior changes "while its description stays innocent" - tool poisoning from a hijacked endpoint.
- Data exfiltration: file contents, records and database queries arrive as normal traffic (how MCP servers leak secrets).
- Prompt injection at load time, before the first call, because MCP instructions are server-controlled content the model trusts (indirect prompt injection).
- Steering: every result the server returns is trusted context the agent takes at face value.
AIR's negative takeaways, that "Official Registries provide no inherent protection" and "MCP Gateways do not protect from MCPJacking," are a coverage gap, not a dismissal: a gateway still terminates the connection, brokers tokens rather than passing them through, and gives you one chokepoint to revoke at.
How Anomity surfaces and governs MCPJacking
The boundary first: Anomity does not watch WHOIS, resolve DNS, probe MCP endpoints or scan the public registry. MCP servers are declared in per-machine client config, so the endpoint is the authoritative record of what your fleet is wired into. The unprivileged Endpoint Sensor inventories eight AI artifact types per endpoint, MCP servers among them, metadata only (Inside Anomity Discovery).
Then watch for the handoff. A server URL that changes under a stable name, or a new MCP server appearing on a dozen machines in a week: those are the endpoint-visible events, and they land in a queryable 90-day audit trail of every added, changed and removed artifact (how to audit AI agent activity). Diffing the tool definitions a server returns is a separate check, run against the server itself. Where an agent exposes a hook, such as Claude Code's PreToolUse, Anomity returns allow, deny or log on each tool call before it runs; without a hook the honest answer is visibility and audit, metadata only. What no registry can answer and this does: which endpoints still point at a server you have revoked.
You can't govern what you can't see.The Anomity principle
What to check across your fleet
- Enumerate every MCP server your fleet reaches, per machine - you cannot re-verify what you never listed (how to build an AI agent inventory).
- Split remote entries from stdio ones; only domain-resolving servers are in scope for the lapsed-domain vector.
- Record each remote server's domain and expected owner, then re-check ownership on a schedule - publication-time proof does not renew itself.
- Diff tool definitions, not just server lists: the second vector changes behavior server-side under an unchanged name.
- Treat a server that stopped answering as a decision: drop it from client config and rotate the credentials it carried.
- Answer "which endpoints still point at a server we revoked" in one query, then run the AI agent incident response playbook.
MCPJacking is dangling DNS with an agent on the far end, where the listing outlives the service and the trust decision is taken once. AIR's 155 is one vendor's unreproduced count; the mechanism under it is independently measured and predates the post. Treat a listing as a lead, keep the list of servers your machines actually reach, and watch it change. Book a demo to see that list.
Related
- MCP Server Security: The Complete Guide - the pillar this sits under.
- SkillJacking - the same reclaim logic, aimed at skills.
- How to build an MCP server registry - the re-verified internal alternative.
- Where scan-time vetting ends - why install-time verdicts expire.
- AI supply-chain attacks: a defender's guide - the catalogue.
- MCP tool poisoning via hidden instructions - the tool-definition abuse.
Frequently asked questions
What is MCPJacking?
MCPJacking is AIR Security's name for taking over a listed MCP server by reclaiming the expired domain its registry entry resolves to. The service behind a legitimate entry goes offline, its domain lapses, the registry keeps the entry live, and whoever registers that domain next can stand up their own MCP server that answers as the original. No account is stolen and the registry entry is never edited. Mechanically it is dangling DNS, the same subdomain-takeover pattern the web has dealt with for more than a decade, applied to an agent's tool endpoint. AIR also describes a second vector: publishing a genuinely working server, then quietly changing its behavior server-side afterwards.
Were 155 MCP servers actually hijacked?
No. AIR Security reports finding 155 entries it judged hijackable in the official MCP registry, using its own commercial scanner, and describes registering those lapsed domains and publishing its own MCP servers behind them as a research demonstration. AIR names no victim and reports no incident response, though its summary claims the team gained remote prompt execution on agents that connected through the entries, an outcome it publishes no evidence for. The 155 figure is AIR's alone, with no independent corroboration published as of late August 2026, and AIR published no list of affected servers, authors or domains. Treat it as a single-vendor claim about a population, not as a count of compromised systems.
Is there a CVE, a patch, or a version to upgrade to?
No. No CVE, GHSA or other identifier has been published for it, and there is no patch, because the weakness sits in the trust model rather than in any one server's code. Nothing has been published about a disclosure timeline, a vendor response, a registry statement, or the removal of any entry. The High severity on this page is Anomity's own editorial rating, not a CVSS score and not a rating sourced to AIR Security or anyone else. Remediation is a process change - re-verify the endpoints your agents reach on a schedule - rather than an upgrade.
Does the official MCP registry or an MCP gateway protect against this?
Partly, and not in the way most people assume. The official MCP Registry does verify namespace ownership through GitHub, DNS or HTTP challenges, and its documentation says only the legitimate owner of an account or domain can publish under that namespace. Two gaps follow. The challenge covers the name, not the address: the remote server URL is separate server.json metadata that the registry never challenges. And the proof is taken at publication, with no continuous re-verification and no automatic retirement of entries whose service has died, though listings do carry a status field and manual takedown is the documented removal path. Gateways have a different gap. AIR says they often fail to validate the identity or intent of the provider on the far end because they verify the connection path. A gateway still terminates connections, brokers tokens and gives you one place to revoke, so read this as a coverage gap rather than a reason to remove the control.
How do I tell whether my fleet is exposed?
Start from the endpoint, not the registry. MCP servers are declared in per-machine client config, so that config is the authoritative list of what your agents actually reach. Enumerate it, separate remote entries that resolve through a domain from local stdio servers, record the owning domain for each remote entry, and re-check ownership on a schedule. Then watch for change: a server URL that moves under a stable name, or a server still declared on endpoints you thought you had cleaned up. Anomity inventories MCP servers as one of eight AI artifact types per endpoint and records added, changed and removed server entries in a 90-day audit trail, and it can allow, deny or log MCP tool calls where an agent exposes a hook such as Claude Code's PreToolUse. Diffing the tool definitions a server returns is a separate check you run against the server itself.
