结论先行：2026 年 10 月 12 日，一个被大量企业自建使用的代码托管与流水线平台发布了紧急补丁，修掉一个评分 10.0 的漏洞（CVE-2026-97229）：攻击者不需要登录，只要在流水线配置里放一段特制的正则表达式，就能在服务器上执行代码。这件事真正需要回答的不是「补丁打没打」，而是「这台机器凭什么能被这么直接地碰到」。

这次漏洞的形状

按厂商公告与公开安全通告，漏洞位于平台的 CI/CD 正则表达式编译器，根因是校验不充分导致的整数溢出。评分向量是网络可达、利用复杂度低、不需要任何权限、不需要用户交互，且影响范围越出组件本身。

受影响的版本是自建实例的三个维护分支；云托管版本已完成修复，专用托管客户无需操作。同批还修复了二十多个安全问题，其中包括一处跨站脚本、一处流水线权限提升，以及一处可能暴露「受保护变量」的缓存投毒问题。截至 10 月 12 日，厂商与监管侧的通报均未提及在野利用，也没有公开的利用代码。

为什么这台机器值得单独拎出来看

它不是一个普通业务应用。源码、流水线定义、部署密钥、镜像仓库凭据、构建任务所继承的云端令牌，通常都在这台或这组服务器上。

一旦被打穿，性质就接近软件供应链被打穿：能读所有仓库、能伪造提交记录、能污染构建产物，并且可以顺着构建任务能够到达的环境继续往里面走。评分里「影响范围越出组件本身」这一项，说的就是这件事。

先做的三件事

一、按分支核对版本，而不是凭印象

同一个模块在三周前刚修过一次同类问题，那次的评分是 9.9，但需要先有账号才能利用——两次之间真正的差别，正在于这次不需要账号。这类连续披露说明「我记得升过」不足以作为判断依据，要按分支逐台核到具体版本。

二、把它的可达范围先收回来

自建实例常常为了外部协作者直接挂在公网上，这是设计使然。在补丁窗口内，先限制访问来源是成本较低的一种止损动作：能推迟到维护窗口升级的，先把入口收窄；必须立刻升的，升级后核对一遍对外暴露的入口清单。

三、查一遍流水线变量与仓库权限

同批修复的缓存投毒问题可能暴露受保护的流水线变量。变量里如果放的是生产环境凭据，那它本身就是一把钥匙——需要做的是把这些凭据从「变量」降级为「按需取用」，并复盘一次谁能看到它们。

再往下一层：从源码到生产，中间有几道门

这次事件暴露的是一个界面问题：很多企业把「研发工具」和「生产系统」当成两件事来管，但对攻击者来说，它们是同一条路。

按可达性来划，这条路上至少有三段不同的信任关系：研发终端与代码平台之间、代码平台与构建集群之间、构建集群与生产环境之间。三段共用一条通路，等于三段只有一道门；任何一段被突破，其余两段都失去了意义。

具体可以这样收：生产环境的入向权限只留给构建侧的最小集合，构建侧的出向只允许到制品库，人的终端不直接连生产。把「谁能碰到谁」写成一份可核对的清单，比逐台加固更容易长期维持。

边界与前提

文中的漏洞编号、评分、受影响范围来自厂商公告与公开安全通告（2026 年 10 月 12 日）。截至该日无在野利用的记录，不代表后续不会出现。收敛可达范围是降低影响面的动作，不能替代打补丁本身。深圳市奇摩计算机有限公司在为客户做数据中心边界梳理时，通常是先按「谁能碰到谁」把通路画出来，再定收口顺序。需要梳理这类通路，欢迎预约咨询。