I’ve seen this movie before.
around 2012, I was starting my career and npm was a young ecosystem, growing fast, full of promise. launched in january 2010 by Isaac Schlueter to solve Node.js’s dependency chaos, it quickly became the de facto standard for server-side JavaScript — and in the following years it would also become the backbone of client-side JavaScript, with React, Webpack, Babel. any dev could publish a package. you’d run npm install and your problem was solved in 30 seconds. insane productivity. and everyone was celebrating.
then came the bugs. then the vulnerabilities. then the abandoned packages that half the internet depended on. then left-pad breaking everyone’s deploy because one guy got pissed off and deleted 11 lines of code, back in 2016. then event-stream getting hijacked in 2018 — a tired maintainer handed the project off to a volunteer who, a few weeks later, added a malicious dependency (flatmap-stream) with an encrypted payload to steal bitcoin wallets from Copay. the code ran silently for about 2 and a half months before being discovered.
we learned — the hard way — that “fast-growing ecosystem + low barrier to entry + implicit trust” is a combination that always, always goes wrong.
guess what’s happening with MCP right now?
the numbers nobody’s really paying attention to
in march 2026, the MCP ecosystem has over 10 thousand public servers and 97 million SDK downloads per month (Effloow). every big company shipping a server — Stripe, Google Analytics, Klaviyo, PagerDuty, Amazon, Microsoft. explosive adoption in 18 months.
that’s beautiful. and that’s exactly the problem.
MCP’s breakthrough was eliminating the N×M integration problem. before, to connect 5 models with 10 tools, you needed 50 custom integrations. with MCP, each tool publishes a server, each client implements the protocol once, and done — the matrix collapses from M×N to M+N. it’s genius.
except the barrier to entry is so low that anyone can publish a server. a dev alone, in an afternoon, can spin up an MCP server on Vercel and list it in the registry. no review. no audit. nothing.
sound familiar?
what’s already gone wrong (and you didn’t read about in the feed)
september 2025, three months before the AAIF was created inside the Linux Foundation to give MCP some governance: the postmark-mcp package on npm. posing as a legitimate Postmark integration — which had never published an official MCP server on npm, only on GitHub — the maintainer (user phanpak) published 15 clean versions (1.0.0 through 1.0.15) to build trust. the code was a copy of the official repository, working perfectly. weekly downloads hitting 1,500. around 300 teams integrated it into their real workflows.
then came version 1.0.16.
one line. one single line added to the code.
BCC on every email going out to phan@giftshop.club.
300 organizations. corporate emails. potentially credentials in password resets. leaking silently for weeks until the Koi Security folks caught it (The Vulnerable MCP Project).
january 2026, BlueRock Security analyzed 7,000 MCP servers: 36.7% were vulnerable to SSRF — the kind of vulnerability where an attacker makes the server request internal resources that shouldn’t be exposed. their proof of concept on a Microsoft MCP server managed to extract AWS IAM keys directly from an EC2 instance’s metadata endpoint. a misconfigured server becoming the front door to an entire cloud.
february 2026, Check Point Research disclosed CVE-2025-59536: a critical vulnerability in Claude Code itself (yes, the client, not some random server). any malicious .claude/settings.json in a cloned repository could achieve remote code execution before the confirmation dialog even appeared on screen. you opened the project. the code ran. done.
Trend Micro found 492 MCP servers on the public internet with zero authentication and zero encryption. not even HTTPS, friend.
and Qualys coined the term: “MCP Shadow IT”. marketing or data team spins up an MCP server to connect a new tool to the agent, without approval, without visibility, without audit. just like the SaaS Shadow IT that dominated the 2010s, except now with direct access to sensitive data via LLM.
the npm mirror (and what it predicts)
take the npm timeline and overlay it:
npm 2010-2013: new ecosystem, viral growth in the Node.js world, low barrier to entry, “install and trust” culture. the registry went from hundreds to tens of thousands of packages in that window. MCP 2024-2026: same thing. 18 months from zero to 10 thousand public servers.
npm 2016-2018: first serious incidents at scale. left-pad (march 2016) exposed cascading-dependency risk. event-stream (november 2018) exposed ownership-transfer risk. community figured out that “trust by default” doesn’t scale. MCP 2025-2026: already happening. postmark-mcp, Claude Code CVE, 36.7% SSRF-vulnerable — and we haven’t even hit the equivalent of event-stream yet.
npm 2017-2020: gateways, auditing, npm audit (2018), lockfiles (2017), signed packages, Snyk becoming a market category.
MCP 2026-?: getting started. MCP gateways showing up (MCP Manager, MCP-Hive), OAuth 2.1 in the spec as of april 2026, static scanners (Cisco mcp-scanner, Snyk agent-scan), SBOMs for MCP servers. but none of this is default yet.
npm today: mature ecosystem, automated tooling, a culture of justified paranoia — and attacks still happen, just detected in hours instead of months. MCP in 2028-2030: it’ll probably get there. but the next two years are going to hurt.
history doesn’t repeat, but it rhymes with impressive persistence.
what you can do today
if you use MCP in a serious project — not exploration, serious — it’s worth adopting a few habits we learned from npm but that still aren’t reflex in the MCP world:
pin the version. don’t use latest for MCP servers. pin the version in your settings.json for Claude Code, Cursor, any client. and review before updating — the postmark-mcp case was literally “new version, new code, new backdoor”. 15 clean versions don’t protect you from the 16th.
treat MCP server as dependency, not plugin. that means entering the list of dependencies your team audits. means code review before adding it to the project. means SBOM, if your team already does that. if you wouldn’t npm install a random package from an unknown maintainer, don’t add an MCP server from a random repo.
least privilege. a file-reading MCP server doesn’t need write access. a database-query server doesn’t need DDL. most servers today ask for broad permissions because it’s easier — and most devs accept because it’s also easier. don’t do it.
use a gateway if you have more than 3 servers. a gateway gives you observability, rate limiting, auditing, permission scoping. with 1 or 2 servers, it’s overhead. with 5+, it’s sanity. the enterprise folks have already started — MCP Manager, MCP-Hive, some big teams built internal gateways. if you’re a solo dev, you’re fine for now. if you’re on a team, you should already have one.
separate official MCP from community MCP. official servers (GitHub MCP, Stripe MCP, Google Drive MCP) go through internal review at the product’s owning company. community ones go through nobody. not that official means invulnerable — the Claude Code CVE shows that official code also breaks — it’s that the risk surface is different. treat them as different categories in your mental registry.
the part I find most interesting
MCP is the most promising thing that’s happened in AI integration in years. I use it. I recommend it. I teach it. and I’ll keep doing so.
the problem isn’t the protocol. the problem is the culture.
npm is also genius. npm’s problem was never npm — it was us treating install as “press a button” instead of “clone code from someone I don’t know to run on my machine with access to my filesystem.”
with MCP the risk is bigger, not smaller. because now the code isn’t just on your machine — it’s connected to an agent with autonomy to execute actions, send emails, run database queries, hit APIs, touch repos. the potential damage per compromised integration is an order of magnitude above npm’s worst case.
we’re in a narrow window where we can learn the lesson before taking the punch at scale. npm took about 8 years (2010 to npm audit in 2018) to have native security — and even today the attacks happen. MCP needs to do it in 1 or 2.
and it’s not Anthropic, Google, or OpenAI that will fix this. they’re doing their part (open spec, governance in the Linux Foundation, OAuth in spec). what fixes it is the culture of the dev who uses it — your culture, your team’s.
either we treat MCP servers with the same respect we treat production dependencies, or we’re going to read the same 2016 headlines, just with “MCP” in place of “npm”.
and this time, with the agent doing the damage.