Skip to main content
Return to Blog de Seguridad de TrendAI™
AI & emerging technologies Cloud & supply chain

When AI Agents Trust the Dead: More Than 900 MCP Servers Pointing to Hijackable GitHub Repositories

We examined more than 90,000 GitHub URLs across four major MCP directories and found links that point to deleted accounts; the usernames of these can be claimed by anyone, including attackers. AI agents serving as installers complicate the matter further, raising questions about trust and security.

AI Emerging technologies Cloud Software supply chain Technology, Media, & Communications General Markets Threat reports
November 10th, 2026 2 min read Ashish Verma , Deep Patel
TrendAI
When AI Agents Trust the Dead: More Than 900 MCP Servers Pointing to Hijackable GitHub Repositories
View full report

Key Takeaways

  • We health-checked more than 90,000 unique GitHub URLs across four major MCP (Model Context Protocol) directories and found that roughly 8% are dead, with more than 900 of those dead links pointing to deleted GitHub accounts that anyone can register with no exploit required.
  • More than a quarter (27%) of the hijackable surface came from the top 10 claimable accounts, accounting for more than 240 repositories. A single username was observed claiming up to 92 repositories.
  • More than 80 of the hijackable entries are named after well-known services like AWS, MySQL, PayPal, Shopify, and Telegram, the exact names users search for. We did not find evidence that the directories we examined routinely validate link health, detect namespace changes, or verify code integrity at listed URLs.
  • As AI agents increasingly discover and install MCP servers on their own with no human reading the README or noticing a new owner, this attack is shifting from tricking a user to tricking an agent, a risk the NSA’s AI Security Center flagged in a May 2026 advisory on MCP security design flaws.

In our new research, we scrutinize the security of Model Context Protocol (MCP) server directories, the community platforms where developers find and install AI agent tools.

After sampling or crawling four major directories and health-checking more than 90,000 GitHub URLs in September 2026, we found that more than 900 dead links point to deleted GitHub accounts. The usernames of these accounts can be re-registered by an attacker, inheriting the trust and visibility of every directory listing that still links to them without the need for an exploit.

What we discovered

To start an attack, an attacker needs only a GitHub account. Zero technical sophistication needed: no vulnerability research, no exploit development, no malware obfuscation. Because this doesn’t involve a software vulnerability, there’s no straightforward fix like patching.

Figure 1. Attack chain: from directory listing to full system compromise
Figure 1. Attack chain: from directory listing to full system compromise

Upon checking more than 90,000 unique GitHub URLs, we found that one in every 13 MCP server links points to a repository that no longer exists. Out of the more than 7,000 that are dead, more than 900 are potentially hijackable.

Figure 2. GitHub URL health check results across more than 90,000 unique URLs
Figure 2. GitHub URL health check results across more than 90,000 unique URLs
Figure 3. Classification of more than 7,000 dead links, with more than 900 potentially hijackable
Figure 3. Classification of more than 7,000 dead links, with more than 900 potentially hijackable

Impersonating trusted services

More than 80 of the identified hijackable entries are named after well-known services and platforms. This makes the attack even more dangerous, as the popular services are often the names users would search for in a directory.

The big names include databases such as MySQL and PostgreSQL, dev platforms such as GitHub and Jenkins, and cloud and infrastructure platforms such as AWS and Cloudflare.

Service category Count Namesake services and platforms Risk category Risk profile
Dev platforms 16 GitHub, GitLab, Jenkins, WordPress, and other dev tools Trust and identity Developer tooling integration
Cloud and infra 14 AWS, Supabase, Cloudflare, Netlify, and other cloud providers Infrastructure and data Cloud credentials and infra access keys
Databases 12 MySQL, PostgreSQL, MongoDB, and other popular databases Infrastructure and data Users connect with real database credentials
Productivity 8 Microsoft 365, Notion, Jira, Obsidian, and other enterprise tools AI and productivity data Enterprise and academic user data
Social and messaging 8 Twitter/X, Discord, Telegram, Slack, and other social platforms Trust and identity OAuth tokens, message history at risk
AI/ML 7 OpenAI, Grok, Gemini, and other LLM providers AI and productivity data Multi-model AI routed through attacker
Crypto/DeFi 6 Solana, Ethereum, Binance, and other blockchain networks Financial exposure Direct financial exposure (wallet keys)
Commerce and payments 5 Shopify, Stripe, PayPal, and other ecommerce platforms Financial exposure Store credentials, payment data exposed
3D and gaming 5 Unity, Unreal, Blender, and other 3D/game engines Infrastructure and data Developer workstation access
Table 1. Hijackable entries named after trusted services: service category, count, what they’re named after, risk category, and risk profile

When the installer is an AI agent

When, instead of a human, an AI agent serves as the installer, the AI agent might be easier to trick. For example, a human might notice details such as suspicious instructions in the README or the newness of the account, or take note of reputation signals such as stars and forks. By contrast, an autonomous agent might not evaluate these signals in the same way. This poses greater risk.

Checkpoint Human installer Autonomous agent
Reads the README Skims it; may notice odd or suspicious instructions. Parses it as context to act on, including any injected instructions.
Notices a new owner May spot a brand-new account, a recently created repo, or a changed profile. Has no memory of what the account looked like last month.
Judges reputation Weighs stars, forks, and familiar names. Matches on name and description, exactly the fields the attacker controls.
Speed and volume Installs occasionally, one server at a time. Can evaluate and connect many servers per session, across many users.
Sees the result May notice errors or strange behavior. Tool output flows straight into its context; failures are often retried silently.
Table 2. Comparison of actions by human installer and autonomous agent

Why this matters for organizations

Because MCP servers sit behind a large language model (LLM), attackers can use prompt injection to manipulate the AI into invoking tools on other connected servers. This turns a single compromised server into a cross-service attack, no traditional exploit code required.

Capability What the attacker gets
Arbitrary code execution Local process with the user's OS privileges; no sandbox.
File system access Read/Write any file the user owns: SSH keys, AWS credentials, .env files, source code.
Credential harvesting MCP configuration files store API keys for ALL configured servers in plaintext.
Lateral movement via config A single malicious server can read the config and extract credentials for every other MCP server installed.
Network exfiltration Outbound HTTP to any host. Silent data exfiltration with no network policy enforcement.
LLM context injection Server responses feed directly into the AI's context window. Prompt injection from inside the tool chain.
Persistence MCP servers auto-start with the AI assistant. Attacker's code runs every session.
Table 3. Capabilities and what the attacker gets

Download the full report

Read our technical brief for the full breakdown of our findings and our detection, mitigation, and defense recommendations.