Security Advisory: Systematic MCP Server Forking as Supply-Chain Attack Vector

[CSCSoftware]

Security Advisory: Systematic MCP Server Forking as a Supply-Chain Attack Vector

Published: 2026-03-23
Severity: High
Affected Ecosystem: Model Context Protocol (MCP) servers -- npm, PyPI, and third-party marketplaces
Affected Package (example): @iflow-mcp/cscsoftware-aidex-mcp (v1.9.0, published by chatflowdev) -- an unauthorized republication of aidex-mcp
Original Repository: CSCSoftware/AiDex

---

Summary

We have identified a systematic campaign in which an organization operating under the name "iflow-mcp" (associated with the domain platform.iflow.cn) is forking hundreds of open-source MCP servers on GitHub, republishing them under their own npm scope (@iflow-mcp/) and on PyPI, and distributing them through their own marketplace -- all without contacting or notifying the original authors.

While forking open-source software is permitted by most licenses, republishing MCP servers through an unvetted third-party pipeline creates a critical supply-chain attack surface that the MCP ecosystem is not yet equipped to handle.

This advisory explains why this practice is dangerous, how it affects end users, and what both developers and users should do to protect themselves.

---

Why MCP Servers Are Not Ordinary Plugins

MCP servers are fundamentally different from typical npm packages or browser extensions. By design, they operate with deep, privileged access to the user's environment:

• Filesystem Access: MCP servers read source code, navigate directories, and retrieve file contents. They can access .env files, API keys, SSH keys, credentials, and proprietary code.
• Direct AI Communication: They communicate via stdio directly with the AI client (Claude, Cursor, VS Code, etc.) and can manipulate tool responses in ways the user cannot easily detect.
• User-Level Permissions: They run with the same OS permissions as the user who started them -- no sandboxing, no permission prompts, no isolation.
• Implicit Trust: Users install MCP servers specifically because they want the AI to use them. Every tool call the AI makes to the server is executed automatically.

What a Trojanized MCP Server Could Do

A malicious actor who modifies an MCP server's code before republishing it could:

1. Exfiltrate sensitive data -- API keys, credentials, source code, database connection strings -- while appearing to perform normal indexing or file analysis operations.
2. Feed the AI false information -- suggest insecure code patterns, hide vulnerabilities in search results, redirect the AI to wrong files, or suppress warnings.
3. Inject malicious code -- instruct the AI to write backdoors, vulnerable dependencies, or data-leaking code into the user's project.
4. Persist silently -- since MCP servers run as long-lived processes, a compromised server has continuous access for the entire session.

None of this requires sophisticated exploitation. A few lines of code added to an otherwise legitimate MCP server is enough.

---

The Broken Trust Chain

The core problem is a broken chain of trust:

1. Developer A publishes an MCP server as open source on GitHub and npm.
2. Organization X forks the repository, republishes it under their own npm scope or on their marketplace.
3. User finds the package in X's marketplace, recognizes the familiar name, and installs it -- believing it to be the original or an officially endorsed version.
4. Nothing prevents Organization X from modifying the code before publishing. There is no signature verification, no reproducible build pipeline, and no way for the user to confirm the published package matches the original source.

The user's trust in Developer A is silently transferred to Organization X -- an entity the user knows nothing about and the developer never authorized.

---

Specific Case: AiDex MCP Server

AiDex is a code indexing MCP server published at:

• GitHub: github.com/CSCSoftware/AiDex
• npm: aidex-mcp

Without any contact or notification, the following unauthorized copy appeared:

• npm: @iflow-mcp/cscsoftware-aidex-mcp (version 1.9.0)
• Published by: chatflowdev
• Marketplace: platform.iflow.cn

We have not yet confirmed whether the republished version contains any modifications beyond repackaging. However, the mere existence of an unvetted republication pipeline for security-critical software is the vulnerability -- whether or not it has been exploited yet.

