Realtime sends private rows to subscribers

ExplainWhat it is

Supabase Realtime can stream every insert, update and delete on a table to subscribed browsers ("Postgres Changes"). A table takes part when it is in the supabase_realtime publication, which is what the dashboard's Realtime switch does. Before sending a change, Realtime checks whether each subscriber may read that row under the table's SELECT policies, using the subscriber's own token.

So a stream is exactly as private as the read policy. PL-016 means a published table holds private rows and its read policy lets the wrong people through (PL-001 or PL-002), or row level security is off (PL-008). Then anyone can open a channel with your public key and receive new messages, orders or bookings as they happen, without ever querying the table.

Delete events are a special case: Postgres can't check a policy against a row that no longer exists, so they go to every subscriber, and when row level security is on they carry only the primary key. Broadcast and Presence channels have their own authorization and aren't covered here.

CauseWhy AI builders produce it

Chat, notifications and live dashboards are popular requests, and the fix for "messages don't update live" is to switch Realtime on for the table. The read policy was usually written earlier and loosely, often to authenticated using (true), because during development every user was the same test account.

ExploitExample of vulnerable code

Simplified from the patterns we see in AI-built apps. Synthetic: not taken from any real app.

create table public.messages (
  id bigint generated always as identity primary key,
  sender_id uuid not null references auth.users (id),
  recipient_id uuid not null references auth.users (id),
  body text not null,
  created_at timestamptz not null default now()
);
alter table public.messages enable row level security;

create policy "Signed-in users can read messages"
  on public.messages for select to authenticated using (true);

-- Every new message now streams to every signed-in subscriber
alter publication supabase_realtime add table public.messages;

// Any signed-in user, in the browser console of your app
supabase
  .channel('anything')
  .on('postgres_changes',
      { event: 'INSERT', schema: 'public', table: 'messages' },
      (payload) => console.log(payload.new))  // other people's messages
  .subscribe();

CheckCheck it yourself

-- 1. Tables published to Realtime, and whether RLS is on
select pt.schemaname, pt.tablename, c.relrowsecurity as rls_on
from pg_publication_tables pt
join pg_namespace n on n.nspname = pt.schemaname
join pg_class c on c.relnamespace = n.oid and c.relname = pt.tablename
where pt.pubname = 'supabase_realtime';

-- 2. Their read policies: Realtime sends a row to whoever these let read it
select tablename, policyname, roles, qual
from pg_policies
where schemaname = 'public' and cmd in ('SELECT', 'ALL')
  and tablename in (select tablename from pg_publication_tables
                    where pubname = 'supabase_realtime');

Any published table with RLS off, or with a read policy that doesn't mention the user, is streaming to more people than you think. Test those tables with the PL-001 and PL-002 queries.

FixThe fix

Fix the read policy, and the stream fixes itself. If nothing in the app listens to the table, take it out of the publication instead.

drop policy "Signed-in users can read messages" on public.messages;
create policy "Participants read their messages"
  on public.messages for select to authenticated
  using ((select auth.uid()) in (sender_id, recipient_id));

-- or, if nothing subscribes to this table:
-- alter publication supabase_realtime drop table public.messages;

A client-side filter: 'recipient_id=eq.' + user.id on the subscription saves bandwidth, but it is not security: the subscriber writes the filter.

PatchLabs doesn’t write this fix yet. Review the SQL with your engineer and add it as a new migration.

ProveHow PatchLabs will test it

When this check ships, the Lab will run it the way it runs PL-001 to PL-008 today: rebuild your database from supabase/migrations in a disposable Postgres, seed fake rows for two users, and try the exploit as an anonymous visitor, a signed-in stranger and the owner. Until then, the self-check above is the test.

IntentWhen the pattern is intended

A public feed or a live scoreboard: if the rows are meant to be public, so is their stream. The question is always the read policy.

RateWhy it’s rated high

High: private data is delivered the moment it's created, with no query to notice. It needs a read-policy problem first, which carries its own severity; Realtime adds speed and silence.

See alsoRelated findings

Guides

• Supabase Realtime security: keep private rows out of subscriptions

Last reviewed 10 Nov 2026. Finding IDs are stable: link to them freely. Spotted a mistake? Tell us.