pnpm Proxy Flaw Leaks Secrets Across 10 MCP Servers

One vulnerability. Eleven servers. Zero code changes required to trigger it — just pnpm install on a repo you didn't write.

That's the story behind GHSA-vx52-2968-3vc6, a high-severity pnpm advisory published September 1, 2026 that's now flagged against eleven MCP servers in our catalog. It's not a bug in any of these servers' logic. It's a supply-chain trap baked into the package manager itself — and every project using pnpm inherited it the moment they added a workspace file.

What's actually broken

pnpm expands ${VAR} environment placeholders inside the httpProxy, httpsProxy, and noProxy settings read from a project's pnpm-workspace.yaml. That file is repository-controlled — meaning anyone who can get you to clone their repo and run pnpm install in it can also control those proxy settings.

Here's the trap: an attacker crafts a pnpm-workspace.yaml with a proxy hostname or userinfo field that embeds an environment variable reference — say, ${NPM_TOKEN} or ${GITHUB_TOKEN}. When pnpm expands that placeholder during install, it routes your traffic through the attacker's proxy, with your secret baked into the URL it just leaked to.

This bypasses a trust boundary developers rely on without thinking about it: workspace config files are assumed to be inert. They're not, if pnpm will happily interpolate live secrets into network settings on your behalf.

Who's affected

The following MCPpedia-listed servers currently carry this advisory:

• Resend Mcp
• io.github.vdappdev2/address
• io.github.igor-holt/sear
• io.synthnet/mcp
• com.worldku/memory
• io.github.sjh9714/mergewarden
• Hotclip
• Stashbase
• io.github.coastmancoastman/diem-agent-workers
• xyz.getava/ava

That's a mix of infra, memory, and workflow servers — nothing unifies them except a shared build tool. This is exactly the kind of exposure that doesn't care what your server does; it cares what installs it.

---

What to do about it

1. Update pnpm. Check the advisory for the patched version range and upgrade before your next install on any untrusted or third-party repo.
2. Never pnpm install on repos you haven't reviewed with install-time secrets sitting in your environment — treat that combination as inherently risky until pnpm ships a fix.
3. Rotate any tokens that were present in the environment during installs of the affected servers, if you can't confirm the timeline.
4. Scope your CI secrets. If your pipeline runs pnpm install against external code, minimize what tokens are available in that job's environment.

Ten servers, one root cause, and a reminder that the scariest vulnerabilities aren't in the code you audited — they're in the tool you didn't think to.