/
← Voltar ao feed
high

Chupabase tool exploits misconfigured Supabase RLS in Lovable-generated apps to extract data without authentication

1 fonte(s) · 1 atualização(ões) · publicado 01/04/2026 09:54 · coletado há 1 dia

Hakai Security released Chupabase, a Python tool that finds and demonstrates insecure Supabase backend configurations in applications generated by the vibe coding platform Lovable. It parses the app's JavaScript bundles (and the sw.js Service Worker precache manifest) to recover the Supabase URL, the public anonKey and the API endpoint map. It then probes which tables, RPCs and Edge Functions respond to the anon role. In preliminary tests the authors found several apps exposing user data, logs and form records. The article ties the issue to CVE-2025-48757, reported by researcher Matt Palmer, which exposed data from more than 170 Lovable-generated apps because Row Level Security (RLS) policies were missing or misconfigured. Lovable's position is that each customer is responsible for securing their own app's data.

Technical Details

  • The anonKey is a role identifier, not a secret. The weakness is excessive permissions for the anon role: RLS disabled or permissive on PostgREST tables, RPCs running as SECURITY DEFINER or executable by anon, and Edge Functions without JWT validation.
  • The attacker model is an unauthenticated external user who needs only the public frontend and its static files.
  • Chupabase runs in 6 steps: (1) find sw.js and its precached assets, (2) locate the largest .js bundle, (3) extract the Supabase URL and anonKey, (4) scan for .from(), .rpc() calls and Edge Function URLs, (5) generate a swagger.yaml, (6) with the test flag, check which endpoints return 200 OK under the anon role.
  • Default Lovable stack: React, Vite, Tailwind, shadcn/ui, with Supabase/PostgreSQL as the backend.
  • In a well-configured app the tool should only see 401/403 responses.

Remediation

  • Enable RLS on all tables and use ALTER TABLE <name> FORCE ROW LEVEL SECURITY.
  • Add TO authenticated to policies for non-public data, and base policies on auth.uid() or auth.jwt().
  • Validate auth.role() = 'authenticated' inside RPCs and keep them SECURITY INVOKER. Run REVOKE EXECUTE ON FUNCTION <function_name>() FROM anon for sensitive functions.
  • Verify the JWT explicitly in Edge Functions, for example with supabase.auth.getUser().
  • Move critical tables out of the public schema, apply least privilege to the anon role, and audit production bundles and the Service Worker regularly.

Linha do tempo

  1. yokai.hakaisecurity.io ↗ · pub. 01/04/2026 09:54 · coletado 19/10 18:03 primeiro registro

    Chupabase tool exploits misconfigured Supabase RLS in Lovable-generated apps to extract data without authentication

    ler a análise desta fonte

    Hakai Security released Chupabase, a Python tool that finds and demonstrates insecure Supabase backend configurations in applications generated by the vibe coding platform Lovable. It parses the app's JavaScript bundles (and the sw.js Service Worker precache manifest) to recover the Supabase URL, the public anonKey and the API endpoint map. It then probes which tables, RPCs and Edge Functions respond to the anon role. In preliminary tests the authors found several apps exposing user data, logs and form records. The article ties the issue to CVE-2025-48757, reported by researcher Matt Palmer, which exposed data from more than 170 Lovable-generated apps because Row Level Security (RLS) policies were missing or misconfigured. Lovable's position is that each customer is responsible for securing their own app's data.

    Technical Details

    • The anonKey is a role identifier, not a secret. The weakness is excessive permissions for the anon role: RLS disabled or permissive on PostgREST tables, RPCs running as SECURITY DEFINER or executable by anon, and Edge Functions without JWT validation.
    • The attacker model is an unauthenticated external user who needs only the public frontend and its static files.
    • Chupabase runs in 6 steps: (1) find sw.js and its precached assets, (2) locate the largest .js bundle, (3) extract the Supabase URL and anonKey, (4) scan for .from(), .rpc() calls and Edge Function URLs, (5) generate a swagger.yaml, (6) with the test flag, check which endpoints return 200 OK under the anon role.
    • Default Lovable stack: React, Vite, Tailwind, shadcn/ui, with Supabase/PostgreSQL as the backend.
    • In a well-configured app the tool should only see 401/403 responses.

    Remediation

    • Enable RLS on all tables and use ALTER TABLE <name> FORCE ROW LEVEL SECURITY.
    • Add TO authenticated to policies for non-public data, and base policies on auth.uid() or auth.jwt().
    • Validate auth.role() = 'authenticated' inside RPCs and keep them SECURITY INVOKER. Run REVOKE EXECUTE ON FUNCTION <function_name>() FROM anon for sensitive functions.
    • Verify the JWT explicitly in Edge Functions, for example with supabase.auth.getUser().
    • Move critical tables out of the public schema, apply least privilege to the anon role, and audit production bundles and the Service Worker regularly.