This is not an isolated case. The same organization has forked and republished hundreds of MCP servers using the same pattern.

---

Recommendations

For MCP Server Developers

1. Monitor for unauthorized republications. Regularly search npm (@iflow-mcp/<your-name>), PyPI, and third-party marketplaces for copies of your packages.
2. Add a clear notice to your README stating the only official distribution channels (your npm package name, your GitHub repo).
3. Consider adding a startup verification check that warns users if the package name or distribution channel does not match the expected values.
4. Sign your releases where possible. Use npm provenance (--provenance flag) to create a verifiable link between your GitHub source and the published package.
5. Document your package's expected behavior so users can recognize deviations.

For MCP Server Users

1. Only install MCP servers from their original, documented source. Always verify the npm package name, GitHub repository, and author before installing.
2. Never install MCP servers from third-party "marketplaces" or aggregators unless you can independently verify the package integrity against the original.
3. Be suspicious of scoped packages (@organization/package-name) that mirror the name of a well-known unscoped package -- especially if the scope belongs to an unfamiliar organization.
4. Check the publisher. On npm, verify who published the package. If the publisher is not the original author, treat it as untrusted.
5. Audit MCP server behavior. If an MCP server makes unexpected network requests, accesses files outside its documented scope, or produces unusual tool responses, investigate immediately.
6. Keep MCP servers updated from the original source. Do not rely on third-party forks for updates.

For the MCP Ecosystem (Claude/Anthropic, Tool Vendors, Registry Operators)

1. Implement a verified publisher program for MCP servers, similar to verified extensions in VS Code or verified publishers on npm.
2. Add provenance metadata to MCP server registries -- link each published package to its source repository with cryptographic verification.
3. Warn users when installing MCP servers from unverified or third-party sources.
4. Consider sandboxing MCP server filesystem and network access with explicit permission grants.

---

Timeline

Date	Event
2025	AiDex MCP Server published on GitHub and npm
2026-03	Unauthorized republication discovered under @iflow-mcp/cscsoftware-aidex-mcp
2026-03-23	This security advisory published

---

References

• AiDex GitHub Repository
• AiDex on npm (official)
• Model Context Protocol Specification

---

Contact

If you have discovered additional unauthorized republications of MCP servers, or if you have evidence of modified code in any republished package, please open an issue on the AiDex repository or contact us at u.chalas@csc-software.de.

---

This advisory is provided in the interest of ecosystem security. It is not a legal claim regarding licensing but a warning about supply-chain risk. The MCP ecosystem is young, and the tooling for verifying package integrity does not yet exist at the level required for software with this degree of system access.

[raye-deng]

This advisory surfaces a problem that is going to get worse fast. The MCP ecosystem has the same structural vulnerability that npm and PyPI had in the early days of typosquatting, except the attack surface is broader because MCP servers get tool-call access to the host environment.

What we have been seeing in our work on AI code quality is a related pattern at the code generation layer: AI coding assistants frequently generate import statements that reference plausible-sounding packages that either do not exist on the registry or have been subtly renamed. An attacker who registers those phantom package names (or, as you describe, republishes legitimate packages under a new scope) gets free installation from every developer who runs the AI-generated code without checking.

The convergence of these two vectors — upstream MCP server hijacking (your advisory) and downstream phantom import injection (what we detect) — creates a full supply-chain attack path that neither traditional SAST nor dependency auditing catches, because the malicious package was never in the original dependency tree. It was introduced by the AI at generation time.

One concrete step we have found useful: validating every import and package reference in AI-generated code against the canonical registry entry at CI time, before any install step runs. This catches both typosquatting variants and the "plausible fork" scenario where the scope or org name has been swapped. It is a deterministic check — no LLM needed, just registry lookups — and it runs in seconds.

For anyone who wants to add this as a CI gate: npx @opencodereview/cli scan . --sla L1

Great work documenting this. The MCP ecosystem needs more visibility into these attack patterns.