Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-25T03:16:59.697Z",
  "pubdate": "2026-09-25T03:16:59.697Z",
  "executiveSummary": "This vulnerability involves an improper validation mechanism in MinIO's AWS Signature Version 4 implementation, specifically concerning the handling of signed headers.\nThe flaw allows an attacker possessing a restricted presigned PUT URL to perform unauthorized server-side object copies.\nBy manipulating x-amz-* headers that are not included in the X-Amz-SignedHeaders list, an attacker can bypass authorization constraints tied to the original presigned URL.\nThis effectively elevates the privileges of a limited write-only credential to read-access for any object the signing key is permitted to access.\nThe vulnerability affects MinIO versions through 7aac2a2 and pgsty/silo versions before 1233254.\nThe root cause is a failure to verify that all provided x-amz-* headers are explicitly declared within the signed headers list during the canonicalization process.\nThis facilitates arbitrary data exfiltration by enabling unauthorized CopyObject operations, which are otherwise rejected by standard S3 implementations.",
  "technicalDetails": "The vulnerability resides within the request authentication workflow, specifically in cmd/signature-v4-utils.go. The function extractSignedHeaders() iterates exclusively over the headers explicitly identified in the client-supplied X-Amz-SignedHeaders list. It fails to perform an intersection or verification against the actual set of headers present in the incoming HTTP request. Consequently, any x-amz-* header injected into the request that is omitted from the SignedHeaders list remains unauthenticated and ignored by the signature verification logic, yet it is processed by the application layer.\nThe attack vector exploits the dispatch logic in cmd/api-router.go, which triggers the CopyObject handler if the x-amz-copy-source header is detected. An attacker can take a legitimate presigned PUT URL—which is scoped to a specific object for write operations—and append an x-amz-copy-source header to the request without including it in the X-Amz-SignedHeaders list. Because the signature check does not validate the integrity of this unsanctioned header, the server processes the request as if it were a valid CopyObject instruction.\nThe attack flow proceeds as follows: 1) The attacker obtains a presigned URL authorized for a specific write operation. 2) The attacker constructs a malicious HTTP request using the presigned URL, injecting the x-amz-copy-source header pointing to a sensitive object within the same environment. 3) The server receives the request; extractSignedHeaders() ignores the injected header because it is not in the signed list. 4) The server validates the signature based on the partial list, passing authentication. 5) The api-router detects the presence of x-amz-copy-source and executes the CopyObject operation. 6) The contents of the sensitive source object are written to the target location specified by the presigned URL, allowing the attacker to exfiltrate the data.\nThis vulnerability deviates from standard AWS S3 behavior, where an unauthorized or missing signature for any header involved in the request context would result in an HTTP 403 AccessDenied error. The impact is significant, as it grants unauthorized read access across all buckets accessible by the credentials used to generate the original presigned URL, effectively bypassing the intended scope of the presigned request."
}