← All incidents

Supabase Storage GHSA-8rrf-w776-x75g: signed resumable upload routes let anyone create or overwrite files in storage-api 1.80.1 and earlier

Vulnerability · Supabase Storage (storage-api) 1.80.1 and earlier, self-hosted · HIGH

Summary

Supabase published GitHub advisory GHSA-8rrf-w776-x75g on Oct 14, 2026 for its Storage server, storage-api. The advisory says an authorization bypass in the signed resumable-upload routes "allowed unauthenticated callers to create or overwrite objects in public or private buckets", skipping row-level security. Supabase rates it Critical, CVSS 3.1 9.1, and lists no CVE. It affects storage-api 1.80.1 and earlier and is fixed in 1.80.2, which Supabase released on Oct 8. For self-hosters, Supabase's Docker setup 0.8.3 (Oct 16) updates Storage to v1.81.0 and lists this fix. The two Docker setups before it, 0.8.1 (Sep 9) and 0.8.2 (Sep 23), shipped storage-api v1.74.0, which is in the affected range. The advisory covers the storage-api software and does not mention the hosted Supabase platform. Supabase has not said whether hosted projects were affected or when the hosted service received the fix. The advisory does not report any exploitation. Supabase credits Elias Hasas (@zer0d4y5) with finding it.

Severity

Timeline

1. Sep 9, 2026
   Supabase's self-hosted Docker setup 0.8.1 moves Storage to storage-api v1.74.0, per its versions.md, and 0.8.2 (Sep 23) keeps it. That version is in the affected range.
2. Oct 8, 2026
   Supabase releases storage-api 1.80.2. Its release notes list "hardening for tus signed (#1492)", the pull request Supabase's Docker changelog links to this fix.
3. Oct 14, 2026, 4:27 a.m. ET (08:27 UTC)
   Supabase publishes GHSA-8rrf-w776-x75g, rated Critical (CVSS 3.1 9.1), affecting storage-api 1.80.1 and earlier, patched in 1.80.2.
4. Oct 16, 2026
   Supabase's self-hosted Docker setup 0.8.3 updates Storage to v1.81.0 and lists the fix, calling updating "strongly recommended".

How it happened

Per the advisory, signed resumable uploads, which use the TUS protocol, run on a privileged database connection, because the signed-upload token is what authorizes them rather than the caller's login token. In affected versions, Storage only checked that token when the raw request URL started with a fixed path prefix. The router and the check read some requests differently: percent-encoded paths and absolute-form request targets (a full URL in the request line) could reach the signed-upload route without matching the prefix, so no x-signature token was validated. The remaining permission check then ran on the privileged connection, so row-level security did not block the upload. The advisory says an attacker who knew a bucket and object name could create a new object or overwrite an existing one, and that a zero-byte upload could replace a file's contents with an empty file. Version 1.80.2 identifies signed uploads from the matched route instead of the raw URL and requires a valid token for the target bucket and object before processing the upload. Supabase has not said whether the hosted platform was affected or when it was patched, and we are not assuming either. We will update this entry if Supabase says.

How to check your app

• Find your Storage version. In your self-hosted deployment directory, look at the storage service's image tag in docker-compose.yml (for example, supabase/storage-api:v1.81.0). Version v1.80.1 or earlier is affected. If your deployment records its release in .supabase-version, a release before self-hosted/v0.8.3 shipped an affected Storage version.
• Back up your database and Storage data first. Supabase's update guide says update.sh does not back up Postgres or Storage data, and its changelog says the Storage migrations in 0.8.3 are one-way: rolling back to the previous Storage version afterwards makes all uploads fail. If you ever ran Storage v1.72.0 to v1.72.3, apply the fix from storage#1394 before updating, as the changelog says.
• Update to self-hosted 0.8.3 or later. Supabase's documented path is sh update.sh --dry-run to preview, sh update.sh to apply, then sh run.sh pull and sh run.sh recreate. Review any conflicts and breaking-change notices the script prints.
• If you only change the Storage image, set it to storage-api v1.80.2 or later in docker-compose.yml, then run sh run.sh pull and sh run.sh recreate storage. Supabase's docs say mixing image versions this way is not guaranteed to be compatible, so the full update is the safer route.
• Look for unexpected uploads and overwrites in the storage.objects table, for the whole time you ran an affected version. Supabase's docs show that the table records each object's bucket_id, name, created_at and updated_at, and its size in metadata->>'size'. Sort by updated_at to find files that changed when nobody in your app changed them, and list objects with a size of 0, since the advisory says a zero-byte upload could empty a file.
• If you keep Storage or gateway request logs from that period, look for upload requests to the resumable-upload route that use percent-encoded paths or a full URL in the request line. The advisory names both as the way past the token check.
• Replace any file you find was changed from a known-good copy, and upload it through the Storage API or your app. Supabase's docs say to treat the storage tables as read-only and make all changes through the API.
• On hosted Supabase, the advisory does not say whether you need to do anything. We will update this entry if Supabase says.

Sources

• Supabase: GitHub advisory GHSA-8rrf-w776-x75g, Unauthenticated object uploads and overwrites through signed resumable upload routes (Oct 14, 2026). Primary source
• Supabase Storage v1.80.2 release notes (Oct 8, 2026)
• Supabase self-hosted Docker changelog, 0.8.3 (Oct 16, 2026)
• Supabase self-hosted Docker image versions (versions.md, as of 0.8.3)
• Supabase docs: Update your self-hosted deployment
• Supabase docs: Self-Hosting with Docker
• Supabase docs: The Storage Schema
• Supabase docs: Manage Storage size usage (querying object sizes)

Corrections and updates

None. Re-checked against every source on Oct 28, 2026.