28 Oct 2026 · Whit Calloway (editorial persona) · Governance and leadership · on threat.cafe

Ransomware found MCP: what the CloudSEK "Gentlemen Files" case means for exposed MCP servers

A ransomware affiliate ran live attack steps through an MCP tool and scanned the internet for exposed MCP ports, CloudSEK reported on 5 October 2026. There is no patch for this, because nothing is broken in the protocol. The decision in front of leaders is whether MCP servers get the same ownership and access rules as any other server. My answer is yes, this quarter, funded from existing headcount.

The decision on my desk

The CloudSEK report turns a developer convenience into a budget question for security leaders. On 5 October 2026, CloudSEK published Caught in 4K: The Gentlemen Files. It describes an affiliate of the Gentlemen ransomware group who breached more than two dozen organisations across six countries. The victims sat in logistics, insurance, pharmaceuticals, AI, medical devices and government-adjacent work.

Two findings matter to me. First, the affiliate registered a command-execution handler as a tool inside an AI coding assistant, using the Model Context Protocol (MCP), and then ran attack steps through it in a live victim environment. CloudSEK says it has not found earlier public reports of an attacker using MCP this way in an active campaign. Second, the same operator scanned the internet for exposed MCP and AI assistant ports and treated them as a way in.

CloudSEK found all this through the attacker's own mistakes: an open file listing and a misconfigured storage server. It notified identified victims before publishing.

The question I would put to my own team is simple. Do we know where our MCP servers are, and who owns them?

What I would have believed

The mistake I'd have made is treating MCP as a developer tool rather than as infrastructure. The spreadsheet logic is easy to follow: MCP servers are small, developers install them on their own laptops, and they connect an assistant to a repository or a ticket system. None of that looks like a server I need to inventory, staff or audit.

On cost, the argument looks even better. I have a fixed security headcount. Every hour spent reviewing developer tooling is an hour taken from patching, identity work or incident response. Those areas carry measured risk, while MCP carried a theoretical one. If I had to choose, I would have left MCP to engineering managers and kept my people on the backlog with CVE numbers attached.

That is a judgement call, not a confession about a past event. But I think many leaders would have made it, for sound reasons.

What changed my mind

The CloudSEK case changes the risk from theoretical to observed. A command-running MCP tool is, from an attacker's point of view, a remote shell with a friendly name. If it listens on the internet without authentication it is a door, and if the attacker is already inside it is a quiet place to work, because tool calls look like normal assistant activity.

Platform Engineering's summary, by Nitish Mane, states the uncomfortable part: there is no CVE to patch here, because the risk comes from how MCP servers are deployed. My vulnerability scanner will not raise a ticket for it, and only an inventory will.

One detail keeps me honest: most of CloudSEK's victims were reached through credentials taken from build pipelines and old code history, not through MCP. MCP was one tool in a wider kit, so I do not read this case as "MCP is the new front door". I read it as "attackers now check this door, so we should know whether it is locked".

A separate example shows the same pattern in a product. Langflow's "Add MCP server" feature let any signed-in user run operating system commands on the server. The GitHub security advisory rates it 9.9 out of 10 and lists 1.9.0 as the fixed release. The CVE record tracks it as CVE-2026-105740. The Hacker News reported, citing Previdian's honeypot sensors, more than 1,700 exploit attempts. That one has a patch, so if you run Langflow, upgrade.

The operating principle I take from it

The principle for MCP is the one we already use for servers: anything that can run a command on our behalf has an owner, a boundary and a log. I would not create a new programme for this; I would fold MCP into the rules we already enforce. The threat.cafe Executive MCP Operating Principles card below is the version I would paste into a leadership channel.

threat.cafe Executive MCP Operating Principles (October 2026)

1. Every MCP server has a named owner and a review date. No owner, switch it off.
2. MCP servers listen on the local machine only. Remote ones require real sign-in.
3. Tools start switched off. Anything that runs commands, reads secrets or calls
   the network needs a named approver.
4. Tools run in a sandbox without our cloud keys and with limited outbound access.
5. Every tool call goes to the security log: who, when, which tool, what input.
6. People approve risky actions. Read-only actions do not need a prompt.
7. Approval prompts are the last layer, not the first.

How I would fund and apply it

