MinIO Is Archived: The Dependency Your Risk Register Never Saw

Somewhere in your organisation there is a docker-compose.yml containing the line image: minio/minio. It has been there for years. It has never been reviewed, never renewed, and never appeared in a procurement conversation, because it only ever runs on developer laptops and in CI.

As of this week, that line does not pull. The MinIO repository is archived. The Docker Hub images are not there. And seven security advisories published against MinIO in 2026 name fixed versions that the public project never released.

This is not really a story about object storage. It is a story about the one category of dependency that nobody owns.

TL;DR

• The minio/minio repository is archived and read-only. The last tagged release is RELEASE.2025-10-15T17-29-55Z, from October 2025, and it was the 521st.
• Seven advisories were published against MinIO between March and April 2026. Four are high severity, including two unauthenticated object write bugs.
• The fixed versions named in those advisories do not exist as public releases. The git tags return HTTP 404, and two advisories list the affected package as MinIO AIStor, the commercial product.
• The minio/minio and minio/mc images no longer resolve on Docker Hub, while minio/operator in the same namespace still does.
• Development-only and CI-only dependencies sit outside almost every risk register, which is exactly why this arrived as a broken build instead of a planned migration.

What actually changed, and when

May 2025. RELEASE.2025-05-24T17-08-30Z, labelled a breaking release, moved the embedded web console out of the server into a separate object-browser project, and removed external identity provider logins over LDAP and OIDC. The release notes directed paying customers to AIStor.

October 2025. Two commits set the direction. On 15 October: “update README.md and other docs to point to source only releases”. On 19 October: “update scripts pointing to internal registry for community releases”. On the same day as the first, RELEASE.2025-10-15T17-29-55Z shipped, fixing CVE-2025-62506, a high-severity privilege escalation through session policy bypass in service accounts and STS. That is the last tagged release the project ever produced.

After that, the commits stop being code. 3 December 2025: “update README.md maintenance mode”. 6 January 2026: “update README.md with latest free license and enterprise option”. 12 February 2026: “update README.md format and clarify state of the project”. That is the complete commit history of 2026.

The README now opens with a note, in bold capitals, stating that the repository is no longer maintained, and points readers at AIStor Free and AIStor Enterprise. A section headed Source-Only Distribution confirms that the community edition ships as source code only and that pre-compiled binaries will no longer be provided for it.

The gap between an advisory and a release

Between 19 March and 25 April 2026, seven security advisories were published against MinIO. Four are rated high:

• CVE-2026-41145: unauthenticated object write via a query-string credential signature bypass in unsigned-trailer uploads.
• CVE-2026-40344: unauthenticated object write via missing signature verification in Snowball auto-extract.
• CVE-2026-39414: denial of service via unbounded memory allocation in S3 Select CSV parsing.
• CVE-2026-34204: server-side encryption metadata injection via replication headers.

Two unauthenticated write paths into an object store is not a subtle finding.

Each advisory names a fixed version. CVE-2026-41145 and CVE-2026-40344 both name RELEASE.2026-04-11T03-20-12Z. CVE-2026-42600 names RELEASE.2026-04-14T21-32-45Z. CVE-2026-39414 names, in plain text, “MinIO AIStor RELEASE.2025-12-20T04-58-37Z”.

None of those tags exist in the public repository:

$ for t in RELEASE.2026-04-14T21-32-45Z RELEASE.2026-04-11T03-20-12Z \
           RELEASE.2026-03-26T21-24-40Z RELEASE.2025-12-20T04-58-37Z; do
    curl -s -o /dev/null -w "$t -> %{http_code}\n" \
      https://api.github.com/repos/minio/minio/git/ref/tags/$t
  done

RELEASE.2026-04-14T21-32-45Z -> 404
RELEASE.2026-04-11T03-20-12Z -> 404
RELEASE.2026-03-26T21-24-40Z -> 404
RELEASE.2025-12-20T04-58-37Z -> 404

The newest tag in the repository is still the one from October 2025. Two of the seven advisories do not even list the affected package as minio/minio; they list it as MinIO AIStor.

