MCP and the Supply-Chain Problem

Connectors & safety scan

Connectors are essentially an agreed contract: a manifest that lists available tools, endpoints, and authentication methods. In practice, that means the model can call those tools and act on their results. For example, searching your database or sending an email on your behalf. When users add a connector in Developer Mode in Chat GPT, they expose that contract to the model and the model can start calling remote endpoints.

Figure 1: Adding a new connector in ChatGPT developer mode (source: OpenAI)

Before the user can use a newly added MCP server, there’s an automated “safety scan.” This scan performs several checks:

In short, safety checks are mainly static. They validate shape and flags but not intent. That matters! Because an attacker doesn’t always need to sneak executable code past the scanner, they only need to change the contract, also known as the manifest, or the behavior of one of the endpoints in a way that enables exfiltration, side effects, or persistence. Those are classic supply-chain objectives and they’re exactly the patterns we’ve seen in open source package-manager attacks.

One high-profile example is Shai-Hulud in the Node Packet Manager (npm), which demonstrates how attackers can weaponize dependencies and developer automation, a pattern that translates to connectors and MCP servers.

Supply chain attacks & Shai-Hulud

Shai-Hulud, a name borrowed from Dune, is a useful case study because it illustrates the classic supply chain goal: control a trusted artifact or automation so attackers can operate inside developer workflows. In this campaign, attackers placed heavily obfuscated payloads inside packages and then relied on developer automation (CI/CD pipelines, package installs and automated workflows) to execute the payloads or expose secrets from build and runtime environments. The malicious code was intentionally made hard to read to evade casual reviews and once executed, it focused on harvesting credentials, establishing persistence (so the attacker could return later) and using the compromised automation to push further updates to other packages, effectively turning a single compromised package into a propagation mechanism across multiple projects and environments. The technical details differ across incidents, but the structural lesson is consistent: compromise the thing everyone trusts (a package, a release process, or automation) and gain pathways into countless downstream systems.

Related techniques: typosquatting and name-confusion

A complementary class of attacks targets human error rather than breaching the maintainer of a popular package. In software and AI communities alike, attackers publish packages with names that look almost identical to popular libraries. For example, swapping a lowercase l (L) for an uppercase I (i) or introducing a subtle typo. Developers who mistype a package name in a dependency file or in a package install command can accidentally pull the malicious package instead of the intended one while developers using graphical package managers can easily click the wrong package name. Malicious packages can contain any sort of unwanted behavior and are effective because they exploit the dependency pipelines: fast installs, blind trust in package names and limited review of transient dependencies.

Why is the pattern transferable to MCP/connectors

Packages and manifests are different technical objects, but attackers pursue the same structural advantage: becoming the entity that downstream systems implicitly trust. In practice, that maps to several concrete MCP risks. An attacker could:

1. slip obfuscated payloads into a connector host or into the data the connector returns so that developer automation or runtime handlers leak secrets.
2. hijack a publishing account and alter a manifest to expose new tools or broaden scopes.
3. publish a connector with a misleading name (the MCP equivalent of software supply chain typosquatting) so that users or scripts install the wrong artifact.

Recently, a supply chain attack targeting an npm package used by the MCP service Postmark-mcp was discovered by Koi Security. A malicious npm package named postmark-mcp impersonated the legit Postmark library with the same name by copying the official Postmark Labs library code with just one added line that acted as the malicious backdoor. The added line was an additional BCC field to the email function of the Postmark-mcp library, a simple and effective line that resulted in a silent copy to the attacker’s email address for every email sent through the Postmark MCP server compiled with the malicious Postmark-mcp package.

Figure 2: Mapping known software supply chain techniques to the MCP/AI supply chain

Once an attacker controls a manifest or a connector host (or a downstream dependency of the connection host, like was the case in the Postmark-npm breach), they can leverage AI model-driven automation and existing workflows such as webhooks, CI actions, or send Email capabilities to exfiltrate information. The root cause is trust in external artifacts plus limited dynamic vetting: static safety checks can only catch structure and obvious flags, but they often miss stealthier runtime behaviors and chained dependencies that make campaigns like Postmark-mcp effective.