Supabase Realtime CVE-2026-62247

Exploitation requires a private Supabase Realtime channel configured with a differential per-extension RLS policy where the client is granted presence.write but explicitly denied presence.read; the attacker must hold a valid authenticated WebSocket session (PR:L) on that channel and enable presence tracking. Limiting factors: this is a non-default asymmetric configuration - deployments with uniform presence visibility are not affected, postgres_changes data is never exposed, and disclosure is confined to application-defined presence metadata (location, online-status, roster, viewing, typing). Only versions prior to 2.111.2 are vulnerable.

This is a moderate, tightly-gated authorization flaw (CWE-863) with no signals of active or opportunistic exploitation: no CISA KEV listing, no EPSS score supplied, and no public proof-of-concept identified - so this is 'no public exploit identified at time of analysis.' The vendor CVSS of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) captures network reach and low attacker privilege but, in my view, overstates confidentiality impact: the leaked data is limited to other members' presence metadata (application-defined location, online-status, roster, viewing, typing), not database rows - the description explicitly notes postgres_changes row data is unaffected - which argues for C:L rather than C:H. More importantly, the real-world risk is bounded by a specific non-default precondition: the tenant must have configured a differential RLS policy on a private channel that grants presence.write while denying presence.read. Deployments with uniform presence visibility 'have no differential' and are simply not affected. There is no SSVC decision data, no KEV, and no EPSS in the input to weigh; the honest read is 'low real-world risk despite a mid-range CVSS,' driven by the narrow configuration gate and limited data exposure rather than any exploitation evidence. This is patch-in-normal-cycle, not a fire drill.

A tenant configures a private Supabase Realtime channel with an asymmetric authorization policy: a given client is granted presence.write (may broadcast its own presence) but is explicitly denied presence.read. Because the pre-2.111.2 write probe used INSERT ... RETURNING *, Postgres enforced the SELECT (read) policy on the returned row and conflated write with read, so the authenticated client still receives presence_diff messages exposing other members' location, online-status, roster, and typing metadata. No public exploit code exists; exploitation requires a valid authenticated WebSocket session on the channel.