MCP supply chain poisoning shows how trust signals can be faked

At a glance

What this is: This is a supply chain attack on the MCP ecosystem that used cloned repositories and fake credibility signals to deliver credential-stealing malware.

Why it matters: It matters because teams deploying MCP-enabled AI tools need to treat developer-facing integrations as an identity and supply chain risk, not just an AppSec review problem.

👉 Read Straiker’s analysis of the SmartLoader MCP supply chain attack

Context

MCP supply chain poisoning happens when a malicious server or package looks legitimate enough to be trusted by developers, AI tooling, or registry consumers. In this case, the core identity security problem is not just malware delivery, but the abuse of community trust signals that decide what gets installed into developer environments and what AI tools are allowed to call.

That matters for NHI governance because MCP servers, service tokens, and developer credentials sit on the same trust path once an agentic toolchain is in place. When provenance, contributor history, and registry validation can be manufactured, the organisation is no longer reviewing software alone. It is making access decisions about a non-human integration surface that can reach secrets, APIs, and downstream systems.

Key questions

Q: What do security teams need to verify before exposing an MCP server to users?

A: Teams need to verify who can register as a client, what scopes they can request, how tokens are validated, and how consent maps to real tool permissions. If any of those links are vague, the MCP server can expand access beyond the user’s intent or the organisation’s policy. Auditability should be built in before go-live.

Q: Why are MCP ecosystems attractive to attackers targeting secrets and credentials?

A: MCP ecosystems connect AI tools to data sources, APIs, and developer workflows, so a malicious server can sit in the middle of high-value identity paths. That makes them attractive for credential theft, session capture, and downstream access abuse. The risk increases when developer workstations already hold cloud tokens, source control access, and production credentials.

Q: What do security teams get wrong about trusting code repositories?

A: Teams often treat a repository as something to inspect before trusting, but folder-open autoruns turn the repository into an active trigger. That means trust must be established before the repo is opened, not after a task has already executed inside the user’s session.

Q: How can organisations reduce the blast radius of a malicious MCP server?

A: Limit the secrets and session tokens available on developer endpoints, enforce egress monitoring, and separate installation approval from runtime permission. If a server is compromised, the damage is smaller when the workstation does not hold broad access and when suspicious outbound behaviour is detected quickly.

Technical breakdown

How cloned MCP servers become a trust bypass

An MCP registry entry is only as trustworthy as the provenance behind it. Attackers can clone a legitimate server, preserve the functional code, and change the distribution channel, contributor set, and repository metadata so the package looks community validated. That matters because many review workflows still privilege surface indicators like stars, forks, and recent activity. In MCP ecosystems, those indicators can be fabricated at scale, creating a false sense of legitimacy before any code is even executed.

Practical implication: require provenance checks that verify original authorship, commit lineage, and package source before allowing MCP server installation.

Why fake contributor networks defeat superficial review

Contributor lists, forks, and account age are often used as social proof, but they are weak signals when an adversary can create an entire ecosystem of supporting accounts. In this campaign, the trust fabric was built first and the payload came later, which is a classic supply chain pattern adapted to MCP. The technical risk is not only malicious code, but also the deliberate manufacture of legitimacy around that code, making manual inspection unreliable at registry scale.

Practical implication: correlate account creation dates, commit timing, and fork relationships to detect coordinated inauthentic repository ecosystems.

How StealC turns developer machines into credential sinks

StealC is an information-stealing payload designed to harvest browser passwords, session cookies, cloud tokens, SSH keys, API credentials, and wallet data from endpoint environments. In developer workstations, that is especially dangerous because one stolen session often opens access to source control, cloud consoles, production credentials, and internal tooling. Once those secrets are collected, the attacker can move from initial compromise into broader identity abuse without needing to keep exploiting the original MCP server.

Practical implication: monitor developer endpoints for credential theft indicators and block unusual outbound connections from workstation identities.

Threat narrative

Attacker objective: The attacker’s objective was to turn trusted MCP distribution into a credential harvesting channel that expands access beyond the original installation point.

1. Entry occurred when developers discovered the trojanized MCP server through search, registry listings, or apparent community recommendations, then installed it as a trusted integration.
2. Escalation followed when the malicious payload executed on developer workstations and harvested browser passwords, session cookies, cloud tokens, SSH keys, and API credentials.
3. Impact was credential compromise across developer and end-user environments, creating a pathway to data exfiltration, production access, and downstream supply chain abuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP trust signals are becoming identity controls, not just community metadata. Stars, forks, and contributor counts were never strong enough to serve as access-control evidence, but they are increasingly being treated that way in AI integration pipelines. When an MCP server can reach credentials, APIs, and downstream systems, provenance is part of the authorisation decision. Practitioners should treat repository credibility as a security control surface, not a popularity metric.

