Artifactory三漏洞被串联利用 制品库遭接管

一、事件回顾：制品库被从零到管理员打穿

2026年8月28日，JFrog发布安全公告，修复自托管Artifactory的认证绕过漏洞CVE-2026-82329，评级为严重，CVSS 9.8。9月初，安全厂商watchTowr确认该漏洞已出现在野利用；Wiz进一步披露，8月15日至9月8日期间，多个攻击团伙针对暴露在互联网上的实例，把三个漏洞串成一条完整攻击链，从无需认证的普通请求一路走到管理员权限，并在服务器上植入Rust编写的后门。从取得入口到建立持久管理员访问，最快不到五分钟。

为什么这件事值得所有做软件开发和运维的人紧张？因为Artifactory不是一台普通服务器，它是制品库——公司内部所有构建产物、依赖包、Docker镜像、甚至是私有的配置和证书都在里面。构建流水线默认信任制品库：只要里面的包被替换，所有下游的构建、发布、上线的代码都会被污染。攻击者拿到制品库管理员权限，等于拿到了软件供应链的上游阀门。

二、三漏洞如何串成一条链

攻击链的第一环是CVE-2026-42018。它的缺陷在于：即使管理员关闭了匿名访问，Artifactory仍会向未登录的调用者返回一个内部匿名用户的令牌。这个令牌权限很低，本来做不了什么，但它是一张合法的身份凭证，为下一步提供了起点。

第二环是CVE-2026-42016，令牌作用域校验的缺陷：攻击者拿着刚才那个低权限令牌，通过构造请求就能把它换成管理员范围的令牌。两环连起来，一次未认证的HTTP请求就变成了管理员身份。公开信息显示，该漏洞影响7.133.10及更早的多个分支。

第三个漏洞CVE-2026-82329出在负责签发与校验凭证的JFrog Access服务里。它在构建集群加入密钥的校验列表时，把配置字符串按逗号切分却没有过滤空项，于是没有额外配置加入密钥的实例会得到一个幻影密钥——任何人都能推导出来，并用它伪造签名、生成管理员级凭证。这也是本次事件中最直接、最省事的一条入侵路径。

拿到管理员权限后，攻击者的动作很典型：枚举用户、用户组、权限集和联合访问拓扑，摸清组织边界；窃取凭证与密钥；创建新的管理员账号；再以制品库为跳板下发恶意包、植入后门。更麻烦的一点是，打补丁并不会让已经签发的令牌失效——令牌只要还在有效期内，攻击者的访问就还在。

三、检测与修复：补丁之外的排查清单

修复动作第一条是升级到官方公布的已修复版本，按分支对应7.111.21、7.117.28、7.125.20、7.133.29、7.146.38或7.161.20，选择与自己分支匹配的版本。升级完成后不要直接收工，因为攻击者很可能已经在里面留下了账号和后门。

排查建议按四步走。第一，轮换平台加入密钥，并吊销8月28日以来签发的访问令牌；第二，审计管理员用户、用户组与令牌，找出来历不明的账号；第三，核对仓库与配置变更，检查是否出现陌生的远程仓库、复制任务或反向代理配置；第四，抽查近期上传的包与镜像，比对校验值，重点排查构建产物中是否混入了异常文件。

日志层面重点看对Access服务的异常认证请求，以及短时间内大量枚举用户、权限的调用。同时要收敛暴露面：自托管Artifactory直接暴露在公网上，等于把供应链的钥匙挂在门外，应只允许办公网或VPN访问，管理接口单独限制来源，关闭不需要的匿名访问，并把它纳入资产台账和漏洞巡检范围。WAF只能争取时间，替代不了补丁与令牌轮换。

四、对青海政企的建议

对青海的政企和事业单位来说，这类漏洞的实际风险并不低。不少单位的研发与构建环境是外包或早期搭建的，Jenkins、GitLab、Nexus这类工具由外部团队部署，部署完就没有人再跟进版本；一旦有同事为了联调方便把管理端口映射到公网，漏洞就从纸面变成了入口。

建议本周内做三件事。第一，清点：把内网和云上所有构建与制品服务列进资产台账，确认哪些在用Artifactory、版本是多少、有没有暴露到公网。第二，闭环：能升级的立即升级，暂时不能升级的先断掉公网访问并限制管理接口来源，同时按等保要求留存日志与整改记录。第三，定责：把构建工具的版本更新纳入季度巡检，明确责任人和检查项。

供应链安全不是等保测评前临时补的材料，而是每一次构建都在使用的信任基础。对没有专职安全人员的中小单位，最务实的做法是先把暴露在公网的构建工具收进台账，再按暴露面排优先级，一个季度做一次版本更新与日志巡检，出事时至少能说清楚谁在管、改过什么。