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 five 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 OINK, link and build fixes, ongoing maintenance, and translation into Chinese. The commit history is the complete record of changes.

The blog, download and release pages, this section, and PGSTY SILO-specific content are original works of the PGSTY SILO project. Pages that carry upstream material include a notice at the bottom of the page, and pages that PGSTY SILO has modified beyond format conversion link to their 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-11-09, 76 community contributors are credited in SILO and related projects. The roll includes maintainers and every human issue / PR author, along with security reporters who have agreed to be acknowledged.

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 alongside the original PR status. 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. Review dates are listed per repository; records not rechecked retain their earlier dates and states. There are 72 distinct human public issue / PR authors, plus 4 credited security reporters. 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

PGSTY SILO maintains active security tracking and patching for the S3-compatible object storage stack after upstream minio/minio entered archive mode. Current production deployments should run Server 20261026 (which embeds Console v2.5.1 and retains the fixes first shipped in Server 20261018 for Object Lock advisories SN-2026-015 / SN-2026-016 and IAM Admin boundary SN-2026-017, building on SN-2026-011 through SN-2026-014 from Server 20260916), standalone Console v2.6.0, mcli 20261109, and silo-pkg v3.16.0; see the October Security Note, Advisory Ledger, and Component Matrix.

Note that deploying standalone Console does not replace an older Server’s embedded Console, and built-in policy Reset, immediate bucket-list refresh, and bucket quota validation fixes require the corresponding Server or standalone Console versions (see the Console 2.5.1 and Console 2.6.0 release notes).

Reporting a Vulnerability

Report undisclosed vulnerabilities through a private channel rather than a public issue:

• SILO Server, Console, mcli, and silo-pkg: Submit a private report via GitHub Security Advisories on pgsty/silo.
• Documentation (silo.pgsty.com): Open an issue on pgsty/silo.pgsty.com, or use the private advisory channel above if the report discloses an exploitable weakness.

Include the affected component version, reproduction steps, and impact scope. SILO is maintained as an open-source project on a best-effort basis without commercial response-time SLAs.

Upstream MinIO Vulnerabilities

Because SILO shares lineage with minio/minio, most vulnerabilities in inherited code affect both codebases. Report findings in inherited code directly to SILO; when a vulnerability affects other active distributions of the same lineage, we coordinate disclosure as appropriate.

Where Fixes Are Published

• Advisory Ledger: The canonical index of all CVE-* and SN-2026-* identifiers, fix commits, affected versions, and dependency security updates.
• Security Advisories: Technical advisories detailing root causes, exploit conditions, code fixes, and upgrade requirements.
• Release Notes: Versioned release announcements for Server, Console, mcli, and silo-pkg.

Deployment Hardening

• Security Checklist — production access control, network isolation, and key management.
• Network Encryption (TLS) — certificate configuration for S3, Console, and internode traffic.

See Also

• License
• Attribution

7 - Security Advisories

This ledger summarizes security fixes and upgrade-impacting security notes across the pgsty/silo stack. Each advisory with its own deep-dive investigation links to its full article in the Security Chronicle or Design Notes; this page serves as the canonical index of identifiers, fix commits, exposure conditions, and upgrade boundaries.

Entries with a public CVE use that identifier. Because upstream minio/minio is archived and no longer coordinates CVE assignments for inherited code, findings without a CVE carry a stable SN-<year>-<sequence> identifier (SN-2026-002 through SN-2026-019) so release notes, commits, and issues can reference them unambiguously. SN-2026-001 tracks a non-security streaming-flush regression in trackingResponseWriter (Server 20260804).

Current Release Boundary

The current production baseline is Server 20261026 (with embedded Console v2.5.1 and silo-pkg v3.15.2), standalone Console v2.6.0, mcli 20261109, and silo-pkg v3.16.0, all built with Go 1.27.3. KES 20261026 is the optional external key service. These releases retain the earlier security fixes below and add the dependency security updates. The first fixed versions remain:

