Capgo - Hashed API Key Enforcement Bypass via PostgREST/RLS Plane

An attacker who possesses a valid plaintext API key for an organization that has enabled `enforce_hashed_api_keys=true` can bypass the org's security control by sending the plaintext key in the `capgkey` header directly to the Supabase/PostgREST REST API, rather than to the backend `/apikey` endpoint. The backend plane correctly rejects the plaintext key with a 401 error, but the PostgREST/RLS plane accepts it through `get_identity(...)` / `find_apikey_by_value(...)` and authorizes access to RLS-protected resources. This creates a policy split where the same key is rejected on one auth plane and accepted on another.

The vulnerability spans multiple migration files: `supabase/migrations/20250530233128_base.sql` (lines 2007-2021) reads the `capgkey` header, `supabase/migrations/20250903010822_consolidated_org_apikey_migrations.sql` (lines 27-41) defines RLS policies that use `get_identity(...)`, and `supabase/migrations/20260105150626_fix_is_allowed_capgkey_hashed_apikeys.sql` (lines 26-33) implements `find_apikey_by_value(...)` which matches both plaintext `key` and hashed `key_hash`. The org-level hashed-key enforcement in `supabase/migrations/20251228080032_hashed_api_keys.sql` (lines 132-136) is applied only on the backend plane, not in the RLS identity path.

The advisory recommends applying org hashed-key enforcement in the same identity path used by RLS/PostgREST API-key authentication, specifically that `get_identity(...)` / `find_apikey_by_value(...)` should consult org hashed-key enforcement before returning a usable principal for plaintext keys. The patch is not included in the bundle, but the fix would ensure both planes share one enforcement decision so that if the backend rejects a plaintext key for an org, PostgREST/RLS rejects it too.