DEV Community

Kiell Tampubolon
Kiell Tampubolon

Posted on

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 "\$"
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)