Getting remote code execution in CircleCI's MCP server took two HTTP headers and zero credentials. Send Host: localhost with no Origin header and you walk through the origin allowlist, call the run-pipeline tool with a config you wrote, and execute inside someone's CI under their org-wide API token. The researchers at Remedio, who found it, gave it an expected CVSS of 10.0.
The mechanism is worth understanding because you'll meet this pattern again in other AI tooling. The allowlist checks Host against an allowed set and explicitly passes requests with no Origin header. That design has teeth against browser-based attacks, where a malicious page can't forge those headers. But nothing forces an attacker to use a browser. curl picks every header on the wire.
The defaults made it worse: the server listened on all interfaces out of the box, and the request-token requirement could be switched off. A tool built with localhost trust assumptions, shipped with the posture of a public service. And running it as a shared team server holding an org token is a supported use case, not an abuse.
Also: there are three advisories for this package, not one. GHSA-xv5j-cwgj-22r4 is the header bypass. GHSA-m9x7-h9px-p447 is an unauthenticated command injection in the run_evaluation_tests tool, also RCE, and it got a fraction of the coverage. GHSA-8xjg-jpfh-5257 is a third issue. None of the materials I reviewed listed CVE IDs, so track by GHSA. The quiet command injection is the one most likely to still be unpatched somewhere.
Check your exposure in ten minutes
Where is it listening?
ss -tlnp | grep -i node
# 127.0.0.1:<port> = loopback only (good)
# 0.0.0.0:<port> = every interface (reachable)
In Docker, check docker ps for published 0.0.0.0:...-> ports. In Kubernetes, look for NodePort or LoadBalancer Services in front of it. Don't skip dev machines. A shared box with a published port is network-reachable.
Is a token required?
tr '\0' '\n' < /proc/$(pgrep -f mcp-server-circleci | head -1)/environ | grep -i REQUIRE_REQUEST_TOKEN
Unset or false, plus a 0.0.0.0 bind, is the worst case. Then test the allowlist against your own deployment:
curl -i -H "Host: localhost" http://<server-ip>:<port>/
If the MCP endpoint responds instead of rejecting you, the allowlist is decorative. Compare your installed version against the patched versions in all three GHSAs.
If it was reachable, hunt before you patch
Patching first feels productive and destroys evidence. Spend an hour on detection.
Pull proxy and firewall logs for requests to the MCP port where Host says localhost but the source IP isn't loopback. Almost nothing legitimate produces that pattern. Then check CircleCI pipeline history for runs nobody triggered or configs with steps you don't recognize. The attack goes through the run-pipeline tool, so the execution record lives in CircleCI, not on your host. Review the org token's activity too, because its activity is the attacker's activity.
If you find something, or your logging is too thin to rule it out, rotate. CircleCI token first, then whatever it could reach: project environment variables and contexts, plus any cloud identity your CI assumes. The blast radius isn't the box running the server. It's everything your CI can touch.
Then patch, and plan the migration. The standalone server is deprecated, so follow CircleCI's current guidance rather than investing further in it.
What I'd do today:
- Inventory every MCP server running in your org: where it listens, whether it requires a token, and which credentials it holds. Scope those tokens like production credentials, because they are.
- Patch all three CircleCI advisories, not just the famous one. Can't this week? Bind to 127.0.0.1, set
REQUIRE_REQUEST_TOKEN=true, and verify withss. Trust the socket, not the config file. - If any instance was network-reachable, hunt first, patch second, then rotate the org token and everything downstream of it.
- Treat any MCP server holding credentials as internet-facing, whether you meant it to be or not. Threat-model it that way.
Honest question for the comments: if someone asked right now, could you produce a list of every MCP server running in your org and the tokens attached to each?
Longer writeup with the full defender's playbook: https://axeploit.com/blog/circleci-s-mcp-server-rce-a-defender-s-playbook-for-all-three-advisories
