The vulnerability is a path traversal flaw introduced in the ReadMultiple storage-REST endpoint. The analysis of the introducing commit, f939d1c1831c71f4b1c14df6d9cd62b12ccce7a3, reveals the addition of this new functionality for handling multipart uploads independently.
The root cause is the lack of input validation on the Bucket field within the msgpack-encoded request body of the POST /minio/storage/{drivePath}/v63/rmpl endpoint. MinIO's existing path traversal protection, setRequestValidityMiddleware, only inspects URL paths and form data, leaving the msgpack body unchecked.
The vulnerable execution flow starts at the storageRESTServer.ReadMultiple handler in cmd/storage-rest-server.go. This function receives the HTTP request, decodes the msgpack body into a ReadMultipleReq struct, and passes it directly to the storage layer.
The core vulnerability lies in xlStorage.ReadMultiple in cmd/xl-storage.go. This function constructs a file path using pathJoin(s.diskPath, req.Bucket). Since req.Bucket is attacker-controlled and not sanitized, it can contain ../ sequences. The path.Clean function used by pathJoin resolves these sequences, allowing an attacker to traverse the filesystem and read files outside the intended storage root, limited only by the file system permissions of the MinIO server process. In distributed deployments, the readMultipleFiles function in cmd/erasure-common.go is used to propagate this malicious read request across all nodes in the cluster.
The exploit requires a valid root JWT, meaning a compromised peer or any actor with the root credential can trigger it. The patch for this vulnerability was to completely remove the ReadMultiple endpoint and its associated functions.