文章总结： NexusRepository3于2026年9月2日爆发两个CVE：CVE-2026-77125为blobstore端点鉴权缺失，CVE-2026-77122为仓库详情接口信息泄露，可串联实现仓库流量劫持。官方已发布补丁，建议清理权限矩阵、监控审计日志并对代理仓库remoteURL加白名单。 综合评分： 85 文章分类： 漏洞分析,安全工具,解决方案

Nexus双CVE同日爆发

Java栈 Java栈

云栖码客

2026年9月5日 01:14 安徽

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

Nexus 双 CVE 同日爆发

9 月 2 日下午，Sonatype 一次性甩出两个 CVE。都是 Nexus Repository 3 的授权问题，都是同一个团队同一时间交出去，只是攻击面一个在 blobstore 端点，一个在仓库详情接口。CVSS 4.0 分别打了 7.1 和 5.3，加起来算个中等偏上的日。真正让这两个漏洞值得单独讲一讲的，是它们串起来能干什么。

两个 CVE 的触发条件

CVE-2026-77125 说的是 blobstore group 管理的两个 REST API 端点上，鉴权校验漏了。攻击者只需要 nexus:blobstores:create 权限就能把已有 blobstore 改成 group blobstore——按 Sonatype 的设计，这类修改本应需要 nexus:blobstores:update。注意 nexus:blobstores:create 是命名权限（named permission），不是默认授予，必须管理员手动加，这一点 Sonatype 在公告里特意强调，因为怕被误读成”任何登录用户都能打”。

CVE-2026-77122 是仓库详情端点 GET /service/rest/v1/repositories/{repositoryName} 上的信息泄露。攻击账号对某个 group repository 有 read 或 browse 权限就够了，通过查询这个 group，能顺带拿到不属于该 group 的 member repository 元数据。代理仓库返回的 remote URL 是重点泄露项，内部上游主机的域名、路径甚至凭据片段都可能被带出去。匿名账号如果在特定角色配置下拿到该权限，一样会被利用。

影响版本是 3.19.0 起、3.95.x 及以前全部。Sonatype 官方在 9 月 2 日公告里给出了修复版本，本文写作当日 Sonatype 支持页抓取失败，具体补丁版本号请以官方公告和 release notes 为准，不要停留在 3.95.x 或更老的分支。

CVSS 4.0 向量的共同点是 AV:N/AC:L/AT:N/UI:N，都是网络可达、复杂度低、无需交互。区别在 PR 和 VI/VC：77125 的 PR:L、VI:H，77122 的 PR:L、VC:M。7.1 的高分基本靠完整性影响撑起，5.3 的中分靠机密性影响撑起。

鉴权检查漏在哪一步

从公开披露信息推断，77125 的问题出在 blobstore group 管理那两个端点的授权装饰器上。端点上应该做的 nexus:blobstores:update 检查被写成了 nexus:blobstores:create，导致权限检查命中了创建权限的路径，而不是更新权限的路径。这是典型的权限常量错位，代码层面多半是同一个 check 函数复用到了不同语义的 handler 上，或者授权注解参数写错位置。CWE-863 Incorrect Authorization，跟之前 CVE-2026-59313 那种 SSE 流污染完全不是一个路数。

77122 的问题则是仓库详情端点在做鉴权决策时，只校验了调用者对 group repository 本身有没有读权限，没有对返回体里的 member repository 信息做二次授权判断。group repository 的元数据聚合逻辑没意识到成员列表的字段本身也是敏感数据——尤其是代理仓库的 remote URL。这类”聚合视图泄露子资源”的模式在 Java 生态里出现过好几次，Nexus 这版是踩在 REST API 层。

两个漏洞串起来

单独看都是低中危，串起来就完整。攻击路径很直白：先用 77122 摸清内部拓扑——拿到内部代理仓库的名字、上游 remote URL、可能的内部主机域名，构建出仓库系统的攻击面图；再用 77125 篡改某个高价值仓库对应的 blobstore 配置，比如把存储后端改到攻击者控制的 S3 endpoint，或者把某个 host blobstore 塞进一个恶意 group 里，让整个业务仓库的构件拉取都走一遍攻击者控制的路径。仓库代理层的流量劫持，代价就是两次 REST 调用。

防御清单

先把权限矩阵拉一遍，找出所有持有 nexus:blobstores:create 的账号，逐个审视是否合理。这个权限通常只该给到少量运维角色，如果某个开发或构建角色上挂了这个权限，多半是历史遗留。同时升级到 Sonatype 官方在 2026-09-02 公告中发布的补丁版本，具体版本号看官方 release notes 或支持页面更新，不要停留在 3.95.x 或更老的分支。

审计日志里两件事要监控：nexus:blobstores:create 权限用户在 /service/rest/v1/blobstores 上的写操作、以及 GET /service/rest/v1/repositories/{name} 端点的调用频率。正常的运维工具一般是批量拉取，非业务时段或异常源 IP 的调用都值得告警。

如果代理仓库的 remote URL 涉及内网主机或云凭证片段，可以在反向代理层加白名单，确保这些端点仅允许运维网段访问。匿名账号如果开启了 anonymous access，务必复查其角色——nexus:blobstores:create 和 nexus:repositories:read 的叠加，就是这次攻击链的起点。

原理演示

两个 curl 骨架，仅作原理演示，不是可直接运行的完整 exploit。

# 用 77122 拉取 group repository 元数据，看响应里是否夹带 member 仓库信息
curl -s -u "$user:$pass" \
  "https://nexus.internal/service/rest/v1/repositories/internal-group" \
  | jq '{type, name, group, memberNames, remote: .proxy.remote}'

# 响应中的 group.memberNames 字段是判断信息泄露的关键
# 若有不属于该 group 的仓库名，77122 命中

# 用 77125 尝试把一个现有 blobstore 改成 group blobstore
curl -s -u "$user:$pass" \
  -X PUT -H "Content-Type: application/json" \
  -d '{"name":"internal-group","members":["evil-backend"]}' \
  "https://nexus.internal/service/rest/v1/blobstores/evil-backend"

# 如果返回 200 而不是 403，说明调用者只有 create 权限也能触发 update 行为
# 攻击者拿到 create 权限后，即可将任意 host blobstore 转成 group

真实场景下的利用链通常还要叠加别的权限（比如拿到能读内部代理仓库的 read 权限），但只要有 nexus:blobstores:create 挂在一个不该挂的角色上，77125 就已经成立。77122 更宽松一些，只要能进 group repository 的 read 权限就能开打。

一句话总结

Sonatype 官方在 2026-09-02 已经发布补丁版本，具体版本号请见官方公告；权限矩阵的清理和代理仓库 remote URL 的内网白名单，是打完补丁之后仍然要做的事。

参考：

• https://support.sonatype.com/hc/en-us/articles/54643114434451
• https://www.rapid7.com/db/vulnerabilities/cve-2026-77125/
• https://www.rapid7.com/db/vulnerabilities/cve-2026-77122/
• https://dbugs.ptsecurity.com/vulnerability/PT-2026-84836

免责声明：

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

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

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

本文转载自：云栖码客 Java栈 Java栈《Nexus双CVE同日爆发》