AI Security

Honeypot Catches MCP Scanner Running Alongside SSH and Docker Probes

A multi-service honeypot logged an IP scanning eight services in ten minutes, including an MCP initialize request.

Oliver Senti
Oliver SentiSenior AI Editor
March 14, 20265 min read
Share:
Terminal screen showing honeypot logs with multiple protocol scan entries highlighted against a dark background

On March 10, 2026, a Russian security researcher's multi-service honeypot captured something new. A single IP address cycled through eight different services in ten minutes: SSH, Telnet, HTTP/HTTPS, MySQL, Docker API, Memcached, and Winbox. Tucked in among the usual banner-grabbing was a JSON-RPC initialize request for the Model Context Protocol. The finding, published on Habr, represents what the researcher calls the first documented case of MCP scanning operating as a module inside a multi-protocol scanner rather than a standalone research tool.

What actually showed up

The scanner wasn't subtle. It hit every service the honeypot exposed, collecting banners and testing for default configurations. The Docker API probe attempted to create a container to extract /etc/shadow, a well-known privilege escalation technique that's been in automated scanners for years. The MCP component sent a standard JSON-RPC 2.0 initialize request, the handshake that kicks off any MCP session. Nothing sophisticated about any individual probe. What's interesting is that MCP made the list at all.

MCP uses JSON-RPC 2.0 for client-server communication, and every connection starts with this initialization handshake. Including it in a multi-service sweep means someone has decided that exposed MCP endpoints are worth cataloguing alongside databases, shell access, and container runtimes.

The timeline matters

Back in November 2025, GreyNoise deployed MCP honeypots across three configurations: unauthenticated, authenticated, and a deliberately exposed developer instance with a leaked API key. Every honeypot was discovered within days, but GreyNoise found zero MCP-specific payloads or exploitation attempts. The traffic was indistinguishable from background internet noise. Their conclusion at the time was measured: MCP endpoints are being noticed, but not pursued.

Then things accelerated. In January 2026, GreyNoise's Ollama honeypot infrastructure recorded 91,403 attack sessions over four months, with 80,469 sessions crammed into an 11-day window starting December 28. Two IP addresses generated all of that traffic, systematically probing over 73 LLM model endpoints. But that campaign targeted Ollama and LLM APIs specifically, not MCP.

In February, a researcher named Kai published results from a honeypot MCP server registered on the official MCP registry. Within 48 hours of going public, something called the honeypot's fake get_aws_credentials tool with role="admin". One hit, never came back. Kai couldn't determine whether it was an automated scanner, a red team, or an AI agent configured to probe for credentials.

And now, four months after GreyNoise saw nothing, MCP reconnaissance shows up bundled into a general-purpose internet scanner.

Why this is different from the Ollama campaigns

The GreyNoise Ollama finding and this Habr report describe different phenomena. The Ollama campaign was targeted: two IPs methodically testing specific LLM model endpoints, sending test queries like "hi" and "How many states are there in the United States?" to fingerprint which models would respond. Bob Rudis, GreyNoise's VP of data science, assessed those IPs as belonging to a professional threat actor building target lists. The two addresses had a combined history of over 4 million GreyNoise sensor hits and had been involved in exploiting more than 200 CVEs.

The Habr finding is more mundane, in a way. It's not a targeted LLM campaign. It's someone adding MCP to the same scan toolkit that already checks for open MySQL ports and misconfigured Docker daemons. That's actually the more telling signal. When a protocol gets folded into commodity scanning infrastructure, it means the attackers (or the tool vendors selling to them) have decided the attack surface is large enough to justify the effort.

The exposure numbers

Knostic researchers used Shodan to hunt for exposed MCP servers and found 1,862 on the public internet. They manually verified 119 of them. All 119 allowed access to internal tool listings without authentication. Separately, a February 2026 report on Reddit documented over 8,000 MCP servers visible on the public internet, with admin panels and debug endpoints exposed without access controls.

And then there's the broader AI infrastructure picture. SentinelOne and Censys identified roughly 175,000 internet-reachable hosts associated with self-hosted LLM infrastructure over a 293-day observation period. Pillar Security's Operation Bizarre Bazaar investigation documented 35,000 attack sessions between December 2025 and January 2026 targeting exposed AI endpoints, with attackers monetizing access through a resale platform called silver.inc.

So is MCP actually under attack?

Not really. Not yet. GreyNoise's own assessment from their MCP honeypot deployment still holds: no MCP-specific exploitation attempts have been documented in the wild. The Habr finding is reconnaissance, not exploitation. The researcher's scanner sent an initialize request, not a tools/call. It wanted to know if MCP was there, not to abuse it.

But reconnaissance precedes exploitation. The GreyNoise Ollama data makes that pattern explicit: 80,000 enumeration requests across 11 days is an investment, and threat actors don't build target lists for fun.

The real question is what happens when someone combines MCP discovery with MCP exploitation. An exposed, unauthenticated MCP server can enumerate all available tools, call them with adversarial inputs, and potentially exfiltrate data through tool outputs. If that MCP server has access to file systems, databases, or shell execution (and many do), a single exposed endpoint becomes a bridge into internal infrastructure. Pillar Security's research described MCP servers as providing access to "file systems for reading source code and placing backdoors, databases for dumping credentials and exfiltrating customer data, and shell access for executing commands on host systems."

The Habr article includes IOCs, a Suricata signature for detecting MCP scanning, and Shodan/Censys search queries for finding exposed MCP endpoints. If you're running MCP in production, that's probably worth your time. The researcher's closing line is blunt: if your MCP server faces the internet, it's probably already been scanned.

Tags:MCPhoneypotAI securityModel Context Protocolnetwork scanningthreat intelligenceDocker securityLLM infrastructureGreyNoisecybersecurity
Oliver Senti

Oliver Senti

Senior AI Editor

Former software engineer turned tech writer, Oliver has spent the last five years tracking the AI landscape. He brings a practitioner's eye to the hype cycles and genuine innovations defining the field, helping readers separate signal from noise.

Related Articles

Stay Ahead of the AI Curve

Get the latest AI news, reviews, and deals delivered straight to your inbox. Join 100,000+ AI enthusiasts.

By subscribing, you agree to our Privacy Policy. Unsubscribe anytime.

Honeypot Catches MCP Server Scanner in Multi-Protocol Sweep | aiHola