事件概述
JetBrains 近日发布 TeamCity On-Premises 安全公告，披露一个编号为 CVE-2026-63077 的严重漏洞。根据 JetBrains 公告，攻击者只要能够通过 HTTP(S) 访问 TeamCity 服务器，就可能在未登录的情况下绕过认证检查，并以 TeamCity 服务进程权限执行任意操作系统命令。NVD 收录信息显示，该漏洞的 CVSS 3.1 基础评分为 9.8，属于 Critical 级别，攻击向量为网络，攻击复杂度低，不需要权限，也不需要用户交互。
这类漏洞之所以值得站长和中小企业运维高度关注，是因为 TeamCity 往往处在 CI/CD 链路的中心位置：它连接源码仓库、构建脚本、制品仓库、部署凭据、测试环境和生产发布流程。传统 Web 漏洞被入侵后，风险可能集中在单个站点；而 CI/CD 平台一旦被拿下，攻击者有机会顺着构建流水线影响更多系统，甚至污染后续发布的软件包和镜像。
JetBrains 表示，CVE-2026-63077 影响所有 TeamCity On-Premises 版本，修复版本为 2025.11.7 和 2026.1.3。TeamCity Cloud 用户不需要采取额外动作，云端必要措施已经由 JetBrains 处理。公告同时说明，截至其发布时，JetBrains 尚未发现该漏洞被主动利用的证据；但由于漏洞门槛低、影响权限高，公开公告发布后仍应按高优先级处置。
影响范围
本次受影响对象主要是自建的 TeamCity On-Premises，也就是企业或团队自行部署在云服务器、物理服务器、虚拟机或内网主机上的 TeamCity 服务。只要 TeamCity 登录页、REST API 或相关 HTTP(S) 服务能够被攻击者访问，就需要纳入排查。这里的“可访问”不只等于公网暴露，也包括办公网、VPN 内网、合作方网络、跳板机后可达的管理网络。
JetBrains 公告提到，该漏洞可通过 TeamCity agent polling protocol 被利用，攻击者不需要认证即可绕过检查并执行命令。由于执行权限取决于 TeamCity 服务进程本身，如果服务以较高系统权限运行，攻击后果会进一步放大；如果服务器上同时存放构建密钥、部署令牌、代码签名材料或云账号凭据，后续风险也会从一台 CI 服务器扩展到整个交付链。
对使用云主机托管开发工具链的团队来说，还要把网络暴露面一起看。很多 TeamCity 实例最初只是为了临时远程办公或方便代理访问而开放了管理入口，后续却没有收回公网端口。无论是自建机房还是云服务器，运维团队都应该确认 TeamCity 是否仅允许可信源地址访问。使用 速维云 等云服务器部署内部工具时，也建议把 CI/CD、代码仓库、制品库这类高价值服务放在更严格的访问控制之后，而不是直接暴露在互联网。
为什么 CI/CD 漏洞更危险
TeamCity 不只是一个“构建网页”。在实际生产环境里，它经常掌握比普通业务应用更敏感的上下文：源码拉取凭据、Docker Registry 登录信息、Kubernetes kubeconfig、SSH 私钥、对象存储密钥、数据库迁移脚本、自动部署 Token，以及构建过程中临时生成的配置文件。攻击者如果拿到 TeamCity 服务权限，第一目标通常不是让页面报错，而是寻找这些凭据和流水线入口。
更麻烦的是，CI/CD 平台天然具备“合法执行命令”的能力。构建脚本会执行 shell、调用编译器、拉取依赖、打包镜像、上传制品、触发部署。攻击者一旦进入这个系统，恶意动作更容易伪装成一次普通构建、一次失败重试或一次临时调试。对缺少审计的团队来说，异常可能不会立刻表现为服务器宕机，而是以凭据泄露、镜像被篡改、后门进入制品仓库等方式延迟暴露。
这也是为什么 TeamCity、Jenkins、GitLab CI、GitHub Actions Runner、制品仓库和镜像仓库都应被视为高价值资产。它们不一定对外提供业务访问量，却常常拥有跨环境权限。安全策略上，CI/CD 平台应至少做到单独主机部署、最小权限运行、凭据分级存储、构建代理隔离、管理入口收敛和日志留存，而不是与普通 Web 服务混放在同一台服务器上。
排查思路
第一步是确认资产。运维团队可以从 CMDB、云主机清单、反向代理配置、堡垒机记录、DNS 解析和端口扫描结果中核对是否存在 TeamCity On-Premises。不要只查生产环境，测试环境、临时构建环境、旧项目遗留主机同样需要检查。很多高危漏洞真正被利用的入口，往往是“没人记得还在跑”的旧实例。
第二步是确认版本。进入 TeamCity 管理界面或服务器安装目录后，核对当前版本是否已经升级到 2025.11.7 或 2026.1.3 及以上。不要只看包名或容器标签，要以实际运行实例为准；如果使用容器部署，还要确认镜像已重新拉取并重建运行，而不是宿主机上有新镜像、旧容器仍在提供服务。
第三步是检查暴露面。确认 TeamCity 的 HTTP(S) 入口是否对公网开放，是否通过反向代理、负载均衡、端口映射、VPN、零信任网关或堡垒机转发。即使短期内无法立即升级，也应先将管理入口限制在可信网络、固定办公出口或专用访问层之后。需要强调的是，访问收敛只能降低被打到的概率，不能替代补丁。
第四步是做入侵迹象排查。可以重点关注 TeamCity 审计日志、用户和 Token 变更、构建配置修改、异常构建触发、未知插件安装、构建代理新增、服务器系统日志、Web 访问日志以及出站连接记录。若发现异常命令执行、未知用户、凭据被访问或构建产物被替换，应按安全事件处理，暂停相关流水线并轮换高风险凭据。
修复与缓解建议
最优先的修复方式是升级 TeamCity On-Premises 到 JetBrains 已发布的修复版本：2025.11.7 或 2026.1.3。升级前应备份 TeamCity 数据目录、数据库和关键配置，确认插件兼容性，并尽量先在测试环境验证。生产环境升级可能涉及服务重启或构建中断，需要提前通知研发和运维团队，避开关键发布窗口。
如果暂时无法升级，JetBrains 也提供了安全补丁插件，适用于 TeamCity 2017.1 及以上版本。公告说明，TeamCity 2024.03 及更新版本会自动下载可用安全补丁插件并通知管理员；管理员可以在 Administration | Updates 的 Available security updates 中查看和应用。对于 TeamCity 2017.1 到 2018.1，安装补丁插件后需要重启服务器；从 TeamCity 2018.2 开始，可以不重启启用插件。补丁插件只针对本次 CVE-2026-63077，长期仍建议升级到最新稳定版本。
临时缓解方面，可以先把 TeamCity 的 Web 入口从公网撤下，或限制为可信 IP、VPN、零信任访问网关、堡垒机之后；检查反向代理是否还保留旧的临时转发；确认云安全组、防火墙规则、负载均衡监听和 DNS 解析没有把服务误暴露出去。同时，将 TeamCity 服务进程权限降到业务所需最低，不要以 root、Administrator 或具备广泛系统权限的账号长期运行。
凭据方面，建议清点 TeamCity 中保存的部署密钥、仓库 Token、云账号 Access Key、镜像仓库凭据和 SSH 私钥。若实例曾经暴露在不可信网络，或日志中出现异常构建与命令执行痕迹，应优先轮换这些凭据，并检查最近发布的制品、镜像和部署记录是否被篡改。不要在未确认影响范围前贸然删除日志，日志往往是判断是否被入侵的关键证据。
给中小团队的加固清单
这次 TeamCity 漏洞也提醒中小团队：内部开发工具链不应按普通后台系统处理。CI/CD、代码仓库、制品库和自动化部署平台，至少应该放入“高价值管理面”清单，建立单独的补丁窗口和暴露面审计。很多团队会给业务服务器配置监控，却忽略构建服务器；一旦构建入口被攻破，业务服务器的防护很可能被绕过。
建议把以下项目纳入常规检查：CI/CD 管理入口是否公网开放；是否启用多因素认证；管理员账号是否过多；构建代理是否与 TeamCity Server 分离；构建任务是否存在硬编码密钥；插件是否长期未更新；系统服务是否以最小权限运行；备份是否可恢复；日志是否集中留存；出站访问是否有审计。对云上部署环境，还应定期核对安全组和防火墙规则，避免测试端口长期遗留。
如果团队使用云服务器自建 TeamCity，可以将构建系统与业务系统分网段部署，关键管理端口仅允许办公出口或堡垒机访问。选择 速维云云服务器 这类托管环境时，也要同步规划备份、快照、访问控制和日志留存；云平台提供的是基础资源，CI/CD 平台本身的版本维护、权限拆分和凭据安全仍然需要运维团队负责。
后续观察
截至 JetBrains 公告发布时，官方表示尚未发现 CVE-2026-63077 的主动利用证据。不过，未认证远程命令执行漏洞公开后，攻击者通常会快速扫描互联网暴露资产，并尝试复现利用路径。TeamCity 历史上多次成为供应链攻击和横向移动的重点目标，因此即便当前没有在野利用证据，也不应等待安全厂商报告出现后再处理。
接下来需要关注三类信息：JetBrains 是否更新公告或补丁说明；NVD、CISA、CERT 或安全厂商是否补充利用情况与检测规则；企业内部是否出现异常构建、凭据访问或制品变更。对已经升级或应用补丁的团队，也建议在一到两周内继续观察日志，并复核是否存在遗漏实例。安全处置不是“打完补丁就结束”，尤其是 CI/CD 这类关键平台，还要确认补丁前是否已经被访问、凭据是否需要轮换、构建产物是否可信。
