文章总结： CircleCIMCP服务器存在未认证远程代码执行漏洞，攻击者仅通过伪造Host头并省略Origin头即可绕过验证，调用工具接管CI/CD环境与密钥。该问题暴露了MCP生态中工具即执行器的结构性风险。建议将MCP服务器视为生产攻击面，严格审查其真实认证机制与网络暴露面，若曾暴露则必须轮换所有相关凭证。 综合评分： 88 文章分类： 漏洞分析,WEB安全,漏洞预警,软文广告

无需密码的 RCE：CircleCI MCP 服务器漏洞拆解

幻泉之洲

2026年8月22日 10:51 北京

在小说阅读器读本章

去阅读

CircleCI 的 MCP 服务器存在未认证远程代码执行漏洞，攻击者只需伪造 Host 头并省略 Origin 就能完全控制组织 CI/CD 流水线，CVSS 3.1 评分 10.0。文章拆解了漏洞原理、攻击路径，也聊了 MCP 生态里“工具即执行器”的结构性风险。

想象一下：不要密码，不要 API token，什么都不用。一个精心构造的请求，攻击者就能在你的 CI/CD 流水线里拿到未认证 RCE，接管构建密钥和云身份。

这不是虚构场景。这是我们在 CircleCI 的 MCP 服务器里找到的真实漏洞。严重程度最高，完全未认证的远程代码执行。最坏的情况，而且真实存在。

预期 CVSS 3.1 评分：10.0，Critical（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）。CVE 编号已申请，等待分配。

工作原理

CircleCI MCP 服务器可以跑成一个共享的、网络可达的服务，整个团队或他们的 AI 代理共用一个实例。这种模式下，服务器带着组织的 API token 去完成任务。为了挡住浏览器类的攻击，服务器会检查请求里的 Host 和 Origin 头。

理论上没问题。实际上，攻击者自己就能设置这两个头。等于说，这个安全检查只是在检查一把攻击者本来就拿着钥匙的锁。发一个 HTTP 请求，Host 头填 localhost，不带 Origin，就过去了。不需要凭证，没有障碍。

进去之后，你可以和连接的工具自由通信。调用 run pipeline 工具，把你写的流水线配置传进去，加一步执行自己的命令。CircleCI 就会用组织的 token 去执行它。

只要这一步，你的代码就跑进了整个组织的 CI，包括它的密钥、环境变量和身份。游戏结束。

攻击长什么样

本不该这么容易。但当挡在你面前的只是两个小检查时，就是这么容易。

export function isOriginAllowed(origin: string | undefined, allowed: Set): 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): boolean {  return !!host?.trim() && allowed.has(host.trim().toLowerCase()); }

这些头是客户端设置的，攻击者可能就在客户端后面。localhost 在允许列表里，缺少 Origin 被显式放行。所以发送 Host: localhost 且不带 Origin，两个检查都通过。更麻烦的是，默认情况下服务器监听所有网络接口。

const bindHost = process.env.MCP_BIND_HOST || ‘0.0.0.0’; app.listen(Number(port), bindHost, () => { /* … */ });

接下来就一次 run_pipeline 工具调用：把你的流水线配置传进去，里面带上自己的 run: 步骤。这一步可以导出环境变量里的密钥，也可以弹一个 shell。CircleCI 编译它，然后用组织的 token 跑起来——你就能在他们的 CI 里执行任意代码。

总共两步：伪造一个请求头，调用一次工具。未认证 RCE。没有比这更糟的了。

MCP 是一团糟

说句不客气的话：CircleCI 这个 bug 不是孤例，它是个症状。眼下的 MCP 生态，说白了，安全上就是一团乱。我们反复看到同一种坏掉的模式。

我们拆过几十个最流行的 MCP 服务器——那些让 AI 代理真正干活的连接器：执行命令、启动流水线、读文件、连数据库。看下来一个共同点：那种“什么都不问、盖章放行”的可用性，不是漏洞，是 MCP 的特性。正是让低门槛用户觉得有价值的设计。也正因如此，它们才这么危险。

你可以停下来想一想。危险的部分恰恰是特性本身。

所以在 MCP 的世界里，认证绕过基本等于白送 RCE。普通应用里，过了登录只是万里长征第一步，你还得在门后面找到有价值的东西。这里不一样，门后面的工具本身就是上了膛的枪。溜过大门，服务器就直接替你跑代码。

CircleCI 这次就是这样：“认证绕过”和“代码执行”几乎是同一个动作。

现在说点好的。CircleCI 处理得很对。我们报告后，没有遇到踢皮球，安全团队认真对待，很快发布了干净的修复（版本 0.19.2），并公开了公告：

GHSA-xv5j-cwgj-22r4[1]。快速、专业、完整。

这才是协同披露该有的样子。说实话，这种反应比想象中少见。这里要夸他们一句。

可惜不是每个厂商都像 CircleCI 这样。我们以前报告过类似漏洞，对方回一句“我们不认为这是问题”。然后没有公告，公司外部没人知道。攻击者当然会知道，他们会和我们一样找到它。当漏洞允许攻击者在生产环境里未认证执行代码时，这种态度极不负责任，而且很危险。

要点

MCP 到处都在用，因为它有用、上手快。但这个新生生态目前缺少合适的策略和缓解措施。所以每当你把一个 MCP 服务器接进技术栈，请小心。它不一定是个无害的只读助手，常常是直通 AI 的执行引擎。把它当作生产攻击面来对待，因为它就是。

上线前问几个不好回答的问题。它真的做了认证吗，还是只是“以为”做了？网络可达吗？如果有人过了这道门，到底能执行什么？

在 Remedio，最后一个问题贯穿我们所有工作。我们专门找那些容易被忽略的安全漏洞，包括 AI 工具里的。如果你已经在用或考虑部署 MCP 服务器，我们可以帮你把它的触达范围和安全隐患搞清楚[2]。

披露时间线

• 2026年7月30日 → 报告给 CircleCI 安全团队
• 2026年8月6日 → 修复发布（v0.19.2）
• 2026年8月10日 → 公开公告发布（GHSA-xv5j-cwgj-22r4[1]）

非常感谢 CircleCI 安全团队快速且专业的响应。

FAQ

安全团队怎么判断 MCP 服务器是否已经被入侵并影响 CI/CD 环境？

把 MCP 访问日志、工具调用记录、配置变更和密钥访问事件关联起来看。调查重点应该放在正常开发流程之外创建的流水线、异常命令步骤、意外的环境变量访问，以及来自陌生网络来源的作业。单看 MCP 遥测不够，因为后续动作会出现在下游 CI 平台里。

修补 MCP 服务器后，组织该不该轮换 CircleCI 密钥？

该。如果漏洞服务曾经暴露给不可信网络，或者无法排除可疑活动，就应该轮换。补丁只能阻止未来被利用，不会让之前通过流水线执行暴露的凭证失效。优先轮换项目 token、云凭证、

参考资料

[1] https://github.com/CircleCI-Public/mcp-server-circleci/security/advisories/GHSA-xv5j-cwgj-22r4

[2] https://remedio.io/demo/

[3] https://remedio.io/blog/the-critical-unauthenticated-rce-vulnerability-in-circlecis-mcp-server/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《无需密码的 RCE：CircleCI MCP 服务器漏洞拆解》