关于 PGSTY SILO

• 1: PGSTY SILO 宣言
• 2: 许可协议
• 3: 商标声明
• 4: 署名归属
• 5: 贡献者
• 6: 安全政策
• 7: 安全公告台账

1 - PGSTY SILO 宣言

PGSTY SILO 的存在目的：让一个可信、可维护、功能完整的 S3 兼容社区版对象存储继续存在，确保其软件供应链的持续性。

本页是项目的公开承诺，通篇遵循一项纪律：这里的每一条，要么是我们已经在做、且有公开证据的事实；要么是我们刻意拒绝承诺的事。 一个兑现不了的承诺，比没有承诺更糟。

第一条 · 存在理由与退场条款

本项目因上游收缩社区版而生：Web 控制台被削减为残桩、社区预编译制品停发、社区仓库被归档。 Silo 为既有的 MinIO 兼容部署提供延续性——Pigsty 在生产环境中以 Silo 承载 PostgreSQL 备份存储，我们自己的运维依赖着我们发布的同一批制品。

Fork 是手段，不是身份。若上游恢复对社区版的承诺，我们乐见其成，愿意收缩范围，并把我们的修复回馈给上游。

背景参考：

• MinIO已死（2025-12）——上游拿走了什么，何时拿走的。
• MinIO已死，谁能接盘？（2025-12）——备选方案的逐一评估。
• MinIO 已死，MinIO 复生（2026-02）——本 Fork 的诞生宣言。
• 续命 MinIO：承诺兑现（2026-04）——头几个月的兑现记录。

第二条 · 兼容性合同

产品与商标改名，协议与数据不改。