• Server 20261018 fixes SN-2026-015 (PutObjectRetention governance bypass), SN-2026-016 (version-addressed and in-place Object Lock overwrites), and SN-2026-017 (Admin credential authorization boundaries), and adds scoped STS token revocation (0cd388c66). Server 20260916 and earlier remain affected by SN-2026-015 through SN-2026-017; deploy the upgrade to every Server node and replication peer accepting writes. See the October security note and Component Version Matrix.
• Server 20260916 and Console v2.4.1 include SN-2026-011 through SN-2026-014, which are absent from Server 20260903.
• Server 20260903 includes SN-2026-006 through SN-2026-010.
• Server 20260804 and silo-pkg v3.11.0 / v3.12.0 include SN-2026-002 through SN-2026-005, SN-2026-018, and SN-2026-019.

Inherited Upstream Advisory Baseline

SILO cut its first community release (RELEASE.2025-12-03T12-00-00Z) from upstream history that already contained CVE-2025-62506.

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

Exposure and Upgrade Guidance

CVE-2025-62506 — Session-Policy Privilege Escalation

Remote exploitation: yes (authenticated service account or STS session carrying an inline session policy). Upstream fixed the DenyOnly evaluation reset in c1a49490 (RELEASE.2025-10-15T17-29-55Z), and every SILO release since RELEASE.2025-12-03T12-00-00Z inherits it. Operators migrating from an unpatched upstream MinIO release should upgrade and audit child service accounts created by restricted parent sessions. See the CVE-2025-62506 chronicle.

CVE-2026-32285 — Mislabeled jsonparser Advisory

Public feeds describe CVE-2026-32285 as a buger/jsonparser vulnerability, but its referenced upstream fix (c1a49490) is the session-policy commit for CVE-2025-62506. SILO already selects github.com/buger/jsonparser v1.1.2 and govulncheck confirms no reachable vulnerable symbols. See the CVE-2026-32285 investigation.

CVE-2026-33322 — OIDC JWT Algorithm Confusion

Remote exploitation: yes, if OIDC is enabled (AssumeRoleWithWebIdentity or AssumeRoleWithClientGrants) and an attacker knows or can guess client_secret to forge an HS256/HS384/HS512 token. Commit d24f449e0 binds JWT verification strictly to the provider’s asymmetric JWKS keys and removes the client_secret HMAC fallback from token.Parse. Deployments that relied on symmetric HMAC id_tokens must switch their IdP to asymmetric signing (RS256, ES256, etc.).

CVE-2026-33419 — LDAP STS Enumeration and DoS

Remote exploitation: yes, if LDAP is configured (AssumeRoleWithLDAPIdentity). Returns a uniform 400 InvalidParameterValue on authentication failure without leaking internal directory errors, bounds concurrent LDAP bind operations with a reserve/commit/cancel/refund lifecycle, and removes the shared per-username rate-limit bucket (which previously allowed an attacker who knew a victim’s LDAPUsername to lock out that user from rotating source IPs). See the LDAP STS chronicle.

CVE-2026-34204 — Replication Metadata Injection

Remote exploitation: yes. Blocks untrusted X-Minio-Replication-* headers on client PutObject and CopyObject requests from being stored as internal replication metadata and leaving objects unreadable. Upgrade any server that accepts untrusted object writes. See SN-2026-008 and Replica Metadata Normalization for the subsequent replication-header hardening.

CVE-2026-39414 — S3 Select Oversized Record Memory Exhaustion

Remote exploitation: yes (s3:SelectObjectContent). Rejects CSV and JSON Lines records exceeding 1 MiB (maxCharsPerRecord) with OverMaxRecordSize instead of buffering unbounded lines in memory. The April patch (3252d5b7f) enforced the limit on CSV and standard JSON readers; the June follow-up (5dc705936) routes JSON Lines on AVX2/AVX-512 CPUs through the bounded json.PReader instead of simdj.NewReader, closing the hardware-specific SIMD bypass. See the S3 Select chronicle.

CVE-2026-41145 — Unsigned-Trailer Query Authentication Bypass

