先把结论放前面：跨平台同步/备份工具 rclone 发布了 1.75.2，一次补掉一批洞，公告编号从 CVE-2026-116187 一路排到 116196。里面最该先动手的有两个——一个在它的"自动更新"上，一个在 serve webdav 上。低于 1.75.2 的版本都建议尽快升。

rclone 这东西在运维手里出镜率太高了：同步对象存储、定时把备份往异地推、临时起个 WebDAV/WebDAV 给同事拷文件。正因为它是"守着数据的那一环"，出在它身上的洞，分量往往比看起来重。

一、自更新校验绕过，CVE-2026-116189，评分 7.7

rclone selfupdate 会去核对发布的 SHA256SUMS，而那段校验值本应来自 PGP 清签（clearsigned）区块。问题在于：它会信任签名区块之前的那段未签名字节里的校验值。于是，控制了发布分发路径的人（镜像、CDN，任何能改下载内容的一环），只要在签名块前面塞进一行未签名的、指向自己那包恶意压缩包的校验值，selfupdate 就会照着这行去装——把攻击者准备的可执行文件覆盖成 "rclone"。影响 1.55.0 到 1.75.2 之前。

这个洞扎人的地方在于：它动手脚的不是业务代码，是更新通道本身。你平时怎么放心让它自己更新，它就能怎么被换掉。

二、serve webdav 路径穿越，CVE-2026-116191，评分 8.7

rclone serve webdav 里，一个没有校验的 .. 路径组件就能让请求越过服务根目录。未认证的攻击者先发一个 MKCOL /.. 落下一个 VFS 节点，接着用 PUT / MOVE / COPY / MKCOL 去创建、覆盖、删除属于其他租户的文件。低于 1.75.2 的都中。同一个 serve webdav 上还挂着一个 CVE-2026-116193（6.9）：光发 OPTIONS 请求就能绕过认证。

这一版顺手修掉的还有一串

  • CVE-2026-116187（6.1）：serve s3 --auth-proxy 越权，已认证租户能改别人的分片上传；
  • CVE-2026-116188（6.9）：serve s3 分片重排时的内存记账整数溢出，绕过配置的缓冲上限；
  • CVE-2026-116192（8.2）：http / netstorage 后端 SSRF，未认证就能把请求重定向出去；
  • CVE-2026-116190（6.3）：WebDAV 后端在 HTTP 跳转时，把操作者配的自定义凭据头转发给了别的 host；
  • CVE-2026-116194（7.6）：pCloud 后端 localhost OAuth 回调的 CSRF，state 校验被关掉、还信了主机名；
  • CVE-2026-116195（7.0）：local 后端 translateLink 路径穿越，.rclonelink 后缀的裁剪发生在包含性检查之后；
  • CVE-2026-116196（6.0）：b2 后端在下载重定向时，把在用的 Authorization token 和 SSE-C key 漏了出去。

出处都可以在 rclone 仓库的公告区翻到，比如自更新那条 GHSA-w33h-3qgq-8mv8、WebDAV 路径穿越那条 GHSA-44pm-2q5p-fm63。

先断自己有没有事，一行：

rclone version

版本号低于 v1.75.2 就得动。

这里有个容易踩的绕圈：被修的对象之一就是 selfupdate 本身，所以别指望这台机器上的旧版自更新去把自己升上去——请手动下载官方包覆盖，或者走系统包管理器升。另外，如果你正把 serve webdav / serve s3 挂在网上给同事用，先别只排队等升级窗口，能加一层认证/限访控制就先加上。

rclone 版本自查：低于 v1.75.2 需升级，≥ v1.75.2 已修

说起来，之前还写过一个把请求骗去连元数据地址的坑，跟 rclone 这次的 SSRF 思路一模一样——都是把「服务器自己发出去的请求」当成了可信输入。这次先把自己手上那台 rclone version 敲一遍，剩下的交给升级窗口——不然哪天更新通道被换了包，还得从我这儿开始查起。