Picture this: No password needed. There's no API token. Nothing. With one well-placed request, an attacker achieves an unauthenticated RCE in your CI/CD pipeline, taking full control of your build secrets and cloud identities.

That's not an imaginary scenario. It's a real security bug we found in CircleCI's MCP server. Critically severe, fully unauthenticated remote code execution. It’s a worst-case scenario and it’s all too real.

Expected CVSS3.1 designation: 10.0, Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
CVE has been requested and is pending assignment.

How It Works

The CircleCI MCP server can run as a shared, network-reachable service, allowing a whole team - or their AI agents - to access one instance. In this mode, the server carries the organization's API token to complete its tasks. To keep things safe and block sketchy browser-based attacks, a check is run on the request's Host and Origin headers.

That’s great in theory. In practice however, the attacker can set those headers. So, the safeguard consists of  inspecting a lock that the attacker already has the key to. Send a simple http request that says Host: localhost in the http header with no Origin, and you get right through. No credentials, no problem. 

Once in, you can freely communicate with connected tools. Call the "run pipeline" tool, hand it the pipeline configuration you wrote, and add a step to run your commands. CircleCI executes it using the organization's token. 

That’s all it takes to get your code running inside the entire organization's CI, including  access to its secrets, environment, and identity. Game over.

What the Attack Looks Like

It shouldn’t be that easy. But when the only thing standing in your way is two small checks, it is. 

(src/lib/auth/originValidation.ts):

export function isOriginAllowed(origin: string | undefined, allowed: Set<string>): boolean {

  // Non-browser clients (mcp-remote, curl) send no Origin – allow them.

  if (!origin?.trim()) return true;

  return allowed.has(origin.trim().toLowerCase());

}

export function isHostAllowed(host: string | undefined, allowed: Set<string>): boolean {

  return !!host?.trim() && allowed.has(host.trim().toLowerCase());

}

Those headers are set by the client, potentially with an attacker behind it. localhost is on the allowed-hosts list, and a missing Origin is explicitly waved through. So sending Host: localhost with no Origin results in both checks passing. On top of that, by default, the server listens on every interface.

(src/transports/unified.ts):

const bindHost = process.env.MCP_BIND_HOST || '0.0.0.0';

app.listen(Number(port), bindHost, () => { /* ... */ });

From there it's one call to the run_pipeline tool: you hand it a pipeline config with your own run: step; It could either dump the environment secrets or pop a shell. From there, CircleCI compiles it and runs it under the organization's token - giving you the ability to execute code inside their CI. 

Two moves total: one spoofed header, one tool call. Unauthenticated RCE. It doesn't get much worse than that.

MCPs Are A Mess

Here's the uncomfortable truth: CircleCI's bug wasn't a freak one-off. It's a symptom. Right now, the MCP ecosystem is, to put it bluntly,  a security mess. We’ve been watching the same broken pattern play out again and again.

We’ve pulled apart dozens of the most popular MCP servers out there - the little connectors that let AI agents actually do things: run commands, kick off pipelines, read your files, hit your databases. Across them all, we see the same thing: the no questions asked rubberstamped operability that opens up security risks is not a bug, but a feature of MCPs. It’s the intended functionality that makes them valuable to low-skill users. And that’s  what makes them so dangerous. 

Sit with that for a second. The dangerous part is a feature.

Which is why, in MCP land, an authentication bypass is basically a free RCE. In a normal app, getting past the login is just the start of a long climb; you still have to find something worthwhile on the other side. Here, the tools waiting behind that login are already loaded guns. Slip past the gate and the server runs your code for you. 

That's exactly what happened with CircleCI: the "auth bypass" and the "code execution" were practically the same move.

Now the good news. CircleCI handled it exactly right. We reported it, and instead of the usual runaround, their security team took it seriously, shipped a clean fix fast (version 0.19.2), and published a public advisory (GHSA-xv5j-cwgj-22r4). Quick, professional, complete. 

That's how coordinated disclosure is supposed to work, and honestly it's rarer than it should be. Kudos to them for that.

Unfortunately, not every vendor reacts the way CircleCI did. We’ve reported these sorts of vulnerabilities before only to be told  "we don’t see that as a problem." When that happens no advisory is issued and nobody outside the company ever finds out. Except for attackers, of course. They’ll find it just like we did. And when the vulnerability allows adversaries to run code in production environments without authentication, such a cavalier attitude is deeply irresponsible and downright dangerous.

The Takeaway

MCPs are used everywhere because they’re useful and easy to use. But the emerging ecosystem currently lacks appropriate policies and mitigations. So, please be careful every time you plug one of these servers into your stack. It’s not always  a harmless, read-only helper; it’s often an execution engine straight into your AI. Treat it as a production attack surface because that's exactly what it is.

Ask the uncomfortable questions before you ship. Is it truly authenticated, or merely presumed to be? Is it accessible from the network? And if someone gets past the gate, what can it actually run?

At Remedio, that last question looms large in all we do.  We specialize in finding and fixing the security gaps that would otherwise be overlooked - including in AI tooling. If you have or are considering deploying MCP servers, we can help you better understand their reach and the security implications of that reach.

Disclosure Timeline

30 July 2026→ Reported to CircleCI Security

6 August 2026→ Fix shipped (v0.19.2)

10 August 2026→ Public advisory published (GHSA-xv5j-cwgj-22r4)

A big thank you to the CircleCI security team for their quick and professional response.

FAQ

About Author

Omri Dar

Lead Vulnerability Researcher

Omri Dar leads vulnerability research within Remedio’s research arm, driving the discovery and analysis of security weaknesses across enterprise environments. He brings more than a decade of experience in the cybersecurity industry, with deep expertise in uncovering complex vulnerabilities across enterprise software, operating systems and embedded devices.