文章总结： 本文分析了CVE-2026-63077TeamCity认证绕过漏洞，指出CI/CD系统内部协议暴露到公网是高风险信任边界。漏洞允许未认证攻击者通过Agent轮询协议绕过认证并执行命令，影响可能扩散至供应链和身份层。建议立即升级或使用安全补丁，隔离Server与Agent，并回溯日志排查异常访问和进程行为。 综合评分： 90 文章分类： 漏洞分析,应急响应,安全建设,应用安全,实战经验

从一次 TeamCity 认证绕过，看 CI/CD 系统最危险的信任边界

云梦DC 云梦DC

云梦安全

2026年7月29日 16:23 日本

在小说阅读器读本章

去阅读

CI/CD 平台常被看作“研发基础设施”，但从攻击者的视角，它更像一台连接了源码、制品、部署密钥与生产环境的权限中枢。

2026 年 7 月，JetBrains 披露 TeamCity On-Premises 的 CVE-2026-63077：可通过 HTTP(S) 访问目标服务器的未认证攻击者，可能借助 TeamCity 的 Agent 轮询协议绕过认证检查，并以 TeamCity Server 进程权限执行操作系统命令。

这类漏洞值得关注的地方，不只是“未认证远程代码执行”这几个字，而是它揭示了一个经常被忽略的事实：CI/CD 系统内部的协议一旦被暴露到不可信网络，内部组件之间的信任假设就会变成外部攻击面。

先看结论：需要处理的不是一个端口，而是一条信任链

官方公告确认，该问题影响所有 TeamCity On-Premises 版本，已在 2025.11.7 和 2026.1.3 中修复；无法立即升级的环境可使用官方安全补丁插件。TeamCity Cloud 不受此问题影响。

但修补不是终点。一个 TeamCity Server 通常同时持有或可访问：

• 代码仓库的访问令牌、Webhook 密钥和部署密钥；
• 构建参数、制品仓库凭证与包签名材料；
• 云账号、容器镜像仓库和部署环境的服务身份；
• 连接 Build Agent 的调度与执行能力。

因此，Server 被攻破的影响往往并不止于“服务器上执行了一条命令”，而是可能向源码可信度、构建制品、发布流程乃至下游生产环境扩散。

技术视角：Agent 轮询协议为何会成为高风险入口？

TeamCity 的 Build Agent 需要与 Server 持续沟通，获取任务、提交执行状态和上传结果。为实现这一流程，服务端会接收 Agent 侧的轮询与协议请求。

这类机制本身没有问题，危险通常来自以下三个条件同时成立：

协议入口可经 HTTP(S) 从不可信网络访问 +请求身份或状态校验存在缺口 +后续处理路径拥有 Server 进程级能力 =未认证请求可能跨越“外部访问者 → 内部受信组件”的边界

根据 JetBrains 公告，CVE-2026-63077 正是发生在 Agent polling protocol 的认证检查环节。这里最重要的防守理解是：协议名称里带着“Agent”，不代表它天然只能由 Agent 访问。

只要协议终点与 Web 服务共享可达路径，或者反向代理、负载均衡与防火墙没有把它限制在受信网络，攻击者就可能把自己伪装成“参与内部协作的一方”。

为什么 CI/CD RCE 的影响常常被低估？

传统服务器被远程执行代码，通常首先担心主机失陷。CI/CD Server 被远程执行代码时，应该把风险拆成四层。

1. 配置层：密钥与连接信息

构建配置中可能保存 VCS 凭据、云服务令牌、制品仓库认证信息或第三方发布密钥。即使密钥经过加密存储，能够控制 Server 进程的攻击者也可能读取运行时配置、环境变量或劫持正常调用链。

2. 供应链层：制品完整性

攻击者若能修改构建逻辑、替换依赖来源、污染缓存或篡改构建产物，影响可能在“正常发布”过程中被带入用户环境。这种攻击往往比直接入侵一台业务主机更难发现，因为制品可能仍然带着合法的流水线痕迹。

3. 身份层：工作负载权限外溢

许多流水线拥有部署或基础设施管理权限。若权限没有按项目、环境与动作收紧，一个 CI/CD Server 的失陷可能转化为云资源、Kubernetes 集群或生产系统的进一步访问。

4. 运维层：横向移动的跳板

Server 与 Agent、代码仓库、制品库之间本就存在大量正常通信。攻击者驻留在这个节点后，可以把恶意活动伪装成构建、下载依赖或发布动作，使单点日志很难还原完整攻击链。

修复优先级：升级优于“临时挡一挡”

官方给出的优先修复路径是升级至 2025.11.7 或 2026.1.3。对于短期内无法升级的 TeamCity On-Premises 环境，可部署面向 2017.1+ 的官方安全补丁插件。

建议按以下顺序处理：

不要把 Build Agent 和 Server 放在同一台主机

公告中还强调了一条很实用的架构原则：TeamCity Server 应运行在专用主机上，与 Build Agent 分离。

这不是单纯的性能建议，而是降低权限耦合的措施。

检测与排查：关注“协议不该出现在哪里”

即使已经修复，也建议对补丁前后的日志做一次回溯。排查重点不应只是搜索某个漏洞特征，而要寻找与正常 CI/CD 行为不匹配的组合信号：

• 来自公网或异常地理位置的 TeamCity HTTP(S) 访问；
• 在非发布时段出现的 Server 进程异常派生、脚本解释器启动或计划任务变更；
• 配置、插件目录、构建模板和全局参数的异常修改；
• 构建制品哈希、签名结果或依赖锁文件与历史基线发生异常偏离；
• 与 TeamCity 关联的令牌在不符合流水线时间窗的场景下被使用；
• Server 到代码仓库、制品库、云 API 的访问量或目标出现突变。

在检测规则设计上，可将 Web 访问日志、TeamCity 审计记录、主机 EDR、代码仓库审计、制品库日志和云审计日志串联。单一日志源很难说明问题，但“异常外部访问 + Server 进程异常行为 + 凭证使用异常”的时间关联，往往能显著提高告警质量。

把这次漏洞转化为一份架构检查清单

对于所有自建 CI/CD 平台，都值得逐项回答：

• 仅供内部组件使用的协议端点，是否真的无法从公网访问？
• Server、Agent、代码仓库、制品库是否存在不必要的网络互通？
• Server 进程的操作系统权限是否已压缩到最低？
• 流水线是否使用短期、可审计、按项目隔离的工作负载身份？
• 是否能够在不依赖单一平台日志的情况下，追踪一次构建的身份、网络与制品变化？
• 高危安全公告发布后，是否有可量化的资产发现、补丁、验证和凭证轮换闭环？

如果这些问题中有任何一项答案不明确，真正需要补的往往不只是一个版本号，而是 CI/CD 的信任边界。

结语

CVE-2026-63077 的价值，不在于提供一个“又一个 RCE”的标题，而在于提醒我们重新审视 CI/CD 中的内部协议：一旦它能被外部请求触达，内部组件之间默认存在的信任就必须被重新证明。

对防守方而言，升级修复是第一步；隔离 Server 与 Agent、收紧公网暴露、拆分凭证权限、验证制品完整性，才是让下一次类似漏洞难以扩大为供应链事件的关键。

免责声明：

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

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

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

本文转载自：云梦安全 云梦DC 云梦DC《从一次 TeamCity 认证绕过，看 CI/CD 系统最危险的信任边界》