The result is remediation advice that is technically accurate and practically unavailable. Read literally, these advisories tell an operator running the last open-source release to upgrade to a build the open-source project does not publish.

The README compounds it. It recommends go install github.com/minio/minio@latest for, in its own words, access to the latest features, bug fixes and security updates. But @latest resolves against a tree whose final functional commit landed in October 2025. Building from source today produces a binary containing none of the 2026 fixes. The advice is sincere and, given the state of the repository, self-refuting.

Why nobody saw this coming

Teams that ran MinIO in production largely did fine. They had a commercial relationship, a support channel, and hotfix builds still appearing on quay.io through 2026. The organisations caught out are the ones for which MinIO was never a product at all. It was a fixture.

Ask where object storage lives in your environment and you will get a confident answer involving S3 buckets, IAM policies and lifecycle rules. Ask where MinIO lives and the answer gets vague, because MinIO is not in production. It is in a compose file, a GitHub Actions service container, a Testcontainers definition, a Makefile target called dev-up. None of those were procured. None has an owner, a renewal date, or a line in a risk register. Each was chosen once, by one developer, in an afternoon, and it worked.

That is the actual vulnerability, and it has nothing to do with CVEs. A dependency that only runs in development is invisible to every control you built for production. Your SBOM is generated from the production image. Your scanner points at the deployed artefact. Your third-party risk process is triggered by an invoice. A dev-only dependency produces no image, no invoice and no scan result, so it passes through all three unexamined until the day it stops downloading.

This pattern is much wider than object storage

MinIO is an unusually clean example, not a special case. The same shape covers the payments emulator you test against, the message broker in your compose file, the fake SMTP server, the seeded database container, the mock identity provider. Each one is a standing promise that your CI is a reasonable model of production, and each one is maintained by somebody under no obligation to you whatsoever.

There is a quieter failure mode here too. When a development fixture stops tracking production, nothing breaks loudly. The tests still pass. They simply stop testing what you believe they test. A MinIO pinned in 2025 will serve your suite happily for years while the S3 API it imitates moves on without it.

What to do about it this week

1. Inventory by lifecycle stage, not by deployment. Search your repositories for compose files, CI service definitions, Testcontainers usage and devcontainer configs. What comes back is a dependency list nobody in your organisation has ever read.
2. Pin by digest and mirror it. If a build breaks because a registry entry disappeared, the fix is not a different tag; it is a digest pin plus a pull-through cache you control. Being dev-only is not a reason to skip this, it is the reason your build was fragile.
3. Give every fixture an owner and a review date. One name, one date, once a year. The cost is minutes. The alternative is learning the answer from a failing pipeline on a release morning.
4. Check availability, then check maintenance. MinIO images are still served from quay.io/minio/minio, but the newest plain tag there dates from September 2025, and the 2026-dated builds are hotfix tags against older releases. Something being pullable is not the same as it being maintained.
5. Treat a fixed version as an artefact, not a string. Confirm the tag exists, in the registry you actually pull from, under the licence you actually hold. A version you cannot obtain is not a remediation.
6. Choose a replacement deliberately, then move once. The realistic options are AIStor Free under its own terms, a maintained alternative such as SeaweedFS, Garage or S3Proxy, or a general emulator if all you need is an S3-shaped endpoint for tests. Picking one on purpose beats five teams each picking differently during a broken build.

The part worth remembering

The uncomfortable thing here is not that a company changed its business model. Companies do that, and AGPLv3 never promised otherwise. The uncomfortable thing is how long it took anyone to notice, and that the notification arrived as a red build rather than as a decision.

Most mature organisations can tell you precisely what runs in production. Far fewer can tell you what runs in CI, who chose it, and what happens when it stops being published. That gap is where this entire class of problem lives, and closing it costs an afternoon.

REPTILEHAUS builds and maintains development and deployment pipelines for teams who would rather discover this on a quiet Tuesday than during a release window. If you are not certain what your CI actually depends on, or you need a clean migration off a fixture that quietly stopped being maintained, get in touch.

📷 Photo by the blowup on Unsplash