每个人都可以，
拥有SSL证书

Sonatype Nexus Repository 爆了个 CVE-2026-7494，服务器端请求伪造，CVSS 5.3，看起来平平无奇。

漏洞点在 SSL 证书获取功能，拥有 nexus:ssl-truststore:read 权限的用户，能诱骗服务器向内部网络发起出站连接。说白了，只要你摸得到这个功能，就能拿 Nexus 当跳板，探测内网主机或访问那些不该暴露的服务。

漏洞本身不算高危，权限前置条件摆在那。但让我心里一紧的是出事的位置：SSL 证书相关逻辑。这几年大家都在推证书自动化，ACME 协议几乎成了标配，Nexus 这个功能本质上也是在跟证书打交道。把 SSRF 和证书获取绑在一起，暴露出一个容易被忽略的事实——证书管理链路一旦没做好网络隔离，很容易变成内网边界的缺口。

我见过太多团队，把 Nexus 这类制品库直接放在能同时访问公网和内网的位置，就为了让它自动拉取依赖、同步镜像，顺带帮忙管理几本 SSL 证书。想法没错，但默认配置下，出站请求的目标如果不受限制，证书获取模块就是一台现成的反向代理。

攻击者不用拿下 shell，只需要构造一个指向 http://169.254.169.254/latest/meta-data/ 的证书下载地址，云环境里的敏感信息就可能顺着 TLS 握手前的 HTTP 请求流出去。

这就不得不提到证书获取背后的协议——ACME。

ACME，全称 Automated Certificate Management Environment，直译过来就是自动证书管理环境。你可以把它想象成驾照自动续期系统：以前你得自己跑去车管所，填表、拍照、排队，到期忘换还得挨罚；现在系统跟医院体检数据打通了，只要体检合格，新驾照直接寄到家。

ACME 干的事差不多，它让服务器自动向证书颁发机构证明域名的控制权，证书签发、部署、续期全自动跑完，人不用插手。

用 Let's Encrypt 的 certbot 跑过一次就明白：

certbot certonly --manual --preferred-challenges dns -d example.com

这条命令下去，ACME 客户端会在你的 DNS 里加一条 TXT 记录，权威机构查完记录，确认域名的确是你的，证书就签下来了。整个过程只要服务器能出公网，能调 DNS API，完全不需要人工上传 CSR、粘贴私钥。

对于几十上百个域名的业务集群，ACME 把证书生命周期管理从“噩梦级”拉回到“一条 Jenkins Pipeline 就能搞定”的水平。

Nexus 的漏洞恰好处在这个链条的盲区上。它要做证书导入，就得访问用户指定的 URL 去拉证书文件。拉取之前如果没校验 URL 是否指向内网地址，SSRF 就是必然结果。很多自建证书管理平台、CI/CD 插件在实现“自动获取证书”时，都踩过类似的坑：URL 白名单没做，或者只做了简单的字符串匹配，被 http://127.0.0.1@evil.com/ 这种畸形 URL 轻松绕过。

运维的痛点不止是漏洞修复。证书过期导致业务中断的事故，每年大厂都得出几起。

手工管理的团队，证书到期前靠日历提醒，人员变动一频繁就断档。多域名、泛域名证书还要手动合并，IP 证书在一些内部系统里更是刚需，但不是每个 CA 都爽快签发。开发环境、测试环境、预发布环境，每一套环境都要配证书，纯手动操作会直接拖垮发布节奏。

lcjmSSL 这类平台的出现，算是把 ACME 的便利性又往前推了一步。它底层对接 Let's Encrypt、Google Trust Services、ZeroSSL，把多家 CA 的接口封装成统一 API，多域名、泛域名、IP 证书都能自动申请和部署。关键是不用自己维护 ACME 客户端的状态，也不用在每台机器上配定时任务，一个 API 调过去，证书的申请、验证、下发全在平台侧闭环。对于不想把精力耗在证书轮换上的团队，这种把证书管理外移的做法，天然减少了内网服务直接暴露证书获取逻辑的风险面——没有本地复杂的出站请求处理，也就少了像 Nexus 那样因 URL 校验疏漏导致的 SSRF 窗口。

安全这件事，往往不是你正面硬刚漏洞，而是用一套自动化程度更高的流程，把容易出错的环节从人工手里拿走。

CVE-2026-7494 修复了，升到 3.94.0 就完事。但证书管理这个坑，填平它靠的永远是自动化，以及尽量让出站请求的发起方远离内网边界。