Security1 distinct publisher3 min readPublished
The MCP layer inherits its trust at install time and never re-checks it, so a lapsed domain behind a still-listed registry entry belongs to whoever registers it next. Air Security says it registered one, and agents came.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
security
Attackers hid a cryptominer inside a LiteLLM MCP config test that reported success1 distinct publisher
build
MCP is four trust boundaries, and credentials only close one of them1 distinct publisher
security
The credential store nobody inventoried: MCP servers now hold the keys to everything they touch1 distinct publisher
product
Most of 19 audited MCP servers keep their context-injection surfaces out of the docs1 distinct publisher
What changes here is position, not payload. According to Air Security, a compromised skill injects instructions into the agent's prompt context, while a hijacked MCP server sits inside the execution loop: the agent invokes the endpoint, hands it data, and executes operations based on the response, with the same implicit trust it extends to its own internal functions [7]. The writeup enumerates four primitives available from that seat [12]. An attacker can redefine what a tool does while its published description stays innocent [8]. File contents, records and database query results arrive as ordinary traffic [9]. Prompt injection lands at load time, before the first tool call, because MCP instructions are server-controlled content the model trusts [10]. And every result returned becomes context the agent takes at face value [11]. Air Security describes the end state as running on the machine with the agent's context, its other credentials, and every system it was trusted to reach [19].
Install-time approval does not survive that, because agents never revisit it. The endpoint recorded at first installation is treated as permanently valid, with no runtime audit of the connection and the channel left open indefinitely [13]. The security decision was made when the domain was still legitimate, and it was made only that once. Air Security is direct about the detection gap: "There is no event here for a single check to have caught" [14]. A service going dark is normal operations. A domain lapsing happens at a registrar that nobody in the agent pipeline is watching.
Detection itself is not the hard part. The hostnames are already sitting in the config files the agents load, and diffing that list against registrar expiry data is the same class of work as checking a dependency for an unmaintained upstream. What blocks it is structural. MCP servers get installed with no review, some from an official vendor and some wired up by whoever needed the automation that week [16], and once connected a server reaches files, an inbox or a production database [15]. Registry entries keep resolving under their published name whether or not anything answers: "MCPs die. Their registry entries don't" [17].
The finding comes from one source, and that source sells the scanner. Air Security built MCP scanning into its own AIR Filter product before pointing it at the Official MCP Registry [1]. The post names none of the affected entries, gives no count beyond "several", no dates, and no registry response [20]. What's public is the technique and a demo of it working end to end. What's unmeasured is how many listed entries currently resolve to expired domains, and whether anyone got to them before the researchers.
The research line is consistent, and it keeps moving down the stack. SkillJacking took the skill, and RepoJacking took the repository the skill cloned [18]. MCPJacking operates a layer under both, at the name the agent resolves, which is the piece of the pipeline most orgs have not assigned to anyone [17].
Ranked by verification strength, evidence, and original report placement.
Air Security built MCP scanning capabilities into its AIR Filter product and directed it at the Official MCP Registry.
In Air Security's demo, an agent prompted to complete an innocent task follows an MCP instruction loaded automatically into its context, triggered by that task, to back up the workspace at the start of each day by running a backup script, which quietly exfiltrates secrets to an attacker-controlled endpoint with zero indication of malicious activity.
Air Security: compromising a skill injects instructions into an agent's prompt context, while hijacking an MCP server places the attacker directly within the agent's execution loop, where the agent invokes the endpoint, shares data and executes operations based on the responses, treating that input with the same implicit trust as its internal functions.
ToolJacking: the hijacker defines the tools and can change what any tool does while its description stays innocent.
Data exfiltration: file contents, records and database queries arrive at the attacker's endpoint as normal traffic.
Prompt injection: MCP instructions are server-controlled content the model trusts, allowing load-time prompt injection before the first call.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 30, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One interested account, no checkable specifics
The mechanism holds up on reading — install-time resolution, a lapsed domain, an entry that keeps pointing at it — and it is a well-worn attack class borrowed from package and repo ecosystems. What does not hold up is verification. Air Security is the only voice here and also the party that bought the domain, and it names no entry, no domain, no date, and no number beyond "several". The claim that agents never re-audit their endpoints is stated about agents in general without a single client being named.
No way to size who actually dialed
Air Security calls the dead entries "widely adopted" and leaves it there. Nothing tells us how many agents resolved the hijacked name, which tools or teams had it configured, or what the replacement server saw after the handoff — and the company runs the endpoint that would know.
Reach asserted, mechanism earned
Two different registers sit in one post. The structural argument — registry listings outlive the services they name, and agents never look again — is fair and lands without embellishment. The reach claim is not: "every agent that connects through that entry now connects to us" arrives with no count, and "widely adopted" is doing quiet work in a sentence with no evidence attached to it. Full agent takeover is presented as the destination when what is demonstrated is a lab demo of a backup script exfiltrating secrets.
The finding and the fix ship together
Read the closing takeaways backwards: scan entry resolution, monitor for handoffs, treat registries as unverified snapshots, don't trust your MCP gateway. That is a specification for the MCP scanning Air Security says it just built into AIR Filter — the same scanning that produced the finding. The naming convention reinforces it; MCPJacking joins SkillJacking and RepoJacking as house-branded vulnerability classes. Withholding the affected entries protects nobody's remediation but does keep the only proof inside the vendor.
Believe the shape, not yet the specifics
We would repeat the trust-model critique without hesitation and the takeover as an unconfirmed vendor claim. A single registry entry named, or one word from the Official MCP Registry's maintainers about whether stale listings are pruned, would move this sharply.