先说结论，省得你往下翻：如果你手上跑的是单节点 MinIO，这套漏洞打不到你，可以先不动；但如果是多节点分布式集群，尤其节点间网络还不是完全可信的那种——8 月初曝出来的一批漏洞里最严重的一条 CVSS 能到 9.1，而官方仓库已经归档，这些漏洞不会等来官方补丁。这事需要本周就排期处理。
8 月这批漏洞，特殊在"没人认领"
8 月初，一直在给 MinIO 社区版打补丁的社区 Fork——PGSTY SILO（前身就是年初那个接盘 MinIO 的 pgsty/minio）——发了一篇安全公告。核心信息是：他们此前修过一个编号 CVE-2026-42600 的路径穿越漏洞（官方评分 4.9），当时就留了句话：删掉这一个端点，不等于同类问题查干净了。这次把账还上了——顺着同一个根因审计下来，又挖出三个协议面、共 12 处缺陷，全部继承自上游 MinIO。
严重程度完全不是一个量级：攻击者可以在磁盘目录之外任意写文件，可以把存着 IAM 和配置的系统卷整个搬进一个可读的桶里，可以递归删掉整棵目录树，也可以一条请求把进程打崩。按 CVSS 3.1 评估，最严重的一条到 9.1 分，而上游那条只有 4.9。知乎更麻烦的是，这批新漏洞拿不到 CVE 编号。CVE 流程需要一个受影响产品的维护方来认领和协调披露，而 minio/minio 仓库已经归档只读，那边没人了。漏洞不会因为仓库变成只读就消失，只是从此没有人负责。
把时间线串起来，才能看懂这次事故的必然性
很多教程还在写"docker pull minio/minio 一键部署"，但这个项目的状态早就变了：
2021 年 5 月：许可证从 Apache 2.0 切换为 AGPLv3
2025 年 5 月：社区版砍掉完整管理控制台，只剩一个对象浏览器
2025 年 10 月：停止社区版预编译二进制和 Docker 镜像分发，改成"仅源码分发"，想装新版得自己 go install 或自己构建镜像
2025 年 12 月 3 日：官宣进入维护模式——不再接收新功能和 PR，Issue 不再主动处理，“关键安全修复视情况评估”，README 引导你去看商业版 AIStor（一年 9.6 万美元管 400TB）。36氪
2026 年 4 月 25 日：GitHub 仓库正式归档只读，README 写明 “THIS REPOSITORY IS NO LONGER MAINTAINED.”。知乎
从官宣维护模式到现在，8 个多月了。这期间 MinIO 公司还在继续迭代它的商业产品，源码也还挂在 GitHub 上，你依然可以 fork、修改、在 AGPLv3 下运行——但"那个单二进制、开箱即用、有人管 Issue 的社区版"，确实已经结束了。这也是为什么 Google 上"MinIO 替代方案"的搜索热度在 2025 年底到 2026 年初涨了 3~5 倍，Reddit 的自建服务器板块原来普遍推荐 MinIO 的帖子，也都陆续补上了风险提示。知乎所以 8 月这批漏洞其实不意外：一个近 60k Star、Docker Hub 下载量超 10 亿次的项目，安全维护的接力棒从官方转移到了社区 Fork 手里。能有人接住，已经是运气。
风险分级：单节点和分布式，是两件事
公告里把受影响范围说得很明白，这也是这篇文章最想帮你分清楚的事：
这批漏洞对应的路由只在分布式纠删码部署里注册，利用条件是需要 cluster root 或节点间凭据。翻译一下：
单节点部署（包括绝大多数 homelab、开发测试、小项目图床）：不受这批漏洞影响。
分布式集群：受影响。如果你的节点间网络不是完全可信——比如节点跨机房、走公网或混合网络、有外部人员能触达内部端口——那就属于应当尽快升级或迁移的档位。
注意，“暂时打不到"不等于"永远安全”。维护模式意味着以后任何新漏洞都不会有官方修复，单节点用户只是多了缓冲时间，不是拿到了豁免。
三条路线，按你的部署形态挑
路线一：换 Silo，改一行镜像（推荐分布式用户优先评估）
如果你接受 AGPLv3（和你现在跑 MinIO 的协议完全一致），迁移成本低到离谱。API、数据格式、环境变量、监控指标名全都不变——人家改名的原则就是"改商标与品牌，不改接口与版权"。Docker Compose 部署的话，基本就是一行：
```yaml
services:
minio: # 服务名可以继续叫 minio
# image: minio/minio:latest
image: pgsty/silo:latest
environment: # MINIO_* 一个都不用改
volumes: # 同一个卷，同一份数据
```
背景信息：Silo 这个 Fork 的 Docker 镜像累计拉取已超过 50 万次，RAGFlow 的默认 Compose 编排、Grafana Loki 的 Helm 随附服务、戴尔 HPC 平台 Omnia、nixpkgs、DaoCloud 公共镜像加速都在用它，是目前最活跃的 MinIO 分支。知乎除了修漏洞，它还把被上游砍掉的管理控制台接了回来（8 月版本做到中英双语），并顺手清掉了 SUBNET、License 管理和遥测相关的遗留。如果你用 RPM/DEB 包部署，因为二进制和系统用户名变了，会多敲几条命令，但数据同样不动。
路线二：借机换到别的方案（适合本来就想摆脱 AGPL 或单一 fork 依赖的）
S3 兼容的替代品现在不少，但先泼盆冷水：迁移成本远高于换镜像，数据搬运和兼容性测试都是真工作量。几个常被提到的方向——RustFS，Apache 2.0 协议、Rust 写的，运维形态最接近 MinIO，但 2025 年 7 月才开源，生态沉淀浅。知乎此外还有 SeaweedFS（Apache 2.0，小文件场景强，S3 边界兼容性弱于 MinIO，深度依赖 aws-sdk 的要充分测试）；Garage（AGPLv3，轻量，适合异构硬件小集群，没有 Web 控制台）；Ceph（功能全但起步 6 台服务器，小集群严重过剩）；以及 Wasabi、Backblaze B2 这类 S3 兼容云服务。
另外提醒一句：市面上不少"MinIO 平替对比"文章本身就是 RustFS、国产存储厂商写的软文，看的时候记得区分事实和营销。
路线三：暂时什么都不动（只适合单机 + 内网 + 接受风险）
至少要完成三件事：确认 9000/9001 端口不暴露公网；把正在用的镜像和二进制备份下来（官方渠道已停更，minio/minio 的 Docker 镜像和 GitHub 上的旧版二进制都成了"绝版"，社区里已经有人在 docker save 囤镜像了）；在清单里把"MinIO 已无人维护"标成技术债，给未来迁移留预算。
几个你大概率会踩的坑
来自已经迁过的人的真实反馈：
漏洞扫描器会把 Silo 识别成官方 MinIO。很多扫描系统只看版本号，Silo 的版本号格式和上游一致，扫出来一样报 MinIO 的漏洞。企业用户要么给资产加白备注，要么调整扫描策略，别等审计时抓瞎。
有 Windows Server 部署需求的要注意，Silo 目前没有 Windows 服务端发布包。
AGPLv3 的传染性义务和原来一致，"换 fork 就能规避 AGPL"是想多了。想要宽松协议，只有走旧 Apache 2.0 基线的分支，比如 JuiceData 那个偏 JuiceFS 场景的 fork，代码基线较旧，或者干脆换 RustFS/SeaweedFS。知乎
别去拉 minio/minio 的 latest 镜像装新环境，那条渠道已经冻结在停更前的状态，装完就是带着一堆已知问题起步。
接下来值得盯的信号
Silo 维护的持续性。它的《Silo 宣言》写了 11 条承诺：永远 AGPLv3、无 CLA、不把既有功能移进付费墙、若上游恢复对社区版的承诺愿意收缩并回馈。承诺很体面，但这个项目主要靠一个人加 AI 编程工具在推进，后续节奏值得持续观察。
MinIO 公司的动作。商标是最大的变数——Silo 这次彻底改名，就是防一封 DMCA 律师函掐断供应链。如果 MinIO 对社区 Fork 发起商标主张，局面会再变。
替代方案的成熟度。RustFS 们喊出"PUT 性能反超 MinIO"的口号，但生产可用性和生态沉淀是两回事，别只看厂商 benchmark。知乎
最后一句话总结：单机玩家可以把这事收藏起来慢慢看，分布式集群请把升级排进本周。另外，如果你近期正准备照网上教程从零搭一套 MinIO——先停一停，2025 年 5 月之后的教程大多已过时，"默认用 MinIO"这个时代已经翻篇了。
