MinIO EUVD-2026-86510

Exploitation requires the attacker to already possess a valid SigV4 presigned URL (e.g., a presigned PUT scoped to one object) issued by MinIO through commit 7aac2a2 or pgsty/silo before commit 1233254, AND the access key behind that presigned URL must have read permission over additional buckets/objects for the attack to yield meaningful data. The concrete trigger is adding an x-amz-copy-source header to the otherwise-unmodified presigned request; MinIO dispatches CopyObject on that header's presence alone and, per extractSignedHeaders(), never rejects the unsigned x-amz-* header. Limiting factors: the attacker must be granted a presigned URL in the first place (so this is a privilege-escalation-from-delegated-credential, not fully unauthenticated), and the value of the breach is bounded by the signing key's own read scope. Amazon S3 is not affected - it returns HTTP 403 AccessDenied for the equivalent request.

This is a genuine signature-verification bypass (CWE-347) in MinIO's AWS SigV4 implementation, not a paper-tiger high-CVSS issue, but its real-world priority is moderate rather than emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N = 7.1) is internally consistent with the described mechanism: the attacker must already hold a valid presigned PUT URL (hence PR:L, a delegated capability rather than PR:N), needs no user interaction, and gains high confidentiality impact (read of any object the signing key can reach) with only low integrity impact (a server-side object copy is created). No EPSS score, no CISA KEV listing, and no explicit proof-of-concept were supplied, so exploitation status is 'no public exploit identified at time of analysis' - however the description is unusually detailed at the code level (naming extractSignedHeaders() in cmd/signature-v4-utils.go and the CopyObject dispatch in cmd/api-router.go), which materially lowers the bar to weaponization for a skilled attacker. A key complicating signal: the upstream minio/minio GitHub repository was archived in April 2026, so the canonical product will likely NOT receive a fix; the only observed remediation is in the downstream fork pgsty/silo (commit 1233254). That combination - no upstream patch plus a widely deployed product - raises long-tail risk even though there is no evidence of active exploitation today. Note the CPE lists only minio:minio while the reference/patch evidence is entirely from pgsty/silo, a discrepancy defenders should reconcile.

An application legitimately issues a presigned PUT URL scoped to a single object to a partner or client. The URL holder, instead of uploading, appends an unsigned x-amz-copy-source header to the unchanged URL; because MinIO routes CopyObject on the mere presence of that header and never checks that it was covered by the signature, the server performs a server-side copy executed as the signer, letting the holder exfiltrate any object the signing key can read. No public exploit code is identified, but the advisory describes the exact code paths, so exploitation is straightforward for a knowledgeable attacker.