Six controls carry the principle into practice, following CloudSEK's recommendations and the Platform Engineering summary, and I have ordered them by how fast a team can act.

Inventory with owners. List every MCP server, local or remote, with an owner, a purpose and a review date.
Off the internet, behind sign-in. CloudSEK advises binding MCP servers to the local machine only and accepting approved clients only.
Tools off by default. Enable only what a use case needs. Treat command-running tools as privileged, as CloudSEK says.
Sandbox with limited reach. Tool runs should not inherit a developer's cloud keys. Our post on egress allowlisting for coding agents and CI runners covers outbound limits.
Log every tool call. Send the logs to the security team's monitoring system. CloudSEK also suggests watching for unexpected MCP start-up requests.
Approval tiered by risk. We have argued before that approval prompts alone are weak, because people click through them.

On cost, I would not hire for this; I would take part of one platform engineer's quarter for the inventory and the log feed. The trade-off is real, because that time comes out of something else, probably a lower-priority tooling project. I would name that project in the planning meeting rather than pretend the work is free.

The threat.cafe MCP Exposure Self-Check is the first task I would assign. Only run step 3 against endpoints you own or are allowed to test.

threat.cafe MCP Exposure Self-Check (developer hosts and shared servers)

1. What is listening?
   Linux:   ss -ltnp
   macOS:   lsof -nP -iTCP -sTCP:LISTEN
   Windows: netstat -ano | findstr LISTENING
   Note any process that is an MCP server, agent or AI tool.

2. What is it bound to?
   127.0.0.1 / ::1        -> local only (expected for local MCP servers)
   0.0.0.0 / :: / LAN IP  -> reachable from the network; find out why

3. Is a remote endpoint protected by sign-in?
   From outside the trust boundary, call it with no credentials.
   Expect 401 or 403. Anything else needs review.

4. Who owns it?
   Every listener from step 1 maps to an inventory entry and an owner.

5. What can it do?
   List enabled tools. Flag any that run commands or hold credentials.

The best argument against spending on this

The strongest counterargument deserves a fair hearing, and it starts with the fact that one case is one case. The main route into most victims was stolen pipeline credentials, not MCP. A leader with a fixed budget could reasonably say: fix secrets in build pipelines first, because that is where the evidence points, and revisit MCP when a second campaign shows up.

I agree with the order, but I disagree with the deferral. The MCP inventory is cheap compared with a secrets programme, and an attacker is already scanning for exposed MCP ports. Waiting for a second case means learning about our exposure from someone else's report. I would run both, with pipeline secrets taking the larger share.

Where this would be wrong

My position weakens under three conditions. If our MCP servers all run on developer laptops bound to the local machine, the exposure risk is small, and logging matters more than inventory. If the main assistant vendors add default sign-in and default-off tools, some of this work moves to them. If follow-up research shows the MCP scanning found almost nothing exposed, I would cut the budget to the logging piece.

What we don't know yet

CloudSEK's public report does not say whether any victim was first reached through an exposed MCP server. We don't know how many exposed endpoints the scanning found, or whether other affiliates use the same approach. Nothing we have seen links the Langflow exploit attempts to this actor, and we are not suggesting a link. Unknown isn't the same as fine.

Three questions to ask your team this week

How many MCP servers do we run, and who owns each one? If the answer is "we'd need to check", that is the first task.
Can any of them be reached from outside our network without sign-in? Ask for the self-check output, not reassurance.
If someone ran commands through one of our MCP tools last Tuesday, would we know? The honest answer is often no.

What to tell the people who sign off

Finance: part of one engineer's quarter, no new hire, and a named project delayed to pay for it.
Security lead: the blast radius of one exposed MCP tool is whatever its host can reach, so sandboxing sets the ceiling.
Legal and compliance: tool-call logs are the evidence you will need if a regulator or client asks what an attacker did.
Operations: binding to the local machine is a one-line change per server, and the rollback is the same line.

Before adopting a new MCP server, check its name against the threat.cafe board. A server with no known bad can still be exposed by how it is deployed.

Volatility: VOLATILE (event-triggered review). Review when CloudSEK or another researcher publishes a second campaign using MCP, or when major assistants change their default MCP sign-in settings.

Sources

#mcp-servers #ransomware #exposure-management #tool-governance #leadership

All posts