About PGSTY Silo

• 1: The PGSTY SILO Manifesto
• 2: License
• 3: Trademark Notice
• 4: Attribution
• 5: Contributors
• 6: Security Policy
• 7: Security Advisories

1 - The PGSTY SILO Manifesto

PGSTY SILO keeps an open-source, feature-complete, S3-compatible object store maintained and installable, with a build and release chain anyone can inspect. That is the whole scope.

This page is the project’s public commitment, and it follows one rule: every article below is either something we already do, with public evidence, or something we explicitly refuse to promise. A promise we could not keep would be worse than no promise.

Article 1 · Reason to exist, and an exit clause

This project started when upstream wound down its community edition: the web console was cut back to a stub, prebuilt community binaries stopped, and the community repository was archived. Silo keeps existing MinIO-compatible deployments running. Pigsty runs it in production as its PostgreSQL backup storage, so our own operations depend on the artifacts we publish.

The fork is a means, not an identity. If upstream restores its community edition, we will narrow our scope and offer our fixes back.

Background:

• MinIO is Dead (2025-12) — what upstream removed, and when.
• MinIO Is Dead. Which Next? (2025-12) — the alternatives, evaluated.
• MinIO Is Dead, Long Live MinIO (2026-02) — the fork, announced.
• MinIO Fork, Promise Kept (2026-04) — the first months of receipts.

Article 2 · The compatibility contract

The product and its trademark are renamed; the protocol and your data are not.