Remote exploitation: yes. Closes the presigned query-string authentication bypass when X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER is sent on PutObject or PutObjectPart. Upgrade any server reachable by clients on object write endpoints.

CVE-2026-40344 — Snowball Auto-Extract Authentication Bypass

Remote exploitation: yes. Verifies SigV4 authentication in newUnsignedV4ChunkedReader() before PutObjectExtract begins untar() extraction on Snowball unsigned-trailer uploads, guaranteeing that unauthenticated streams never reach the tar extractor.

CVE-2026-42600 — Internode ReadMultiple Path Traversal

Remote exploitation: yes (requires cluster-root / internode JWT). Removes the unused /rmpl (xlStorage.ReadMultiple) RPC endpoint that allowed msgpack request payloads to traverse outside configured drive roots. Single-node deployments do not register internode routes; distributed erasure deployments should upgrade.

SN-2026-002 — Internode Payload Path and Memory Containment

Remote exploitation: yes (requires cluster-root / internode JWT). Completes CVE-2026-42600 across the remaining internode protocol surfaces (storageREST, peerREST, grid WebSocket multiplexing, and xlStorage). Enforces path containment at two storage-layer chokepoints (getVolDir/NSScanner and getStorage() via guardPaths, hasBadPathComponent, and isVolumeRootAlias), caps caller-declared slice allocations (maxDeleteVersions = 1000, max BitrotVerifier size), validates erasure DataBlocks/ParityBlocks before division to prevent per-frame node panics, and verifies shard lengths before reporting intact data. Single-node deployments do not register these routes; no S3 API behavior changes. See the internode containment chronicle.

SN-2026-003 — Policy Condition Value Sources

Remote exploitation: yes (policy-dependent). Prevents raw HTTP query parameters or headers that spell internal IAM condition-key names from shadowing or synthesizing server-derived condition values; confines s3:signatureAge to verified SigV4 presigned requests; separates query-only list parameters from header-backed x-amz-* condition keys; prevents client request tags from impersonating stored ExistingObjectTag values; and evaluates s3:VersionId against the whitespace-trimmed version ID only when ?versionId is actually present. See the version-ID and condition chronicle and condition value sources reference.

SN-2026-004 — Object-Grant Bucket Reach

