A Supabase Storage presigned PUT URL for one object could be used to read objects from other buckets

GHSA-3m3f-pjv4-x2fp, published November 5, 2026, says that in Supabase Storage, a party you hand a Signature Version 4 (SigV4) presigned PUT URL for one object can add one unsigned header and read any object the signing key can reach, in any bucket. The copy runs as the signer. The advisory notes that presigned uploads from an untrusted browser are a documented pattern in the product.

Prerequisites and impact

The advisory says a typical presigned PUT URL carries X-Amz-SignedHeaders=host and signs only that header. Storage built the canonical request from the names in that signed-headers list, not from every header that arrived, so an x-amz-* header outside the list was not covered by the signature check. The S3 router then selected CopyObject when the request carried x-amz-copy-source, which turned a write grant into a read of the named source object. The advisory says AWS S3 refuses the same request with HTTP 403 and AccessDenied.

You are affected if a caller can obtain a SigV4 presigned PUT URL issued by an affected Storage version. The advisory rates the issue High, CVSS 3.1 score 7.1, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, assigns CWE-347, Improper Verification of Cryptographic Signature, and lists no CVE id.

Fixed versions

The advisory's version data lists @supabase/storage-api <= 1.89.9 as affected and 1.89.10 as patched. Our advice, not Supabase's: upgrade to 1.89.10 or later. The advisory does not say whether hosted Supabase projects were affected.