CVE-2026-97731: High severity MinIO MinIO vulnerability
MinIO through 7aac2a2 does not verify that every x-amz- header present on a request also appears in the client-supplied X-Amz-SignedHeaders list. extractSignedHeaders() in cmd/signature-v4-utils.go iterates only the claimed list and never enumerates the headers that actually arrived, and thus a header that arrives unsigned is neither hashed into the canonical request nor rejected. Because cmd/api-router.go dispatches CopyObject on the presence of x-amz-copy-source alone, the holder of a presigned PUT URL scoped to a single object can add that header to the unmodified URL and cause a server-side copy, executed as the signer, of any object the signing key can read. A grant to write one object becomes a read of every bucket that key can reach. Amazon S3 rejects the equivalent request with HTTP 403 AccessDenied. The minio/minio GitHub repository was archived in April 2026; pgsty/silo before 1233254 is also affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pgsty/siloto a version that resolves this vulnerability.Patch 1233254
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments of MinIO through commit 7aac2a2 and pgsty Silo before commit 1233254 are affected. Exposure exists where presigned PUT URLs are issued to parties that should only be able to write a specific object.
What does an attacker need to exploit it?
The attacker needs a valid presigned PUT URL scoped to an object and must be able to add an x-amz-copy-source header without changing the signed URL. The signing key associated with that URL must have read access to the object the attacker wants copied.
What is the practical impact of a successful exploit?
An attacker can turn permission to write one object into a server-side copy operation performed with the signer’s privileges. This can expose data from any bucket or object that the signing key is allowed to read.
Is a normal presigned PUT request enough to trigger the vulnerable behavior?
The issue is triggered by adding x-amz-copy-source to the request while leaving it out of X-Amz-SignedHeaders. The API router selects CopyObject based on the presence of that header, even though it was not included in the signed canonical request.
What can be done if upgrading is not immediately possible?
Avoid issuing presigned PUT URLs to untrusted recipients where the associated signing identity has broader read access. Use signing credentials limited to the minimum required bucket and object permissions, particularly without read access to unrelated objects.