Skip to content

200,000 exposed MCP servers later, the boring checks still win

Published Last updated 3 min read

Key takeaways

  • OX Security's April disclosure put vulnerable MCP instances at roughly 200,000, and a stats report counted over thirty MCP related CVEs in a single 60 day window.
  • The exposed instances are mostly human mistakes: admin interfaces bound to every interface, no authentication, plaintext secrets in configs and servers months behind on patches.
  • Run ss -tlnp | grep node and treat anything on 0.0.0.0 that is not meant to be public as a bug, since local tool servers should bind to localhost.
  • Test whether the endpoint answers useful data without an auth header using curl, because that ten second check is the most common finding in exposure scans.
  • Pin the server version, watch the release feed, and send tool call logs somewhere with an alert rule and a human who looks at them.

The numbers from this spring keep sitting in my head. OX Security’s April disclosure put vulnerable MCP instances at roughly two hundred thousand, across a supply chain footprint of more than 150 million package downloads. A stats report tallied over thirty MCP related CVEs in a single 60 day window. Gartner started connecting the coming GenAI breach wave to exactly this exposure.

Read the CSA research note and you will see the phrase systemic design flaw, and yes, the protocol era genuinely has architectural problems that spec releases will need years to settle.

But census the actual exposed instances and the list is embarrassingly human: admin interfaces bound to every interface, no authentication, secrets sitting in plaintext configs, servers months behind on patches. The design flaw makes headlines. The config mistake pays the attackers.

The five checks I run on every MCP server

1. What are you listening on

ss -tlnp | grep node

Anything on 0.0.0.0 that is not meant to be public is a bug. Local tool servers should bind to localhost. If your MCP server has a web UI and it answers on all interfaces, that is the incident, everything else is commentary.

2. Does it answer without credentials

curl -s http://localhost:PORT/ | head

If the endpoint returns useful data with no auth header, stop and fix. This takes ten seconds and it is the single most common finding in exposure scans.

3. What secrets are in the config

grep -rE "(api_key|token|secret)" . --include="*.json" | grep -v "\$"

Plaintext keys in config files are how one cloned repo becomes a leaked org. The regex above is a start; a scanner catches the formats grep misses, like JSON quoted keys that defeat the naive pattern. I learned that one the hard way testing my own scanner against JSON configs.

4. Is the version pinned

A floating server tag means someone else decides when your tooling changes. Pin it. Then watch the release feed so a pin does not become a museum piece.

5. Do the logs go somewhere a person looks

Logs rotated into a volume nobody reads are a retention liability with delusions of being a control. Tool call logs should land somewhere with an alert rule attached. You do not need a SIEM. You need one query and one human.

The uncomfortable summary

Two hundred thousand exposed instances were not collected by novel research exploits. They were collected by pointing basic network scans at the basics. Your defense gets the same treatment: basic checks, run consistently, before someone else runs them for you.

I keep a free 12 point preflight checklist for MCP setups that extends this list. Link below.

Sources

If you want to run checks like these on an MCP server or a .claude/ directory before you install it, I maintain mcpscan, an open-source scanner for tool poisoning, risky permissions and leaked secrets. Issues and false-positive reports are welcome.

Originally published on DEV. Discussion happens there.

Frequently asked questions

How do I check if my MCP server is exposed to the internet?
Run ss -tlnp | grep node and look for anything listening on 0.0.0.0 that should not be public. Then curl the endpoint without credentials, and if it returns useful data you need to fix authentication.
Why are so many MCP servers vulnerable?
According to the article, the exposed instances are mostly basic mistakes like admin interfaces bound to all interfaces, no authentication, plaintext secrets and unpatched servers. Architectural flaws in the protocol exist, but the config mistakes are what attackers collect.
Should I pin my MCP server version?
Yes. A floating server tag means someone else decides when your tooling changes, so pin it and watch the release feed so the pin does not go stale.
Share Share on X Share on LinkedIn

About the author

Security Engineer & Technical Writer

Security engineer and technical writer based in Batam, Indonesia. I review and harden MCP servers and AI agents, build security automation, and write up what holds and what fails. I also train on DNS security as a PANDI .id Academy trainer.

Related articles

All writing | RSS | Markdown