Otto-Support: Supply Chain Risks in MCP Servers

TL;DR: otto-support's selfpwn module quantifies exactly what a hostile MCP server can read from a developer's machine the moment it runs, making the supply chain risk concrete in a way an abstract threat model cannot. This entry pairs that demonstration with the postmark-mcp and ClawHub compromises, then lays out the registry, pinning, and egress controls that make the next one survivable.

Until now, our blog series has treated the MCP server as honest infrastructure: built to spec, deployed in good faith, and attacked through misuse or external pressure.

Now, we take a different look exploring supply chain risk in MCP servers, the cases where that assumption breaks down, and the MCP server itself becomes the attacker.

What is Supply Chain Risk for MCP servers?

MCP tools are often distributed as community packages. A malicious update can preserve the identical tool name, schema, and behavior while silently exfiltrating data that the tool touches.

The supply chain risk in MCP servers is structural. The protocol defines how tools are discovered and called, but it has no mechanism for verifying that the tool implementation matches what was reviewed at install time. A server that passes every functional test can still be exfiltrating data in the background. The trust model relies entirely on the developer reviewing source code before installation and trusting that the code does not change on update.

Case Studies

Malicious postmark-mcp Server Harvests Emails (September 2025)

On September 29, 2025, researchers identified what appears to be the first documented case of a malicious MCP server used for data harvesting in the wild. The package was called postmark-mcp, an MCP server for sending emails through the Postmark API.

The package worked perfectly for 15 versions before 1.0.16, in which the developer introduced a small change causing every outgoing email sent through the server to include a hidden BCC to an attacker-controlled email address. The modification was minimal and the tool continued to function normally. Users who pinned to an earlier version were unaffected. Users who accepted the update, which is the default behavior in most package managers, silently opted in to the exfiltration. The attacker was the developer of the software.

ClawHub Marketplace: Malicious Skills on a Trusted Platform

Researchers found malicious skills on ClawHub that functioned as advertised while running secondary operations in the background. Some exfiltrated cryptocurrency wallet keys while others harvested stored credentials and forwarded them to attacker-controlled infrastructure. The skills returned normal results to the user, making the malicious behavior difficult to detect during normal use. The marketplace did not scan submissions for malicious instructions and had no mechanism for users to verify if skills had been modified since their last review.

Measuring the Consequences

In our otto-support capture the flag (CTF), the supply chain scenario is demonstrated through a built-in command that gathers data from your system in a similar manner to many supply chain compromises. The disclaimer below is taken from the code here when otto-support selfpwn is run.

$ otto-support selfpwn 
otto-support selfpwn — Credential Exposure Scanner 
 
This module scans your filesystem for credentials, keys, tokens, and secrets that any MCP server running as your user would have access to. It checks for SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes configs, Docker registry auth, database passwords, cryptocurrency wallets, CI/CD tokens, environment files, and shell history. 
 
Results are printed to the terminal and not written to disk or sent anywhere. 
 
If you are running this inside the otto-support CTF container, the credentials it finds are fabricated demo data planted for the exercise. They are not real. 
 
If you are running this on your host machine, the credentials it finds are real. Review the output carefully. Any file listed in the report is readable by every MCP server you have installed. This is the same data commonly collected during supply chain compromises: SSH keys for lateral movement, cloud credentials for infrastructure access, API tokens for service impersonation, and wallet keys for direct financial theft. If you suspect a malicious or compromised MCP server has run on your system, treat every credential in the report as potentially exfiltrated and begin revocation. 
 
To proceed, run: 
 
    otto-support selfpwn --agree

Figure 1 - selfpwn disclaimer prior to running

The otto-support binary is included in the CTF container, and we can invoke it through Claude Code by prepending a "!" to the command like so:

! otto-support </b>selfpwn --agree 
 
Scanning for credentials accessible to MCP servers...  
 
# MCP Server Credential Exposure Report  
Generated: 2026-04-08T12:33:31Z  
Host: linux/arm64  
User:  
Home: /home/otto 
 
Any MCP server running via stdio inherits your user context and can read all of these files silently.  
 
---  
 
## SSH Keys & Config 
 
| File | Size | Permissions | Risk |  
|------|------|-------------|------|  
| `/home/otto/.ssh/id_ed25519` | 237B | `-rw-------` | CRITICAL — private key | 
| `/home/otto/.ssh/config` | 95B | `-rw-r--r--` | HIGH — configuration with credentials |  
 
## AWS Credentials  
 
| File | Size | Permissions | Risk |  
|------|------|-------------|------|  
| `/home/otto/.aws/credentials` | 272B | `-rw-------` | CRITICAL — credential/token |  
| `/home/otto/.aws/config` | 132B | `-rw-r--r--` | HIGH — configuration with credentials | 
…omitted for brevity… 

Figure 2 - Running selfpwn with the agree flag

It is critical to note that this data is only collected from the system, printed to the screen, and discarded in the context of a function that returns an error. This tool does not send data anywhere except the terminal in which the command is run, so that one can understand and quantify the risk of running MCP servers locally on their system without a sandbox.

Mitigations for Supply Chain Compromises

Organizations deploying MCP servers at scale should maintain internal plugin registries with verified commits and signed plugins. Community marketplace packages should be treated as untrusted by default, reviewed before adoption, pinned internally, and re-reviewed before updating the pinned versions. The postmark-mcp incident demonstrates that a package with a clean history is not the same as a package that will always be clean. Pinning versions, verifying checksums on MCP server dependencies, vendoring dependencies locally with go mod vendor or equivalent, and using lockfiles, go.sum, or subresource integrity hashes so that updates cannot be applied without additional controls can all help control the version of a MCP server in use.

Network egress controls on MCP server processes can provide preventative and detective security layers, but data exfiltration can be a difficult signal to detect if MCP servers are allowed to run from any computer and network location. Ideally, MCP servers should be restricted to running in dedicated environments with centralized monitoring and allowlist-only network egress controls. If an MCP server is meant to query an internal database and return results, it should not be making unapproved outbound HTTP requests to unfamiliar endpoints. Runtime monitoring for unexpected network connections during tool execution can catch the exfiltration that code review missed. Users that run MCP servers outside of the authorized boundary can be both educated and have software-defined networking policies applied to their endpoints that enforce allowlist-only network egress controls for risky assets.

Mitigating supply chain compromises should continue with user education about established processes and technologies to support the secure usage of vendor- and community-developed MCP servers. Empower users with knowledge and opportunities to take actions that can help prevent or limit the impact of supply chain compromises by using only approved MCP servers. If users would like to use a specific MCP server that is not available, provide a mechanism for them to request a review for the server to be adopted into the internal marketplace. Otherwise, users may find other ways to run the MCP server, perhaps by using a containerization solution, a virtual machine, or other difficult-to-detect methods.

Conclusion

Supply chain attacks work because they turn an organization's own diligence against it. The package gets reviewed, the version gets pinned, the integration tests pass, and none of those controls were designed for the case where the developer of the package is the attacker. The postmark-mcp incident showed how small the malicious change can be and how invisible it stays once shipped. The credentials surfaced by selfpwn show how much is already on the table the moment a hostile MCP server runs locally without isolation and containerization.

In the next post, we shift from compromise prevention to compromise detection. Even with sound mitigations in place, every attack class in this series produces traffic that looks legitimate on the wire without deep packet inspection, and without intentional logging, the difference between a routine tool call and an active breach can be impossible to see.