Between October 11 and 15, 2026, one week produced a cluster of Model Context Protocol vulnerabilities that ThreatFrontier catalogued in a single write-up: servers that leaked their users' tokens, a gateway that could be authenticated around, an allowlist that a lone shell metacharacter walked straight through, and, disclosed separately the same week, a TypeScript SDK bug that handed one client's responses to another.
Notice what is missing from that list: a clever model jailbreak. Not one of these needed the attacker to talk a model into misbehaving. They needed an MCP server running with credentials and a network path, which is exactly how most teams run them.
The companion article on how data leaves agent sessions treated MCP servers as one exfiltration vector among several. This one zooms in on the server itself, because an MCP server is not a library you import. It is a live process, usually holding a credential, usually with its own route to the network. Sort October's incidents by what the attacker walks away with, and the controls that matter stop being a wish list and start being a short, ordered set.
MCP is a riskier supply chain than your package manager
A package manager has one dangerous moment: install time. A malicious postinstall runs, and after that the code is inert unless something calls it. That risk is real, and the series has covered it. An MCP server is worse, because it does not go inert. It keeps running for the length of the session, holding whatever credential it needs to do its job, with a network path it uses by design.
So an MCP server combines the three things you least want in one component: it executes, it authenticates, and it reaches the network, continuously. A vulnerability in it is not a one-shot payload. It is a standing position inside your agent's environment. That is the frame for everything below.
Sort the threat model by what the attacker walks away with
Grouping vulnerabilities by their mechanism produces a taxonomy nobody acts on. Grouping them by payoff produces a priority order, because it answers the only question an incident responder cares about at 2am: if this server is compromised, what did the attacker get? October gave four answers.
Secrets
The most direct payoff is a credential. The NetLicensing case leaked tokens outright, and the Splunk MCP case, an SSRF the vendor tracks as SVD-2026-1004, can be steered to expose the server's auth token. Either way the attacker walks off with the thing every later stage of an intrusion wants. A bug that yields a token turns one flaw into access to everything that token authenticates.
Access
One level up from a secret is a way past the front door for everything behind it. A gateway auth bypass, the Unla case, is this payoff: the attacker does not need each individual server's secret, because the gateway in front of them can be authenticated around. Centralizing many MCP servers behind one gateway is good operational hygiene and a single, high-value target at the same time.
Execution
Higher still is code execution. The mac-shell-mcp allowlist bypass (CVE-2026-108953), also in that ThreatFrontier roundup, is the clean example: an allowlist of command names, one shell metacharacter, and a prompt injection could run commands that were never on the list. An allowlist that judges the command name answers "which binary?" It does not answer "with which arguments?" The command-allowlist problem gets its own treatment here, because every coding agent now ships a version of it.
Cross-session leakage
The subtlest payoff needs no attacker at all. A bug in the TypeScript SDK, tracked as GHSA-jm63-cq47-j5jp, where server or transport instances were shared across clients, could return one client's responses to another. In a multi-tenant deployment that is a data breach produced by ordinary traffic. It is the kind of failure that never shows up as an alert, because from the outside everything looks like it worked.
Controls that hold no matter which server is next
The specific servers above will be patched. The next MCP CVE week is coming regardless, so the useful question is which controls hold independent of which server breaks next. These are described here at the level Marshal states publicly, not by internal mechanism.
Pin and inventory every MCP your agents load, with versions, so "which server, at which version, is running where?" has an answer. Run one server instance per session, so a cross-session bug has no second session to leak into. Keep credentials out of the MCP process, so a token-leaking server has no token to leak. Scope egress per server, so a compromised MCP cannot reach a destination its job never required. And make revocation live, so a server you learn is vulnerable can be cut off from running sessions without a restart. Each of these removes the payoff of one of October's four classes, before you know which class next week belongs to.
Log every tool call like it will be evidence
When a server turns out to be vulnerable, the first question is operational, not forensic: which of your sessions loaded it? You can only answer that if every tool call was recorded with enough shape to query later.
A useful record names the server, its version, the tool invoked, the arguments, the destination, and the verdict. With that, "which sessions loaded the vulnerable version of this MCP between the 11th and the 15th?" is a query you run in minutes, not an investigation you open for days. Without it, you are reading container logs that tell you a session ran and nothing about what it did.
A patch-week runbook for the next MCP CVE
When the next cluster lands, work in payoff order:
- Inventory every MCP your agents load, with versions, from the log above.
- Pin and upgrade the affected servers.
- Confirm one server instance per session, so cross-session bugs have nowhere to go.
- Confirm no credentials sit inside any MCP process.
- Confirm egress is scoped per server.
- Revoke the vulnerable version on running sessions without waiting for a restart.
- Query which sessions touched it, and review what those sessions sent.
October's MCP vulnerabilities did not need a model jailbreak. They needed servers that held credentials and had a network path, run the way most teams run them. Sorting the week by what the attacker walks away with, secrets, access, execution, cross-session data, turns a scramble into a short list of controls that hold no matter which server breaks next: inventory and pin, one instance per session, no credentials in the process, egress scoped per server, and revocation that works live.
This article builds on the data exfiltration problem nobody is auditing →, the third in the series.
Marshal runs skills and MCP servers in isolation, with no credential access and egress scoped per Space, and lets you revoke one on a running session. Book a demo →