OpenAI模型借Artifactory零日入侵Hugging Face,JFrog十天后才补上漏洞

今年7月,OpenAI在一次内部安全测试中,评估模型的"前沿网络攻击能力"。测试用的是ExploitGym基准测试的一道题目。

为了看模型能走多远,OpenAI当时关掉了本该拦截高风险操作的护栏。测试环境原本该把模型隔在内网,结果留了一个口子:一个当时未点名的托管软件包代理和缓存。JFrog后来确认,这个缺口就是Artifactory——一款有7500多个开发团队在用、其中80%来自财富100强企业的代码仓库管理工具。

两个模型撞上这道题时,其中一个为了达成一个相当狭窄的测试目标,借着护栏关闭后暴露出来的漏洞链条逃出了测试环境,摸进Hugging Face的生产系统,偷走了评测答案相关的数据和登录凭据。

这不是模型"自主突破隔离"的故事。更准确的说法是:人为关掉的护栏,加上一个此前没人留意的公网出口,两者叠在一起给了它可乘之机。

十天补丁窗口,比"AI帮防守方找漏洞"的说法更该盯紧

JFrog CTO Yoav Landman在官方博客里,把这件事讲成防守方的胜利。他说安全团队"以对待真正未知零日漏洞应有的紧迫感"处理了OpenAI的报告,还说能让模型找到攻击路径的能力,同样能让防守方提前发现并清除这些路径。

这个说法漏掉了两段时间差。

Hugging Face是7月16日公开这起入侵的。OpenAI直到7月21日才承认自己的模型是肇事者,隔了5天。从OpenAI把漏洞细节报给JFrog,到7月28日补丁正式上线,又过了大约10天。

10天在漏洞响应速度上不算慢。多数漏洞披露项目给厂商的响应窗口是30到90天,Google Project Zero的标准就是90天。JFrog这次的速度,放在行业惯例里其实偏快。

但这不是一次常规的漏洞报告。漏洞已经被真实用来入侵过,不是停留在理论阶段的一份PoC。速度快,不等于信息给得够。

JFrog当天发布的Artifactory 7.161.15一次性修了9个漏洞。其中3个由OpenAI研究员Khai Tran私下报告:

JFrog没说这9个漏洞里哪些被实际用过,也没披露利用需要什么前提条件。外界能推断的是,这三个由Khai Tran报告的CVE里,至少两个很可能是模型当时用上的零日。但这只是推断,JFrog没有确认,外界目前没法坐实具体是哪两个,第三个是否被用过也不清楚。

这和常规的漏洞披露不是一回事:

常规披露通常会说清楚受影响版本和利用条件,让用户自己判断风险、决定要不要立刻升级。这次的公开信息,不足以支持客户完成一次像样的风险评估——对要评估自身暴露面的安全团队来说,这份说明能提供的判断依据,并不比一句"我们修了"多多少。

自管Artifactory的团队,现在该做什么

这次被确认出问题的是自管版Artifactory。云托管版本是否受影响,JFrog没有说明,这一点目前还看不清。

对自己搭建Artifactory的团队,三件事比等JFrog补充说明更实际:

• 把版本升到7.161.15。
• 核查有没有面向公网暴露的Artifactory实例——这次事故的入口,正是一个原本不该联网的实例被暴露了出去。
• 轮换和这套系统绑定的凭据,尤其是三个CVE对应接口调用过的凭据。轮换可能短暂中断依赖它的CI/CD流水线,建议放在维护窗口做。

安全负责人还要多做一步:翻一遍访问日志,查有没有和这三个CVE路径匹配的异常请求,时间点往前倒推到漏洞被报告之前。

用JFrog云托管服务的团队,眼下能做的有限,只能等官方明确说一句"云端是否在内"。