MinIO ReadMultiple path traversal enables file disclosure outside drive roots

MinIO is a high-performance object storage system. From RELEASE.2022-07-24T01-54-52Z to before RELEASE.2026-04-14T21-32-45Z, A path traversal vulnerability in MinIO's ReadMultiple internode storage-REST endpoint allows a caller holding the cluster root JWT to read files from outside the configured drive roots, bounded only by the MinIO process UID. The attacker sends POST minio/storage/{drivePath}/v63/rmpl with a msgpack-encoded body carrying../ sequences in the Bucket field. The server opens the resulting path via os.OpenFile with O_RDONLY|O_NOATIME and returns its contents in the msgpack response stream. This vulnerability is fixed in RELEASE.2026-04-14T21-32-45Z.

The normalized record identifies minio/minio as affected for >= RELEASE.2022-07-24T01-54-52Z, < RELEASE.2026-04-14T21-32-45Z.

• The fixed release identified by the record is RELEASE.2026-04-14T21-32-45Z.
• The vendor advisory distinguishes the open-source minio/minio line and describes it as affected from RELEASE.2022-07-24T01-54-52Z through its final release, RELEASE.2025-09-07T16-13-09Z.
• The same advisory states that MinIO AIStor removed this route starting with RELEASE.2024-10-23T19-38-07Z, and that AIStor releases from that point onward are unaffected. These statements distinguish product lines, so administrators should identify the deployed distribution before applying a version boundary.

The flaw is in the internal ReadMultiple storage-REST endpoint, involving cmd/storage-rest-server.go and cmd/xl-storage.go. The handler decodes a msgpack body containing Bucket, Prefix, and Files, then passes those values to xlStorage.ReadMultiple without sufficient path containment validation.

1. The Bucket value is joined with drivePath to form volumeDir.
2. pathJoin calls path.Clean, so .. components can escape the configured drive root instead of remaining inside the storage directory.
3. The request-validity middleware rejects .. in the URL path and form data, but it does not inspect the msgpack request body, allowing this validation boundary to be bypassed.
4. The server opens the resulting path with os.OpenFile using O_RDONLY|O_NOATIME and returns the data in the msgpack response stream.

The request must reach POST minio/storage/{drivePath}/v63/rmpl and include the required cluster-root authentication. The advisory does not establish every implementation detail or every file reachable in each deployment; the practical file scope still depends on the UID running the MinIO process.

The flaw is reachable over the network through the internode storage-REST route, but its deployment scope is limited. Distributed-erasure multi-node deployments are affected, while standalone single-node deployments do not register the route according to the vendor advisory.

An attacker needs an HS512 JWT signed with MINIO_ROOT_PASSWORD and containing accessKey = MINIO_ROOT_USER. This means the attacker must obtain the cluster root credential or control a peer that can use the cluster's shared secret. No user interaction is required, and the normalized record describes low attack complexity.

The record does not identify a public exploit and sets public_exploit to false. It also does not provide a known-exploited status. That status is not evidence that exploitation has never occurred.

A successful attack allows a caller with a cluster root JWT to make ReadMultiple open and return files outside the configured drive root. This is a confidentiality issue; the record does not describe file modification or availability loss.

• For a process running as the MinIO UID on bare metal, file reads are constrained by file ownership and the O_NOATIME behavior, but service secrets and data sharing that UID may still be exposed.
• For a container running as UID 0, the consequence may extend to host-filesystem disclosure depending on namespaces, mounts, and container privileges.
• The vendor confirms the affected scope for distributed-erasure multi-node deployments; standalone single-node deployments do not register the affected route.
• Exposure of root credentials, TLS keys, KMS or KES material, service-account tokens, or tenant data could create follow-on operational and access risks, but the record does not confirm a specific breach.

The flaw primarily threatens data and operational confidentiality. The described primitive does not provide a documented ability to modify files or disrupt service.

• On bare-metal systems, reads may be limited to files owned by the MinIO UID, but this can still expose TLS private keys, KMS or KES key material, systemd credentials, and data belonging to other tenants sharing that UID.
• In containers running as UID 0, the advisory describes possible host-filesystem disclosure, including Kubernetes service-account tokens, metadata data, and other sensitive files.
• Exposed credentials or key material could create follow-on access risk if those secrets remain usable, but the record does not confirm a specific subsequent intrusion scenario.
• Root credentials and secrets suspected of exposure should be treated as readable data even if the cluster credential is later changed.

1. Identify whether the deployment uses the open-source minio/minio line or MinIO AIStor, then upgrade distributed-erasure deployments to MinIO AIStor RELEASE.2026-04-14T21-32-45Z, the target release recommended by the advisory.
2. Verify that every node in the cluster runs the applicable fixed release before considering remediation complete. Do not infer the status of one branch from the fix status of another branch.
3. If an upgrade cannot be completed immediately, rotate the cluster root credential and strictly limit who can hold or use MINIO_ROOT_PASSWORD. This reduces exploitability but does not remove the flaw.
4. Avoid running the MinIO container as UID 0 where possible. Use securityContext.runAsNonRoot: true with a non-zero UID in Kubernetes, or specify a non-privileged user when starting the container, to reduce the set of readable files.
5. Restrict the internode storage-REST route at the network layer. The vendor recommends using a separate interface or port for internode traffic with --internode-port where appropriate, and allowing access only from cluster peers.
6. If credentials, key material, or sensitive files may have been read, rotate the affected secrets and assess systems that trust them. Changing the root credential does not revoke data that may already have been copied.

1. Inventory all MinIO instances and determine their deployment topology. Prioritize distributed-erasure multi-node deployments because standalone deployments do not register the affected route.
2. Compare each deployed release with the affected and fixed boundaries stated in affected_summary and remediation. Do not use deployment topology alone as a safety determination.
3. Determine the effective UID of the MinIO process, especially for containers and Kubernetes. Record workloads running as UID 0 or without securityContext.runAsNonRoot.
4. Review the ownership and locations of sensitive files that the MinIO UID could read, including TLS private keys, KMS or KES key material, systemd credentials, and data belonging to other tenants sharing the same UID.
5. Review logs or network telemetry for POST requests to minio/storage/{drivePath}/v63/rmpl and msgpack bodies containing ../ in the Bucket field. This is precautionary monitoring, not a complete IOC set.
6. Review how MINIO_ROOT_PASSWORD and internode JWT credentials are stored and distributed. The absence of matching log evidence does not prove that the system is safe.