Know the attacks
Malicious MCP servers: how to vet one before you install it
Installing an MCP server means running someone else's code with your keys. It sees everything your agent sends through it.
New to MCP? What is an MCP server? covers the basics first.
A malicious MCP server does something you didn't ask for with the access you gave it, like copying data out or running commands. You install it from npm, PyPI or a container registry like any package, hand it an API key, and from then on it sees every request your agent sends through it. The difference from a normal dependency is that an agent calls it on its own, usually with nobody reading each call.
The postmark-mcp case
The first widely reported case was an npm package called postmark-mcp, which let an assistant send email through Postmark. It shared its name with Postmark's own MCP server on GitHub, and Postmark later said it "didn't develop, authorize, or have any involvement with" the package.
According to Snyk's timeline, version 1.0.0 went up on September 15, 2025, followed by normal-looking releases. Version 1.0.16 added a blind copy to an outside address on every email the server sent. Koi Security, who found it, said the change was a single line. By September 25 the package was gone from npm.
The early versions worked as described, so anyone who checked it before 1.0.16 found nothing wrong. Pulling it from npm didn't help people who already had it either, since installed copies kept running. Snyk's advice was to assume exposure: uninstall, rotate any credentials that passed through it, and review your email logs.
No model was attacked. The server did its job, plus one extra thing the agent had no way to notice.
How a bad server gets installed
The MCP security best practices describe the local version directly: a server you run on your machine can carry a malicious payload, or a config can include a harmful startup command, giving "arbitrary code execution" with the client's privileges and "no visibility" into what ran.
The ways in are mundane. A package impersonates a vendor's name. A server you checked months ago ships a bad update and an unpinned install picks it up. A maintainer hands a project over, or loses their account. A README tells you to paste a config block whose startup command does more than start the server.
A server can also do harm through its tool descriptions alone, covered in MCP tool poisoning and MCP rug pulls.
A checklist for vetting a server
These are the checks you'd run on any dependency that holds a credential.
- Confirm the publisher. Start from the vendor's own docs or GitHub org, not a search result, and check that the package on the registry is published by the same people. A matching name proves nothing.
- Find the source and compare it. Make sure the registry package links to a real repo, and that what you install was built from that repo. Look at what the server does with the credential you give it and where it makes network calls.
- Pin the version. Install an exact version, or pin a container image by digest, so an update can't change what you reviewed. Upgrade on purpose, and look at the diff when you do.
- Give it the smallest credential that works. A read-only key, a single project, a sandbox account. If the server turns out to be bad, this decides what it had.
- Expose only the tools you need. Many servers bundle read and write tools together. If the agent only needs to read, don't let it call the rest. See excessive agency.
- Limit where it can send data. A server that can only reach the API it wraps can't BCC a stranger or post your data elsewhere. Network egress rules do more here than anything you read in the code.
- Log every call. If something goes wrong, you need to know which agent called which tool, when, and with what result.
- Know how to pull it. Keep a list of which servers run where, so "uninstall it and rotate the key" takes minutes and not a week of searching laptops.
The MCP security checklist turns this into a score with fixes.
What vetting can't catch
Reading the code won't catch a release that turns bad after you looked, or one that behaves until some condition is met. That's why steps 3 to 8 matter more than step 2. They limit what any server can do, including one that passed review.
Where Statio fits
For servers Statio hosts, the security page describes the scanning: Grype and npm audit for known vulnerabilities, and Semgrep rules looking for things like environment exfiltration and unexpected outbound calls, with high or critical findings blocking the deploy. Hosted servers aren't reachable from the internet and send outbound traffic through a proxy that checks each destination against that server's allowlist, with nothing allowed until you add it.
For any server behind the gateway, per-tool permissions let you deny individual tools, each agent has its own identity, and every call is in the audit log. None of that replaces checking who published a server. Scanning finds known patterns, so treat it as one layer. The catalog lists the servers Statio supports.