Remote exploitation: yes (policy-dependent). Withholds 12 sensitive bucket-level write actions from object-only resource patterns (arn:aws:s3:::bucket/*): PutBucketPolicy, DeleteBucketPolicy, PutBucketObjectLockConfiguration, PutBucketVersioning, PutReplicationConfiguration, PutBucketLifecycle, DeleteBucket, ForceDeleteBucket, PutBucketCors, DeleteBucketCors, PutBucketQOS, and PutInventoryConfiguration, and requires a single Allow statement to match both the action and the resource (monotone intersection). Read the SN-2026-004 chronicle before upgrading if you maintain custom bucket-scoped IAM policies: add the bare bucket ARN (arn:aws:s3:::bucket) alongside arn:aws:s3:::bucket/* in any statement intended to grant those 12 bucket-level writes. Built-in canned policies, Deny statements, and NotResource exclusions are unaffected. Setting MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on in the process environment before startup restores legacy matching (MINIO_CONFIG_ENV_FILE is read too late for package init).

SN-2026-005 — Bare ARN Prefix Rejection

Policy-hardening change (silo-pkg v3.12.0 / Server eee05a17c). Rejects S3, S3 Tables, and KMS ARN namespace prefixes that name no resource (arn:aws:s3::: and its historical *arn:aws:s3::: form) in both Resource and NotResource when creating named policies or creating/updating service-account session policies. Existing stored policies continue loading, matching, importing, and replicating without disruption, but re-submitting a policy containing a bare prefix requires replacing it with the concrete bucket/object ARN or an explicit wildcard (arn:aws:s3:::*). Note that a bare ARN prefix (arn:aws:s3:::) is distinct from a valid bare bucket ARN (arn:aws:s3:::bucket). See the SN-2026-003 / SN-2026-005 chronicle and silo-pkg v3.12.0 release notes.

SN-2026-006 — Zero-Byte SSE-C Object Key Authentication

Remote exploitation: yes (requires read access to the object). Zero-byte SSE-C objects previously returned 200 OK without unsealing the customer-provided key, allowing a caller with the wrong SSE-C key to pass HeadObject/GetObject or copy/overwrite the object under a newly chosen key. Zero-byte SSE-C reads and copies now unseal and verify the customer key, returning 403 AccessDenied on key mismatch as on AWS S3. Shipped in Server 20260903.

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

Remote exploitation: yes (requires read access to the object). GetObjectAttributes previously returned object attributes for SSE-C objects without authenticating the customer key, and skipped the check whenever a client sent X-Minio-Source-Replication-Request. Wrong SSE-C keys now return 403 AccessDenied, and unauthenticated replication markers return 400 InvalidArgument; authorized replication peers holding s3:ReplicateObject remain unaffected. Shipped in Server 20260903.

SN-2026-008 — Post-Auth Trust Boundary for Internal Replication Headers

Remote exploitation: yes (any authenticated principal with read or write access to the object). Completes CVE-2026-34204: internal headers (X-Minio-Source-Etag, X-Minio-Source-Mtime, X-Minio-Source-Replication-Request, X-Minio-Source-DeleteMarker, replication SSE key headers, and X-Amz-Bucket-Replication-Status) were previously trusted on mere presence in several handlers. Server 20260903 strips these headers from a post-authentication clone unless the caller sends the exact marker value and holds s3:ReplicateObject or s3:ReplicateDelete. Site replication service accounts and bucket-replication targets holding replication permissions are unaffected. See the chronicle and CORS & Replication Trust Design.

SN-2026-009 — User and Group Status Authorization

Remote exploitation: yes (authenticated Admin API). SetUserStatus and UpdateGroupStatus previously checked admin:EnableUser and admin:EnableGroup regardless of whether the request enabled or disabled the target, allowing an operator granted only enable permission to disable accounts (and vice versa). Status changes now check admin:EnableUser / admin:DisableUser and admin:EnableGroup / admin:DisableGroup according to the requested target state. Policies granting admin:* or consoleAdmin are unaffected; least-privilege policies granting only one action of the pair now authorize only that direction. See the chronicle and User Status Permissions Design.

SN-2026-010 — Explicit Object Version Delete Authorization

Remote exploitation: yes (authenticated S3 API). DeleteObject?versionId=... and DeleteObjects entries carrying a VersionId were previously authorized against s3:DeleteObject with only a negative check for Deny s3:DeleteObjectVersion. Explicit version deletes now require s3:DeleteObjectVersion, matching AWS S3. Two policy effects: principals granted only s3:DeleteObject can still create delete markers on unversioned DELETE calls but can no longer permanently delete specific versions; and policies that relied solely on Deny s3:DeleteObject alongside Allow s3:* to block permanent version deletion must also add Deny s3:DeleteObjectVersion. Replication targets retain the s3:ReplicateDelete contract. See DeleteObjectVersion Authorization.

SN-2026-011 — Unsigned X-Amz-* Operation Headers

Remote exploitation: yes (holder of a presigned URL or intercepted Authorization-header PUT request). Because cmd/api-router.go dispatches PUT requests carrying x-amz-copy-source to CopyObjectHandler, an attacker holding a presigned PUT URL could append an unsigned x-amz-copy-source: /src/secret header and trick the server into copying any object readable by the signer into the destination object. Reported by Oren Yomtov.

Fixed in Server 20260916 (status note, 123325430, PR #173 and #177). Both doesPresignedSignatureMatch and doesSignatureMatch now invoke checkUnsignedHeaders and reject any request carrying an unsigned X-Amz- header with 400 AccessDenied (ErrUnsignedHeaders). X-Amz-Content-Sha256 is the sole explicit header exemption because its payload digest is bound by the canonical request and verified by SN-2026-012; PR #177 also derives s3:signatureAge directly from the signed X-Amz-Date without mutating r.Header. Standard AWS SDKs, mcli, and minio-go already sign all X-Amz- headers; custom clients that append X-Amz-* headers to a presigned URL must include them in X-Amz-SignedHeaders at signing time. See Signed Header Coverage Design.

SN-2026-012 — Header-Only Presigned Payload Hash Verification

Remote exploitation: yes (holder of a presigned URL whose payload hash was bound via X-Amz-Content-Sha256 header rather than query string). Generic authenticated handlers such as PutBucketPolicy previously verified the signature against the header digest but did not verify the consumed request body against that digest, allowing a holder of the presigned URL to substitute a different body. Commit c4b5e1cb4 (Server 20260916) binds generic body verification to the same effective payload hash used during signature verification (query parameter first, header fallback) and rejects tampered bodies with XAmzContentSHA256Mismatch.

SN-2026-013 — Durable IAM Revocation and Scoped STS Revocation

Remote exploitation: requires a previously issued credential and a restart, peer-sync delay, or same-name parent recreation scenario. Before Server 20260916 (#191, #192, f99ed829b), disabling or deleting a user, rotating credentials, or recreating a user under the same name could leave previously minted STS tokens or child service accounts valid until JWT expiration, or allow stale site-replication records to resurrect deleted identities. Server 20260916 persists deletion tombstones, parent revocation timestamps, and group-grant revisions under .minio.sys/iam/revocations/, and Server 20261018 (0cd388c66) adds POST /minio/admin/v3/sts-revoke for per-principal and per-token (jti) STS revocation without invalidating unrelated sessions. Coordinate upgrades across all nodes sharing an IAM backend; see IAM Revocations Design and the IAM Upgrade Runbook.

SN-2026-014 — Anonymous Console Share-Download Proxy Restriction

Remote exploitation: yes (anonymous caller reaching the Console /api/v1/download-shared-object endpoint). The Console share-download proxy previously accepted arbitrary paths and query parameters on its configured S3 origin, allowing an unauthenticated caller to reach internal origin paths (such as /minio/v2/metrics/cluster) that operators had isolated behind the Console network boundary. Reported by Jiri Pejchal (@jiri-pejchal). Fixed in Console v2.4.1 (silo-console#56) and embedded in Server 20260916 (#209): the proxy now restricts forwarding strictly to single-object GET downloads on the configured S3 origin, rejects /minio/* system paths and subresource management queries before dialing, and refuses HTTP redirects.

SN-2026-015 — PutObjectRetention Authorization and Governance Bypass

Remote exploitation: yes (authenticated S3 caller). Three flaws in PutObjectRetentionHandler (cmd/object-handlers.go) allowed an authenticated caller to: (1) modify object retention without holding s3:PutObjectRetention by supplying X-Amz-Bypass-Governance-Retention: true when holding s3:BypassGovernanceRetention (short-circuiting the base action check); (2) clear (Mode: "") or shorten an active GOVERNANCE lock using only s3:PutObjectRetention without s3:BypassGovernanceRetention; and (3) bypass IAM Deny policies on s3:object-lock-remaining-retention-days when clearing retention. Fixed in Server 20261018 (PR #234, #235, 14042b5aa): s3:PutObjectRetention is unconditionally enforced before object lookup, weakening or clearing an active GOVERNANCE lock requires both X-Amz-Bypass-Governance-Retention: true and s3:BypassGovernanceRetention, and clearing retention evaluates s3:object-lock-remaining-retention-days = 0. See the SN-2026-015 / SN-2026-016 Advisory and Repair Architecture.

SN-2026-016 — Version-Addressed and In-Place Object Lock Overwrites

Remote exploitation: yes (authenticated S3 writer). Callers supplying ?versionId=<existing-uuid> on PutObject, CopyObject, CompleteMultipartUpload, or PutObjectExtract, or overwriting unversioned/null-version objects in place (including directory objects and multipart completions), could overwrite an existing version protected by COMPLIANCE or GOVERNANCE retention or LegalHold without triggering an Object Lock check. Fixed in Server 20261018 (14042b5aa, 0d3ba5d4c): S3 handlers reject caller-supplied ?versionId= unless the request is an authenticated replication write (isReplicationRequest), preflight checks fail closed on unreadable metadata, and storage write paths (PutObject, CopyObject, CompleteMultipartUpload, PutObjectDir) re-verify destination version lock state (checkObjectLockForOverwrite) inside the namespace write lock. Upgrade every Server node and replication peer accepting writes. See the Repair Architecture.

SN-2026-017 — Delegated IAM Admin Credential Authorization Boundaries

Remote exploitation: yes (authenticated delegated IAM administrator or restricted derived credential). In Server 20260916 and earlier, delegated admins holding admin:CreateUser, admin:AttachUserOrGroupPolicy, or admin:UpdateServiceAccount could assign policies broader than their own effective permissions, mutate higher-privilege users/groups/service accounts, or use self-service admin routes to escape session-policy or Deny restrictions. Fixed in Server 20261018 (2616d43fb, 995439260, PR #242): delegated IAM mutations now enforce target-policy containment (authorizePolicyChange, authorizeGroupTargets, authorizeTargetUser) and block non-root self-permission escalation (ErrAdminChangeUserSelfPermission). See IAM Admin Authorization Design.

SN-2026-018 — Client Source Address Trust Boundary (MINIO_API_TRUSTED_PROXIES)

Forwarded-Header Trust Policy

Opt-in security hardening (fe6dc4780, shipped in Server 20260804). By default, inherited upstream code trusts X-Forwarded-For and X-Real-IP from any direct peer, allowing clients that can reach the server directly (or behind an appending proxy) to spoof aws:SourceIp IAM conditions and evade per-IP LDAP rate limits. MINIO_API_TRUSTED_PROXIES establishes an enforceable trust boundary: when set to none, forwarded headers are never trusted; when set to a comma-separated list of proxy IPs or CIDRs, forwarded headers are accepted only from listed peers (plus loopback sidecars) and X-Forwarded-For is walked right-to-left past trusted hops to extract the first untrusted client IP. Multi-node clusters that enable MINIO_API_TRUSTED_PROXIES must include their own cluster node IPs/CIDRs in the list so peer-forwarded S3 requests preserve the original client IP. See the Source Address Trust Chronicle and Settings Reference.

SN-2026-019 — Notification Key Registration and Secret Redaction

Config-subsystem hardening (672c07a0f in Server 20260804, followed by f1ba68358 in Server 20260903). Auditing notify_postgres and notify_mysql revealed that config.HasSensitiveKeys did not redact password, dsn_string, or connection_string when returning validation errors or GetConfigKV payloads, and five discrete connection keys were missing from the registered Keyspace. Commit 672c07a0f added credential redaction in config.HasSensitiveKeys and a structural test verifying key registration across all config subsystems; Server 20260903 subsequently retired the five discrete keys in favor of connection_string and dsn_string to eliminate split-brain overwrites during startup migration. See the Notification Keyspace Chronicle and Notify URL Design.

Dependency Security Updates

Server 20261018 builds with Go 1.27.2 and selects golang.org/x/net v0.61.0, golang.org/x/crypto v0.58.0, golang.org/x/text v0.43.0, and github.com/go-jose/go-jose/v4 v4.1.6 (note that the go-jose RSA JWK parsing fix rejects RSA keys larger than 4096 bits; verify OIDC/JWKS identity providers before upgrading). Unified Go 1.27.3 and static curl 8.23.0 updates are tracked in SILO 20261026.

Operationally Significant Security-Related Fixes

Ledger Provenance

This page is maintained from the advisory ledger originally tracked in pgsty/silo (docs/security/advisories.md through f99ed829b5eba / 40220bd836cb) and aligned with the Component Version Matrix. Full root-cause traces, rejected design alternatives, and verification commands live in the linked Security Chronicle and Design Notes articles.