• The S3 API, MINIO_* environment variables, minio_* metrics, x-minio-* headers, /minio/* routes, and the on-disk format (including .minio.sys) are preserved, and held in place by a CI compatibility check.
• Every release documents its tested rollback target and path in the release notes.
• New capabilities do not touch the on-disk format. Any exception must be explicitly marked as non-reversible before you can enable it.
• The migration guide, which includes how to leave Silo, and the per-component compatibility audits are public and maintained.

Article 3 · The license cannot change

Silo is AGPLv3. There is no CLA and no copyright aggregation: contributions are accepted only with DCO sign-off, so copyright stays with each contributor. That is not a verbal promise not to relicense. It means nobody here, ourselves included, holds enough copyright to relicense the project on everyone else’s behalf.

Our reading of the AGPL boundary is a position, not legal advice: using Silo through its S3 API does not make your application a derivative work. We will not use the license as a threat or a sales instrument.

Article 4 · Change discipline

Changes relative to the upstream baseline fall into four classes only: security fixes, defect fixes, restored community features, and optional additions. Existing API semantics change only when a security fix demands it, and every such compatibility cost is recorded in the advisory that caused it. Every divergence from upstream is listed in the code-verified compatibility audit.

Article 5 · The never list

Silo will never:

• move an existing feature behind a paywall;
• put a registration or login wall in front of downloads;
• ship telemetry — the upstream phone-home paths (update checks, SUBNET, call-home) are removed outright, not merely disabled;
• require a CLA;
• change the license;
• use trademarks against normal use or descriptive mention.

This list is append-only: entries may be added, never removed.

Article 6 · Security discipline

• Vulnerabilities are reported through a private channel and triaged reproducibly. Writeups are held until the fixed release ships.
• Every security fix ships with a public advisory, including its evidence and its compatibility cost.
• Dependencies are tracked for CVEs, with reachability analysis before any change.
• Every release ships SHA-256 checksums, SPDX SBOMs, Sigstore-signed manifests, and GitHub build provenance.

Severe, remotely exploitable issues are expedited on a best-effort basis, but we do not commit to a specific fix-time SLA.

Article 7 · Release cadence

Releases ship typically every one to two months, and at most a quarter apart. Security and defect fixes are batched into these releases. The history is public; judge the promise against it.

Version tags keep the RELEASE.YYYY-MM-DDTHH-MM-SSZ format, and each release documents its upstream baseline. Deprecations get at least six months’ notice and a migration path. The exception is a removal that security requires immediately; the removal and its justification are then published in the security advisories.

Article 8 · Upstream relations

We renamed the project out of respect for upstream’s trademarks. Upstream copyright, license, and third-party notices are preserved in full: attribution and trademark. If upstream resumes accepting contributions, applicable fixes will be offered back as appropriate.

Article 9 · Continuity

• The repositories live under the pgsty organization, not a personal account.
• The build is documented and provenance-attested: anyone can rebuild equivalent artifacts from source without us.
• If active maintenance stops for six months, we will say so publicly and archive the project rather than let it go quiet. Released artifacts and documentation stay up as long as we can keep them up.
• If an established open-source organization (a CNCF-style foundation, say) wanted to bring Silo under more formal governance, we would cooperate.

Article 10 · The commercial boundary

Everything in the Silo repositories is complete and free of charge: the server, the client, the console, and the released artifacts. That does not change.

Article 11 · Amendment discipline

Additions and strengthenings of this manifesto take effect immediately. Weakening or removing any article requires ninety days’ public notice. Article 5 is append-only, always.

Where to check:

• Security advisories: every CVE investigated and fixed, one article per incident.
• Release notes: every release, with its baseline, rollback target, and acceptance record.
• Compatibility audits: where Silo matches MinIO, and where it deliberately differs.

2 - License

Silo carries two separate licenses. The software and the documentation are distributed under different terms, and each inherits the license its upstream work already used.

Software: AGPLv3

PGSTY SILO is a fork of MinIO, which has been distributed under the GNU Affero General Public License v3.0 since 2021. That license is irrevocable for code already released under it — the legal basis on which this fork exists. PGSTY SILO keeps the same license: no relicensing, no added restrictions, no open-core carve-outs.

In practice, AGPLv3 lets you run, study, modify, and redistribute PGSTY SILO; if you offer a modified PGSTY SILO to users over a network, you must offer those users the corresponding source of your modified version.

Read the full license text before acting on any summary, including this one.

Contributions to PGSTY SILO

Code contributions to all four maintained software repositories use AGPL-3.0-or-later, the same license as each repository. Contributors retain copyright in their original work. SILO requires no CLA, copyright assignment, or separate Apache-2.0 license grant to its maintainers or to upstream MinIO.

Submit changes to the PGSTY repository that owns them and sign commits with git commit -s to certify the Developer Certificate of Origin 1.1. See the contribution guides for the server, Console, mcli, and shared packages.

Contributions to this documentation follow CC BY 4.0. Existing copyright, license, and attribution notices remain in place, including the original terms of separately licensed third-party material.

Documentation: CC BY 4.0

Everything published on this site is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0) — the same license the upstream MinIO documentation used. The full legal text is reproduced verbatim in the documentation repository.

You are free to share and adapt this documentation, including commercially, provided you give appropriate credit, link to the license, and indicate whether changes were made. You may not impose legal or technological measures that restrict others from doing anything the license permits.

Attribution is the only substantive obligation; Attribution gives you a ready-to-copy credit line along with the full copyright stack.

What the license does not cover

A license grants rights in copyright. It says nothing about names. Permission to use the MinIO codebase and documentation is not permission to use the MinIO trademark — see the Trademark Notice.

Disclaimer

Both licenses provide the work as-is, without warranties or conditions of any kind. See Section 5 of CC BY 4.0 and Sections 15–17 of AGPLv3 for the complete disclaimers of warranty and limitations of liability.

See also

• Attribution — copyright stack, derivation, and how to credit this documentation
• Trademark Notice — how the MinIO name is used here
• Security Policy — how to report a vulnerability

3 - Trademark Notice

What the project does to avoid confusion

• The fork is published under its own name, PGSTY SILO, not under MinIO’s.
• Every page of this site carries a trademark disclaimer in the footer.
• It is labeled a community fork across every distribution channel — repositories, container images, release artifacts, and this documentation.
• No claim of affiliation, endorsement, certification, or commercial relationship with MinIO, Inc. is ever made.

Why the name still appears in this documentation

A license grants rights in copyright; it says nothing about names. AGPLv3 gives anyone the right to fork and redistribute the MinIO codebase, but trademark law is a separate matter that a license does not settle.

The MinIO name appears in this documentation to identify the upstream project this work derives from, and to name the things that still carry the upstream name in practice:

• the upstream project and its history, in attribution and in prose
• the wire protocol, API surface, and S3 compatibility statements
• command names, configuration keys, environment variables, binary names, and error strings — part of the software’s compatibility contract
• content carried over from the MinIO documentation, where renaming would break the correspondence between the text and the software it describes

Other marks

“Pigsty” and “PGSTY” refer to the Pigsty project and its maintainers, who publish PGSTY SILO. Amazon S3 is a trademark of Amazon.com, Inc. or its affiliates; references to S3 describe protocol compatibility only. All other trademarks are the property of their respective owners.

See also

• License — AGPLv3 for the software, CC BY 4.0 for this documentation
• Attribution — copyright stack and derivation of this documentation

4 - Attribution

Copyright

Copyright © 2020–Present MinIO, Inc. Original MinIO Object Storage Documentation.

Copyright © 2026–Present PIGSTY & SILO Contributors Fork maintenance, format conversion, modifications, restored and newly written content, and Simplified Chinese translation.

Both layers apply at once. A translated or modified page carries MinIO’s copyright in the underlying expression and the PGSTY SILO project’s copyright in the translation and the changes; neither replaces the other.

License

All documentation content on this site is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0) — the same license as the upstream work. The full legal text is in LICENSE. The PGSTY SILO software itself is licensed separately; see License.

Derivation

Portions of this documentation are derived from the MinIO Object Storage Documentation. The work has been modified from the original: rebranding to PGSTY SILO, restoration of documentation for features removed upstream, conversion of the frozen RST/MyST source to bilingual Markdown, replacement of the Sphinx presentation layer with Hugo and Docsy, link and build fixes, ongoing maintenance, and translation into Chinese. The commit history is the complete record of changes.

Not every page is derived from MinIO. The blog, download and release pages, this section, and PGSTY SILO-specific content are original works of the PGSTY SILO project. Pages that do carry upstream material say so in a notice at the bottom of the page, and pages that PGSTY SILO has changed beyond the format conversion link to their own change history.

Translation

Chinese translations are unofficial and are maintained by the PGSTY SILO project, not by MinIO, Inc. Where a translation and the original English text differ, the English text is authoritative.

How to attribute

If you reuse content from this site, the following credit line satisfies CC BY 4.0:

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

For Chinese-language contexts:

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

Disclaimer

Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. See Section 5 of the license for the complete disclaimer of warranties and limitation of liability.

See also

• License — AGPLv3 for the software, CC BY 4.0 for this documentation
• Trademark Notice — how the MinIO name is used here

5 - Contributors

As of 2026-09-16, 50 community contributors are credited in SILO and related projects. The roll includes maintainers and every human issue / PR author, plus the previously acknowledged security disclosure.

Opening an issue or PR counts, whether open, closed, draft, or unmerged. Each account appears once. Merged PR authors come first, followed by other PR authors and reporters. Within each group, significant fixes, adopted proposals, and reports that led to fixes take priority, followed by first participation. Gold rings highlight significant contributions.

When a proposal was incorporated through a later repair, its adoption is credited separately from the original PR status. A closed issue does not necessarily mean a fix, and merged source does not imply a published release. Automated accounts are excluded. Upstream authorship remains in Git history and copyright notices.

Merged pull requests

Other pull-request authors

Issue reports

Audit scope

Counts below come from every page of the GitHub issue / PR records, across all states, including automated accounts. There are 49 distinct human public issue / PR authors, plus 1 credited security reporter. Excluded automated accounts: Copilot, dependabot[bot].

Maintainer record

Record source: SILO CONTRIBUTORS.md · GitHub data. Please open an issue or PR to correct missing or inaccurate credit.

6 - Security Policy

Current release boundary: latest Server 20260903 remains affected by SN-2026-011, fixed on main. A client/pkg release is separate from publication of a fixed Server; see the component matrix.

Security maintenance is the reason this fork exists. Upstream minio/minio is archived; Silo tracks CVEs against the codebase, backports or writes the fixes, and publishes what it found.

Reporting a vulnerability

Report undisclosed high-severity vulnerabilities through a private channel, not in a public issue.

• Silo server and mcli client — preferably as a private report through GitHub Security Advisories on pgsty/silo.
• This documentation — open an issue on pgsty/silo.pgsty.com; if the content itself discloses a weakness, use a private channel instead.

Include the affected release, a description of the impact, and reproduction steps if you have them — this helps us confirm the issue faster.

We will do our best to respond within a reasonable time, but note that Silo is a community project: we promise no fix SLA and no guaranteed response time.

Vulnerabilities in upstream MinIO

Silo is a fork, so the vast majority of findings apply to minio/minio as well. The upstream repository is archived and no longer accepts reports — precisely the gap this project fills. Report to Silo; where an issue affects other distributions of the same code, the project coordinates disclosure with them.

Where fixes are published

• Advisory Ledger — the stable index of every CVE and fork-local SN- identifier: the fix commit, affected area, exploitability, release boundary, and dependency security updates.

• Security Chronicle — one article per investigated CVE: the original threat model, the back-and-forth of the review, the rejected alternatives, the invariant finally settled on, the verifying evidence, and the compatibility cost.

• Release Notes — the release each fix first shipped in and became publicly available.

Hardening your own deployment

Reporting is one half; configuration is the other. See the security checklist for deployment hardening, and network encryption for TLS setup.

See also

• License — the software is provided as-is, without warranty of any kind
• Attribution — copyright and derivation of this documentation

7 - Security Advisories

This ledger summarizes fork-specific security fixes and closely related upgrade-impacting security notes in pgsty/silo. It is intentionally narrower than a changelog and focuses on release-impacting security behavior. Each advisory with its own investigation also has an article in the Security Chronicle; this page is the stable index of identifiers, fixes, and release boundaries.

Entries carry a CVE identifier where one exists. Where none does, they carry a fork-local SN-<year>-<sequence> identifier so that a finding without a CVE can still be referenced stably from release notes, commits and issues. An SN- identifier is not a CVE and is not registered in any vulnerability database; it is deliberately not written in CVE form so that scanners do not mistake it for one. Upstream minio/minio is archived, so for findings in inherited code there is no upstream maintainer to coordinate a CVE assignment with. SN-2026-001 is the streaming-flush regression in trackingResponseWriter, which is a reliability defect rather than a security one and is tracked in the release notes rather than here.

Current release boundary

Verified 2026-09-16. The latest published Server is RELEASE.2026-09-03T13-18-01Z. SN-2026-011 is fixed on main but remains present in that release and all earlier public Server releases. A newer mcli, pkg or standalone Console does not patch an installed Server. See the component matrix for source pins.

Inherited upstream advisory baseline

The first Silo community release was cut from upstream history that already contained the following security fix. Upstream and Silo links are both recorded even when the fork preserves the same commit object and SHA; that identity is the inheritance evidence, not a claim that Silo independently reimplemented the patch.

Advisories since RELEASE.2026-03-21T00-00-00Z

Upgrade and compatibility notes for each entry follow. Entries whose full investigation is told in a chronicle article are summarized here; follow the link for the threat model, rejected alternatives, and verification.

CVE-2026-33322 — OIDC STS JWT algorithm confusion

Remote exploitation: yes. Closes JWT algorithm confusion by removing HMAC/shared-secret verification and requiring JWKS-backed verifier keys. Breaking change: providers issuing HS256, HS384, or HS512 tokens for these STS flows must switch to JWKS-backed RSA or ECDSA signing before upgrading. PS256 and EdDSA are not currently supported.

CVE-2026-33419 — LDAP STS username enumeration

Remote exploitation: yes. Prevents username enumeration by unifying unknown-user and bad-password responses (both now 400 InvalidParameterValue) and adds in-memory login throttling. The final June design limits by source IP only; it removed the shared username bucket because attackers could use it to lock out a specific account. Limits are per-node and in-memory; the source address trust policy is configurable separately. See the LDAP STS chronicle for the successive repairs.

CVE-2026-34204 — replication metadata injection

Remote exploitation: yes. Blocks untrusted X-Minio-Replication-* headers from being smuggled into internal replication metadata and leaving objects unreadable. Upgrade any server that accepts untrusted PutObject or CopyObject requests, which in practice means almost any production server that accepts writes.

CVE-2026-39414 — S3 Select oversized records

Remote exploitation: yes. Rejects oversized CSV and line-delimited JSON records with OverMaxRecordSize instead of buffering them unchecked. The April fix initially missed the SIMD JSON path; the June follow-up routes all JSON Lines through the bounded json.PReader, closing that bypass. See the S3 Select chronicle.

CVE-2026-41145 — unsigned-trailer authentication bypass

Remote exploitation: yes. Closes the query-string authentication bypass in unsigned-trailer streaming requests. Upgrade if clients can reach object write endpoints using the STREAMING-UNSIGNED-PAYLOAD-TRAILER content-sha256 mode together with query-string SigV4 credentials.

CVE-2026-40344 — Snowball auto-extract authentication

Remote exploitation: yes. Verifies request authentication before tar extraction in Snowball unsigned-trailer flows. Upgrade if you use PutObjectExtract or Snowball uploads.

CVE-2026-42600 — internode ReadMultiple path traversal

Remote exploitation: yes; cluster-root JWT required. Removes the unused endpoint that allowed path traversal outside configured drive roots. Upgrade distributed-erasure deployments. Single-node deployments do not register this route.

SN-2026-002 — internode payload containment

Remote exploitation: yes; cluster-root / internode JWT required. Completes CVE-2026-42600: its fix removed one endpoint that exercised the gap; the gap itself — request bodies and grid frames never reaching the validity middleware, and no containment in the storage layer — remained across three further protocol surfaces. Closes path traversal on both the volume and path axes (including the peer-S3 bucket RPCs, which bypass the storage-REST wrapper entirely), an unrecoverable divide-by-zero that killed a node per RPC frame, metadata that reported truncated shards as intact, and three allocations sized from caller-declared values. Upgrade distributed-erasure deployments; single-node deployments register none of these routes. No S3 API behaviour changes; object keys containing . or .. path segments were already refused at the S3 boundary.

SN-2026-003 — policy condition value sources

Remote exploitation: yes (policy-dependent). Prevents raw request entries that spell condition-key names from shadowing or synthesizing internal condition values; confines s3:signatureAge to verified SigV4 presigned requests; separates query-only list fields from header-backed x-amz-* fields; and stops client request tags from impersonating stored existing-object tags. The compatible query form remains for storage class and upload tagging on handlers that consume it; an explicitly present header wins, including an empty header. Use request-tag conditions only on operations that consume tags. Header-only x-amz-* policy keys no longer accept query substitutes. See condition value sources and precedence.

Client source address trust — opt-in hardening, not a vulnerability

Fixed by fe6dc4780; no CVE assigned (the default matches upstream, and upstream’s own position is that IP-based restrictions are impractical without reliable source-IP visibility). Adds an enforceable forwarded-header trust boundary, MINIO_API_TRUSTED_PROXIES. Set to a list of addresses or CIDR blocks, forwarded headers are believed only from those peers and forwarding chains are read right-to-left past listed hops — which also stops the client-supplied left-most entry that an appending proxy leaves in place. Set to none, no forwarded header is believed at all. This is the guarantee _MINIO_API_XFF_HEADER=off never provided. No behaviour change for any existing deployment; the variable is opt-in and inert when unset. If you use IpAddress or NotIpAddress conditions, note that they were not enforceable before this change; the operator contract — including why the allowlist must name proxies rather than subnets and why multi-node deployments must include their own node addresses — is in the chronicle article and the settings reference.

SN-2026-004 — object-grant bucket reach

Remote exploitation: yes (policy-dependent). Withholds twelve sensitive bucket-level writes from an object-only resource pattern (arn:aws:s3:::bucket/*): PutBucketPolicy, DeleteBucketPolicy, PutBucketObjectLockConfiguration, PutBucketVersioning, PutReplicationConfiguration, PutBucketLifecycle, DeleteBucket, ForceDeleteBucket, PutBucketCors, DeleteBucketCors, PutBucketQOS, PutInventoryConfiguration. This is an authorization tightening; read the chronicle article before upgrading if you write your own bucket-scoped policies. Add the bare bucket ARN (arn:aws:s3:::bucket) alongside the wildcard form in any statement that legitimately grants one of the twelve. Built-in canned policies are unaffected; Deny statements and NotResource exclusions are untouched. MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on restores the historical behaviour in full; it is read once at startup.

SN-2026-005 — bare ARN prefix rejection

No direct remote exploit; policy-dependent. Rejects S3, S3 Tables, and KMS ARN namespace prefixes that name no resource, including their historical *arn:... serialization, in both Resource and NotResource, when creating named policies and when creating or updating service-account session policies. Existing policies keep loading, matching, importing, and replicating with unchanged runtime behavior, but a policy containing such a prefix cannot be submitted unchanged; replace it with the intended concrete resource, or use an explicit wildcard such as arn:aws:s3:::* only when all resources are intended. A “bare ARN prefix” (arn:aws:s3:::) is distinct from the valid “bare bucket ARN” of SN-2026-004 (arn:aws:s3:::bucket). IAM import, site-replication receive paths, stored-policy loading, and STS inline policies remain on the permissive compatibility path in this release. See the pkg v3.12.0 release note.

SN-2026-006 — SSE-C zero-byte reads

Remote exploitation: yes; requires read access to the object. Zero-byte SSE-C objects never unsealed the customer-provided key, so a wrong key was accepted with 200 instead of 403, and a copy or new version could be created under a key of the caller’s choosing without knowing the current one. Wrong keys now fail with 403 AccessDenied as on AWS; correct keys behave as before and no client change is needed. Inherited from upstream; every earlier release is affected.

SN-2026-007 — GetObjectAttributes on SSE-C objects

Remote exploitation: yes; requires read access to the object. Attributes of SSE-C objects were returned without authenticating the customer key, and a bare X-Minio-Source-Replication-Request header skipped the check entirely. A wrong key returns 403, a replication marker without the key returns 400; replication peers holding s3:ReplicateObject are unaffected. Inherited from upstream.

SN-2026-008 — internal replication headers

Remote exploitation: yes; any authenticated principal that can read or write the object. Completes CVE-2026-34204: internal headers such as X-Minio-Source-Etag, X-Minio-Source-Mtime, X-Minio-Source-Replication-Request, the replication SSE key headers, and X-Amz-Bucket-Replication-Status were still trusted on presence in most handlers. Replication semantics now require the exact marker value together with s3:ReplicateObject or s3:ReplicateDelete; other requests have these headers removed after signature verification. Site replication service accounts and bucket-replication targets that already hold the replication permissions are unaffected. Inherited from upstream.

SN-2026-009 — user/group status authorization

Remote exploitation: yes; authenticated admin API. Status changes were authorized against admin:EnableUser / admin:EnableGroup regardless of the requested status, so a principal allowed only to enable could also disable, and vice versa. Enable and disable now require the action matching the target status. Policies that grant only one of the pair lose the other operation; admin:* and the built-in consoleAdmin policy are unaffected. Inherited from upstream.

SN-2026-010 — explicit version delete authorization

Remote exploitation: yes; authenticated S3 API. Explicit version deletes were authorized as s3:DeleteObject with only a deny check on s3:DeleteObjectVersion, diverging from AWS. Explicit version deletes now require s3:DeleteObjectVersion. Two policy effects: principals granted only s3:DeleteObject can no longer delete specific versions, and a policy that relied on Deny s3:DeleteObject to block permanent deletes must also deny s3:DeleteObjectVersion, because Allow s3:* now permits explicit version deletes. Replication targets keep the s3:ReplicateDelete contract. Inherited from upstream.

SN-2026-011 — unsigned x-amz-* headers and x-amz-copy-source

Remote exploitation: yes; a party holding only a presigned PUT URL, or any signed PUT, needs no credentials of its own. SigV4 verification only checked that each named signed header was present and never inspected the x-amz-* headers that actually arrived, while the router dispatches any PUT carrying x-amz-copy-source to CopyObjectHandler. An unsigned x-amz-copy-source therefore turned a one-object write grant into a server-side copy of any object the signing key can read, executed as the signer; both the presigned and Authorization-header paths were affected, and where the destination bucket allows anonymous GetObject the copied private bytes become readable unauthenticated. Any unsigned x-amz-* request header is now refused with AccessDenied on both paths, matching AWS S3 (AWS returns 403; Silo returns 400 AccessDenied, otherwise identical). Every AWS SDK, minio-go, and mc already signs its x-amz-* headers, so legitimate clients need no change. Inherited unchanged from upstream minio/minio; every earlier release, including the latest published Server 20260903, is affected. Reported by Oren Yomtov; a CVE has been requested. See the chronicle article and the signed-header design record.

Dependency security updates

Rows list the absorbed fix and the commit or release that first carried it. Reachability and deployment exposure still need to be judged per release: an absorbed dependency fix is not a claim that the vulnerability was reachable in Silo.

Operationally significant security-related fixes

Attribution of this ledger

This page is maintained from the ledger previously carried in the repository at docs/security/advisories.md, updated through verified main 40220bd836cb (2026-09-16). Release status statements are calibrated against the component matrix; each fix’s investigation, review, and verification detail lives in the linked chronicle article or release note.