Supabase Storage accepted replayed S3 signed requests and presigned URLs after they should have expired

GHSA-2p28-q2vx-mw6w, published November 2, 2026, says Supabase Storage did not fully enforce the lifetime of S3 Signature Version 4 requests. For requests signed in the Authorization header, Storage checked the signature but not how far the x-amz-date timestamp was from the server's clock, so a valid signed request could be reused after the expected 15-minute window. For presigned URLs, Storage skipped the expiration check when X-Amz-Expires was missing or empty, did not enforce the supported range when it was present, and did not fully validate request timestamps, including future and invalid dates.

The advisory says these requests still needed a valid signature, session-token authentication still verified the JWT, and changing an existing presigned URL's expiration breaks its signature. The risk is that a signed request or URL someone obtained keeps working longer than intended, within what the credentials behind it allow. It rates the issue Medium, CVSS 3.1 score 6.5, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N, assigns CWE-294, Authentication Bypass by Capture-replay, and lists no CVE id.

The advisory's text says versions before 1.81.4 lack the header-signature freshness check, that the presigned URL gaps date back to 1.5.0, and that the fix is available from 1.81.4. Its version data lists Storage 1.84.13 and earlier as affected and 1.84.14 as patched. The fix enforces a 15-minute clock-skew limit for header-signed requests and requires presigned URL expirations to be a whole number of seconds from 1 to 604800. If you cannot upgrade yet, the advisory says to set S3_PROTOCOL_ENABLED=false and restart every Storage instance, or block the S3 endpoint at your gateway and prevent direct access to the Storage origin. The standard Storage REST routes stay available either way. The advisory does not say whether hosted Supabase projects were affected.