Manufactured provenance is the new supply chain weakness in MCP ecosystems. This campaign did not rely on a broken exploit chain alone; it relied on enough believable context to get installed. That is a problem for governance models that assume the package review step is about code quality. In MCP environments, the decision is whether to trust a non-human integration point that can inherit real enterprise reach.

Credential theft from developer endpoints is now an MCP governance issue. MCP servers can sit between AI tools and the systems those tools query, which means a compromised server can become a credential capture layer as well as a malicious integration point. That expands the governance scope from package approval to endpoint exposure, token hygiene, and session handling. The implication is that developer identity and non-human integration identity now share the same blast radius.

Identity blast radius is the right lens for MCP risk. Once a malicious MCP server reaches a developer workstation, it can harvest secrets that were never intended for that integration path. Those secrets often unlock cloud consoles, version control, and production tooling, which turns a single deceptive server into a multi-system access event. Security teams need to evaluate how far a trusted integration can travel before any alert fires.

Surface trust has to be replaced with runtime validation. The lesson here is not that every repository is suspect, but that static trust signals are too easy to counterfeit. Runtime checks, provenance validation, endpoint monitoring, and registry intelligence need to work together because no single review step can prove legitimacy. Practitioners should redesign MCP governance around continuous verification rather than one-time approval.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
• That same research also found that companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, which shows how expensive the trust problem has become.

What this signals

Identity blast radius: MCP adoption is turning developer tooling into a high-impact access path, which means organisations need to map which identities and secrets sit behind every approved integration. With 27 days as the average remediation time for a leaked secret in our AppSec secrets research, a stolen token can stay useful long after the original install event.

The security programme implication is straightforward: provenance checks, endpoint monitoring, and secret containment now belong in the same control set. Teams that still separate AppSec, IAM, and developer tooling will miss the combined failure mode this campaign exposed, where a trusted integration becomes both a distribution channel and a credential sink.

The next maturity step is to treat MCP registries like identity admission points and to pair that with continuous behavioural review. That is the only way to reduce dependence on surface trust signals that can be manufactured at registration time.

For practitioners

• Verify MCP provenance before installation Check original authorship, commit lineage, account age, and contributor relationships before approving any MCP server. Do not rely on stars, forks, or registry placement as proof of legitimacy.
• Treat developer workstations as high-value identity targets Assume a malicious MCP server can harvest browser passwords, session cookies, cloud tokens, SSH keys, and API credentials from endpoints used by engineers.
• Correlate repository behaviour for inauthentic ecosystems Look for clustered account creation, synchronized commits, repeated fork patterns, and contributor sets that appear engineered rather than organic.
• Monitor endpoint egress from MCP-enabled environments Alert on unusual outbound connections, especially from developer machines that should not reach cryptocurrency RPC endpoints, known malware infrastructure, or unexpected C2 destinations.
• Separate package trust from execution trust Allowing a server into a registry should not imply permission to operate freely at runtime. Add behavioural monitoring around file access, network activity, and secret access once the MCP server is executed.

Key takeaways

• MCP supply chain attacks show that repository popularity is not a reliable trust control when malicious actors can fabricate provenance.
• The campaign’s value to attackers comes from developer credentials, session tokens, and API keys, which can unlock far more than the original integration.
• Security teams should move MCP governance from one-time approval toward provenance verification, endpoint monitoring, and blast-radius reduction.

Key terms

• MCP Supply Chain Poisoning: A supply chain attack that abuses trust in Model Context Protocol distribution channels, registries, or repositories. The attacker replaces or clones a legitimate server with a malicious one, then uses false provenance signals to get it installed into developer or agent environments.
• Manufactured Provenance: Artificial trust evidence created to make software appear legitimate, such as fake contributors, coordinated forks, or freshly created accounts with synchronized activity. In MCP ecosystems, manufactured provenance can override human judgment unless teams verify authorship and lineage independently.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full report

Straiker's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact fake account and fork pattern used to manufacture trust in the MCP ecosystem.
• The obfuscation and persistence techniques observed in the payload, including scheduled tasks and runtime unpacking.
• The registry poisoning path that let the trojanized server appear alongside legitimate community contributions.
• The detection and response indicators Straiker used to identify the malicious repository network.

👉 Straiker’s full post covers the cloned Oura Ring server, fake GitHub ecosystem, and payload analysis in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.