• S3 API、MINIO_* 环境变量、minio_* 指标、x-minio-* 头、/minio/* 路由与磁盘格式（含 .minio.sys）原样保留，并由 CI 兼容性门禁冻结。
• 每个版本在 发布说明中 标注经过测试的回滚目标与路径。
• 新增能力不触碰磁盘格式；任何例外必须在你启用它 之前 显式标记为 不可回退。
• 迁移指南（包括如何离开 Silo）与逐组件的兼容性审计公开维护。

第三条 · 许可证恒定，且是结构性的

Silo 永远是 AGPLv3。没有 CLA、不做版权聚合：贡献只接受 DCO 签署，版权保留在每位贡献者手中。 不重新授权不是一句口头承诺 —— 我们把它做成结构上的不可能。

我们对 AGPL 边界的解读，以立场而非法律意见的形式公开承诺： 通过 S3 API 使用 Silo 不会使你的应用构成衍生作品。许可证永远不会被用作威胁或销售工具。

第四条 · 改动纪律

相对上游基线的改动只限四类：安全修复、缺陷修复、恢复被移除的社区功能、可选的新增能力。 既有 API 语义只在安全修复必需时才改变，且每一处兼容性代价都记录在引发它的安全公告里。 与上游的全部分歧，以逐项核验代码的兼容性审计 形式维护。

第五条 · 永不清单

Silo 永不：

• 将既有功能移入付费墙；
• 给下载设置注册墙或登录墙；
• 加入遥测——上游的回连路径（更新检查、SUBNET、call-home）已被整体移除，而非仅仅默认关闭；
• 引入 CLA；
• 变更许可证；
• 以商标追究正常使用与描述性提及。

本清单只增不减：条目可以增补，永不删除。

第六条 · 安全纪律

• 漏洞通过私密渠道报告，可复现地分诊，协调式披露 —— 完整分析在修复版本发布前不公开。
• 每项安全修复都在 安全纪事 发布公开公告，附证据与兼容性代价。
• 依赖链 CVE 持续跟踪，任何变更前先做可达性分析。
• 每个版本附带 SHA-256 校验和、SPDX SBOM、Sigstore 签名清单与 GitHub 构建溯源。

我们对确认可远程利用的高危问题尽力加急处理，但不承诺修复时限的具体 SLA。

第七条 · 发布节奏

通常每一到两个月发布一个版本，最长不超过一个季度。安全与缺陷修复随版本集中交付。历史公开可查；请拿它来检验这条承诺。

版本 tag 沿用 RELEASE.YYYY-MM-DDTHH-MM-SSZ 格式，每个版本标注其上游基线。 功能弃用提前至少六个月公告并附迁移路径 —— 安全需要立即移除的情形除外，此时移除及其理由会在安全纪事中公开。

第八条 · 上游关系

出于对上游商标的尊重，我们改了名。上游的版权、许可证与第三方声明完整保留：署名与商标。 若上游恢复接收贡献，适用的修复将择机回馈上游。

第九条 · 延续性

• 仓库归属 pgsty 组织，而非个人账号。
• 构建过程完整文档化并附溯源证明：任何人都可以在没有我们的情况下从源码重建等价制品。
• 若项目停止积极维护超过六个月，我们将公开声明并妥善归档 —— 并尽最大努力确保已发布的制品与文档保持可用。
• 若有成熟的开源组织（例如 CNCF 这样的基金会）愿意为 Silo 引入更正规的治理，我们乐于合作。

第十条 · 商业边界

Silo 各仓库中的一切——服务端、客户端、控制台与软件制品 —— 现在完整免费，将来也完整免费。

第十一条 · 宣言自身的纪律

对本宣言的增补与加强即时生效；削弱或删除任何一条，须提前九十天公示。第五条永远只增不减。

持续更新的证据：

• 安全纪事：每一个被调查的 CVE 与修复，一事一文。
• 发布说明：每个版本的基线、回滚目标与验收记录。
• 兼容性审计：Silo 与 MinIO 何处一致，何处刻意不同。

2 - 许可协议

Silo 涉及两套彼此独立的许可协议：软件与文档的分发条款不同，各自沿用其上游作品原有的许可。

软件：AGPLv3

PGSTY SILO 是 MinIO 的分支，而 MinIO 自 2021 年起便以 GNU Affero 通用公共许可证第 3 版分发。 对于已经以该许可发布的代码，授权不可撤回——这正是本分支得以存在的法律基础。 PGSTY SILO 沿用同一许可：不重新授权、不附加限制、不做开源核心式的功能阉割。

具体而言，AGPLv3 允许你运行、研究、修改与再分发 PGSTY SILO；如果你把修改后的 PGSTY SILO 以网络服务形式提供给用户， 则必须向这些用户提供你所修改版本的对应源代码。

在依据任何摘要（包括本段）行事之前，请阅读许可证全文。

向 PGSTY SILO 贡献

四个维护中的软件仓库均按 AGPL-3.0-or-later 接收代码贡献，与各仓库自身的许可证一致。 贡献者保留原创内容的版权。SILO 不要求签署 CLA、转让版权，也不要求向 SILO 维护者或上游 MinIO 额外授予 Apache-2.0 许可。

请向负责相应组件的 PGSTY 仓库提交修改，并通过 git commit -s 签署 开发者原创声明 DCO 1.1。详见 服务端、 Console、 mcli 和 共享包 的贡献指南。

本文档的贡献沿用 CC BY 4.0。已有的版权、许可和署名声明须予以保留， 单独授权的第三方材料继续遵循其原有许可。

文档：CC BY 4.0

本站发布的全部内容依据 知识共享署名 4.0 国际许可协议（CC BY 4.0）授权， 与上游 MinIO 文档使用的许可一致。完整法律文本 以原样形式保存在文档仓库中。

你可以自由地共享与演绎本文档，包括用于商业目的，前提是给出适当的署名、提供许可协议链接， 并说明是否作出了修改。你不得附加任何法律或技术限制，去妨碍他人行使许可协议所允许的权利。

署名是唯一实质性的义务，归属与署名页面给出了可直接复制使用的署名文本， 以及完整的版权归属层次。

许可协议不涵盖什么

许可协议授予的是著作权层面的权利，它不涉及名称。获准使用 MinIO 的代码与文档， 并不等于获准使用 MinIO 商标——参见商标声明。

免责声明

两套许可协议均按“现状”提供作品，不附带任何形式的保证或条件。 完整的保证免责与责任限制条款，见 CC BY 4.0 第 5 条， 以及 AGPLv3 第 15–17 条。

参见

• 署名归属 —— 版权归属层次、衍生关系与署名方式
• 商标声明 —— MinIO 这一名称在本站的使用方式
• 安全政策 —— 如何报告安全漏洞

3 - 商标声明

项目为避免混淆所做的事

• 本分支以自己的名称 PGSTY SILO 发布，而非冒用 MinIO 之名。
• 本站每一个页面的页脚都带有商标免责声明。
• 在所有分发渠道——代码仓库、容器镜像、发行制品与本文档——均明确标注为社区分支。
• 从不宣称与 MinIO, Inc. 存在关联、认可、认证或商业合作关系。

为什么这个名字仍然出现在文档中？

许可协议授予的是著作权层面的权利，它不涉及名称。 AGPLv3 赋予任何人分支与再分发 MinIO 代码库的权利， 但商标法属于另一个领域，商标使用并不因许可协议而自动解决。

本文档内出现 MinIO 名称，用于标识本作品所衍生自的上游项目，以及那些在现实中仍沿用上游名称的对象：

• 上游项目及其历史，在署名与叙述中出现
• 通信协议、API 接口，以及 S3 兼容性说明
• 命令名、配置项、环境变量、二进制文件名与错误信息——它们属于软件兼容性契约的一部分
• 自 MinIO 文档承接而来的内容：若强行改名，文本将无法与其所描述的软件对应

其他商标

“Pigsty” 与 “PGSTY” 指 Pigsty 项目及其维护者，PGSTY SILO 由其发布。 Amazon S3 是 Amazon.com, Inc. 或其关联公司的商标，文中提及 S3 仅用于说明协议兼容性。 其余商标均归各自所有者所有。

参见

• 许可协议 —— 软件采用 AGPLv3，文档采用 CC BY 4.0
• 归属与署名 —— 本文档的版权归属层次与衍生关系

4 - 署名归属

版权

Copyright © 2020–至今 MinIO, Inc. MinIO 对象存储文档原作。

Copyright © 2026–至今 PIGSTY SILO Contributors 分支维护、格式转换、内容修改、恢复与新增的文档，以及中文翻译。

两层版权同时存在。经过翻译或修改的页面，底层表达的版权属于 MinIO，翻译与修改部分的版权属于 PGSTY SILO 项目，二者互不取代。

许可

本站所有文档内容依据 知识共享署名 4.0 国际许可协议（CC BY 4.0）授权， 与上游原作使用同一许可证。完整法律文本见 LICENSE。 PGSTY SILO 软件本身另行授权，参见许可协议。

衍系

本文档的部分内容衍生自 MinIO 对象存储文档，相对原作，本文档已进行若干修改： 更名为 Silo、恢复上游已移除功能的文档、将冻结的 RST/MyST 源码转换为双语 Markdown、 以 Hugo 与 Docsy 替换 Sphinx 呈现层、修复链接与构建问题、持续维护，以及翻译为中文。完整的变更记录见提交历史。

并非所有页面都衍生自 MinIO。博客、下载与发行页面、本节内容，以及 Silo 专属内容， 均为 Silo 项目的原创作品。凡包含上游素材的页面，都会在页面底部标注来源； 被 Silo 修改过（超出格式转换范围）的页面，还会给出该页自身的修改历史链接。

翻译

中文翻译由 Silo 项目维护，属于非官方翻译，与 MinIO, Inc. 无关。 如中文译文与英文原文有出入，以英文原文为准。

署名

如果你复用本站内容，按下面这样署名即可满足 CC BY 4.0 的要求：

[PGSTY SILO 文档](https://silo.pgsty.com/zh)，作者 PGSTY 与 MinIO. Inc，依据 CC BY 4.0 授权。

英文场景可使用：

[PGSTY SILO Documentation](https://silo.pgsty.com) by PGSTY and MinIO. Inc, licensed under CC BY 4.0.

声明

除许可人另行承诺外，在法律允许的范围内，许可人按“现状”与“现有”方式提供许可材料， 不就许可材料作出任何明示、默示、法定或其他形式的陈述或保证。 完整的保证免责与责任限制条款见 许可证第 5 条。

参见

• 许可协议 —— 软件采用 AGPLv3，文档采用 CC BY 4.0
• 商标声明 —— MinIO 这一名称在本站的使用方式

5 - 贡献者

截至 2026-09-16，SILO 及相关项目共有 50 位社区贡献者，包括维护者、公开 issue / PR 作者，以及已公开致谢的安全披露者。

只要提交过 issue 或 PR，无论开启、关闭、草稿或未合并，均予以认可。同一账号只计一次。排序先列已合并 PR 的作者，再列其他 PR 作者和问题报告者；每组优先展示重要修复、已采纳方案和推动修复的报告，其余按首次参与时间排列。金色圆环突出显著贡献。

原 PR 未合并但工作被后续修复吸收时，会单独列出采纳记录；关闭 issue 不等于问题已修复，代码合入也不等于已发布。自动化账号不计入人数。上游作者的署名继续保留在 Git 历史与版权声明中。

已合并 PR 的贡献者

其他 PR 贡献

问题报告与安全披露

统计范围

以下统计来自全部分页的 GitHub issue / PR 记录，包含所有状态和自动化账号。 去重后有 49 位公开 issue / PR 作者，另保留 1 位安全披露者。排除的自动化账号：Copilot, dependabot[bot]。

维护者记录

名单来源：SILO CONTRIBUTORS.md · GitHub data. 如有遗漏或描述不准确，欢迎提交 issue 或 PR。

6 - 安全政策

当前发布边界： 最新 Server 20260903 仍受 SN-2026-011 影响，修复已在 main。客户端/pkg 发布与 Server 修复发布是独立事项，见组件矩阵。

安全维护正是这个分支存在的理由。上游 minio/minio 已经归档，Silo 持续跟踪针对该代码库的 CVE， 回合并或自行编写修复，并把调查过程公之于众。

报告安全漏洞

未公开披露的高危漏洞请通过私密渠道报告，不要发在公开 issue 里。

• Silo 服务端与 mcli 客户端 —— 建议通过 pgsty/silo 的 GitHub Security Advisories 提交私密报告。
• 本文档 —— 请在 pgsty/silo.pgsty.com 提交 issue；如果内容本身披露了某个弱点，请改用私密渠道。

请注明受影响的版本、影响描述，以及复现步骤（如果有），这将帮助我们更快地确认问题。

我们将尽努力在合理时间内回复，但请注意 Silo 是社区项目，我们不承诺任何修复 SLA 与响应时效。

上游 MinIO 的漏洞

Silo 是分支，因此绝大多数发现同样适用于 minio/minio。 上游仓库已归档，不再接收报告——这恰恰是本项目要填补的空缺。 请向 Silo 报告；如果问题影响同一份代码的其他发行版，本项目会与它们协调披露。

修复在哪里公布

• 安全公告台账 —— 每个 CVE 与 fork 本地 SN- 编号的稳定索引：修复提交、受影响面、可利用性、发布边界与依赖安全更新。

• 安全注记 —— 每个调查过的 CVE 一篇文章：原始威胁模型、评审过程中的反复、被否决的备选方案、最终确立的不变量、验证证据，以及兼容性代价。

• 发布说明 —— 每个修复首次随哪个版本发布并公开可用。

加固你自己的部署

报告只是一半，配置是另一半。部署加固参见安全检查清单， TLS 配置参见网络加密。

参见

• 许可协议 —— 软件按“现状”提供，不附带任何形式的保证
• 归属与署名 —— 本文档的版权归属与衍生关系

7 - 安全公告台账

本台账汇总 pgsty/silo 的 fork 专属安全修复及密切相关的升级影响说明。它有意比 changelog 更窄，只关注影响发布的安全行为。每个经过完整调查的公告在安全编年史另有独立文章；本页是编号、修复与发布边界的稳定索引。

条目在有 CVE 编号时使用 CVE。没有 CVE 的发现使用 fork 本地 SN-<年份>-<序号> 编号，使其仍能被发布说明、提交与 issue 稳定引用。SN- 编号不是 CVE，也未登记到任何漏洞数据库；它刻意不写成 CVE 形式，避免被扫描器误认。上游 minio/minio 已归档，继承代码中的发现没有上游维护者可以协调 CVE 分配。SN-2026-001 是 trackingResponseWriter 的流式刷新回归，属于可靠性缺陷而非安全问题，记录在发布说明而非本页。

当前发布边界

核验于 2026-09-16。 最新已发布 Server 为 RELEASE.2026-09-03T13-18-01Z。 SN-2026-011 已在 main 修复，但该版本及之前所有公开 Server 版本仍受影响。升级 mcli、pkg 或独立 Console 不会修补已安装的 Server。源码钉定见组件版本矩阵。

继承自上游的公告基线

Silo 首个社区版本切自已包含以下安全修复的上游历史。上游与 Silo 链接同时记录——即使 fork 保留了同一提交对象与 SHA；该同一性是继承证据，不表示 Silo 独立重新实现了补丁。

RELEASE.2026-03-21T00-00-00Z 之后的公告

各条目的升级与兼容性说明如下。有编年史文章的条目在此只做摘要；威胁模型、被否决方案与验证细节请 follow 链接。

CVE-2026-33322 — OIDC STS JWT 算法混淆

可远程利用。移除 HMAC/共享密钥验证并强制 JWKS 支持的验证密钥，关闭 JWT 算法混淆。破坏性变更： 为这些 STS 流程签发 HS256/HS384/HS512 令牌的提供方必须在升级前切换到 JWKS 支持的 RSA 或 ECDSA 签名。PS256 与 EdDSA 暂不支持。

CVE-2026-33419 — LDAP STS 用户名枚举

可远程利用。统一未知用户与错误密码的响应（均返回 400 InvalidParameterValue）并增加内存登录限流，关闭用户名枚举。六月最终方案只保留来源 IP 限流，移除了可被攻击者用来锁死特定账户的共享用户名桶。限流状态按节点保存在内存中，来源地址信任策略可单独配置。各轮修复见 LDAP STS 编年史。

CVE-2026-34204 — 复制元数据注入

可远程利用。阻止不可信的 X-Minio-Replication-* 头被偷渡进内部复制元数据并导致对象不可读。任何接受不可信 PutObject/CopyObject 请求的服务器都应升级——实践中即几乎所有接受写入的生产服务器。

CVE-2026-39414 — S3 Select 超大记录

可远程利用。对超大 CSV 与行分隔 JSON 记录返回 OverMaxRecordSize，而非无界缓冲。四月修复最初遗漏了 SIMD JSON 路径；六月后续修复让所有 JSON Lines 走有界的 json.PReader，关闭了该绕过。详见 S3 Select 编年史。

CVE-2026-41145 — unsigned-trailer 认证绕过

可远程利用。关闭 unsigned-trailer 流式请求中的查询串认证绕过。若客户端能以 STREAMING-UNSIGNED-PAYLOAD-TRAILER content-sha256 模式加查询串 SigV4 凭据到达对象写入端点，应升级。

CVE-2026-40344 — Snowball 自动解包认证

可远程利用。在 Snowball unsigned-trailer 流程中先验证请求认证再解包 tar。使用 PutObjectExtract 或 Snowball 上传的用户应升级。

CVE-2026-42600 — 内部节点 ReadMultiple 路径穿越

可远程利用；需 cluster-root JWT。移除允许路径穿越到盘根之外的未使用端点。分布式纠删部署应升级；单节点部署不注册此路由。

SN-2026-002 — 内部节点载荷遏制

可远程利用；需 cluster-root / 内部节点 JWT。补完 CVE-2026-42600：该修复只移除了触发缺口的一个端点；缺口本身——请求体与 grid 帧从未到达有效性中间件、存储层无遏制——仍存在于另外三个协议面。在卷与路径两轴上关闭路径穿越（包括完全绕过 storage-REST 包装的 peer-S3 桶 RPC）、一个每帧杀死节点的不可恢复除零、把截断分片报为完整的元数据，以及三个按调用方声明值定大小的分配。分布式纠删部署应升级；单节点部署不注册这些路由。S3 API 行为无变化；含 . 或 .. 路径段的对象键本已在 S3 边界拒绝。

SN-2026-003 — 策略条件值来源

可利用性取决于策略。阻止原始请求条目拼写出条件键名从而遮蔽或伪造内部条件值；将 s3:signatureAge 限定于已验证的 SigV4 预签名请求；把仅查询串的列表字段与来自头的 x-amz-* 字段分离；阻止客户端请求标签冒充已存储的对象标签。兼容的查询串形式在消费它的 handler 上对存储类与上传标签仍然保留；显式出现的头优先，包括空头。请求标签条件只应用于消费标签的操作。仅头的 x-amz-* 策略键不再接受查询串替代。见条件值来源与优先级。

客户端源地址信任 — 主动加固，非漏洞

修复于 fe6dc4780；未分配 CVE（默认行为与上游一致，且上游立场是：没有可靠的源 IP 可见性，基于 IP 的限制不可实施）。新增可执行的转发头信任边界 MINIO_API_TRUSTED_PROXIES。设为地址或 CIDR 列表时，只相信来自这些 peer 的转发头，并从右向左越过已列出的跳数读取转发链——同时挡住追加型代理留下的客户端可写最左项。设为 none 时完全不相信任何转发头。这是 _MINIO_API_XFF_HEADER=off 从未提供过的保证。对既有部署无任何行为变化；该变量为可选，未设置时不起作用。若使用 IpAddress/NotIpAddress 条件，注意它们在此变更之前不可执行；运维契约——包括允许列表为何必须列代理而非子网、多节点部署为何必须包含自身节点地址——见编年史文章与设置参考。

SN-2026-004 — 对象授权触达桶动作

可利用性取决于策略。把十二个敏感桶级写入从对象形式资源模式（arn:aws:s3:::bucket/*）中扣留：PutBucketPolicy、DeleteBucketPolicy、PutBucketObjectLockConfiguration、PutBucketVersioning、PutReplicationConfiguration、PutBucketLifecycle、DeleteBucket、ForceDeleteBucket、PutBucketCors、DeleteBucketCors、PutBucketQOS、PutInventoryConfiguration。这是授权收紧；自写桶域策略的用户升级前请读编年史文章。 在合法授予上述动作之一的语句中，把裸桶 ARN（arn:aws:s3:::bucket）与通配形式并列添加。内置 canned 策略不受影响；Deny 语句与 NotResource 排除不动。MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on 可完整恢复历史行为，启动时读取一次。

SN-2026-005 — 裸 ARN 前缀拒绝

无直接远程利用；取决于策略。在创建具名策略与创建/更新服务账号会话策略时，拒绝不指向任何资源的 S3、S3 Tables 与 KMS ARN 命名空间前缀（含历史 *arn:... 序列化），Resource 与 NotResource 均适用。既有策略的加载、匹配、导入与复制行为不变，但含此类前缀的策略无法原样再次提交；请替换为具体资源，或在确实指全部资源时使用显式通配如 arn:aws:s3:::*。“裸 ARN 前缀”（arn:aws:s3:::）不同于 SN-2026-004 中合法的“裸桶 ARN”（arn:aws:s3:::bucket）。IAM 导入、站点复制接收路径、已存策略加载与 STS 内联策略在本版本仍走宽松兼容路径。见 pkg v3.12.0 发布说明。

SN-2026-006 — SSE-C 零字节读取

可远程利用；需对象读权限。零字节 SSE-C 对象从不解封客户提供的密钥，错误密钥会以 200 而非 403 被接受，并可在不知当前密钥的情况下以调用方选择的密钥创建副本或新版本。现在错误密钥与 AWS 一致返回 403 AccessDenied；正确密钥行为不变，客户端无需改动。继承自上游；更早版本均受影响。

SN-2026-007 — SSE-C 对象的 GetObjectAttributes

可远程利用；需对象读权限。SSE-C 对象的属性在返回时未认证客户密钥，且单独一个 X-Minio-Source-Replication-Request 头即可完全跳过检查。现在错误密钥返回 403，无密钥的复制标记返回 400；持有 s3:ReplicateObject 的复制对端不受影响。继承自上游。

SN-2026-008 — 内部复制请求头

可远程利用；任何能读写该对象的已认证主体。补完 CVE-2026-34204：X-Minio-Source-Etag、X-Minio-Source-Mtime、X-Minio-Source-Replication-Request、复制 SSE 密钥头与对象读写上的 X-Amz-Bucket-Replication-Status 在多数 handler 中仍按“存在即信任”处理。现在复制语义要求精确标记值与 s3:ReplicateObject 或 s3:ReplicateDelete 同时成立；其他请求的这些头在签名验证后被移除。已持有复制权限的站点复制服务账号与桶复制目标不受影响。继承自上游。

SN-2026-009 — 用户/组状态授权

可远程利用；已认证 admin API。状态变更无论目标状态如何都按 admin:EnableUser/admin:EnableGroup 授权，只被允许 enable 的主体也能 disable，反之亦然。现在启用与禁用要求与目标状态匹配的动作。只授予二者之一的策略失去另一操作；admin:* 与内置 consoleAdmin 策略不受影响。继承自上游。

SN-2026-010 — 显式版本删除授权

可远程利用；已认证 S3 API。显式版本删除此前按 s3:DeleteObject 授权，仅对 s3:DeleteObjectVersion 做拒绝检查，与 AWS 不一致。现在显式版本删除要求 s3:DeleteObjectVersion。两个策略影响： 只被授予 s3:DeleteObject 的主体不能再删除特定版本；依赖 Deny s3:DeleteObject 阻止永久删除的策略必须同时 deny s3:DeleteObjectVersion，因为 Allow s3:* 现在允许显式版本删除。复制目标保持 s3:ReplicateDelete 契约。继承自上游。

SN-2026-011 — 未签名 x-amz-* 头与 x-amz-copy-source

可远程利用；只持有一个预签名 PUT URL 或任意已签名 PUT 的方无需自有凭据。SigV4 验证只检查每个被命名签名头是否存在，从不检查实际到达的 x-amz-* 头，而路由把任何携带 x-amz-copy-source 的 PUT 分发给 CopyObjectHandler。未签名的 x-amz-copy-source 因此把单对象写授权变成以签名者身份执行的服务端复制，可复制签名密钥能读到的任意对象；预签名与 Authorization 头两条路径均受影响，且当目的桶允许匿名 GetObject 时，被复制的私有字节可被匿名读取。现在两条路径上任何未签名的 x-amz-* 请求头都会被以 AccessDenied 拒绝，与 AWS S3 对齐（AWS 返回 403；Silo 返回 400 AccessDenied，其余一致）。所有 AWS SDK、minio-go 与 mc 本就签名其 x-amz-* 头，合法客户端无需改动。原样继承自上游 minio/minio；包括最新已发布 Server 20260903 在内的更早版本均受影响。报告人 Oren Yomtov；CVE 已申请。见编年史文章与签名头设计记录。

依赖安全更新

各行列出吸收的修复与首个携带它的提交或发布。可达性与部署暴露面仍需按发布单独判断：吸收了依赖修复不等于该漏洞在 Silo 中可达。

运维相关的安全修复

台账归属

本页由仓库内原 docs/security/advisories.md 台账维护而来，更新至已核验的 main 40220bd836cb（2026-09-16）。发布状态表述与组件版本矩阵对齐；每个修复的调查、评审与验证细节见链接的编年史文章或发布说明。