Description

Supabase Realtime provides Broadcast, Presence, and Postgres Changes via WebSockets. Prior to 2.111.2, Realtime authorization does not correctly honor the per-extension presence.read row-level security policy when a private-channel client is allowed presence.write but explicitly denied presence.read. Under that differential policy, the client can receive presence_diff messages containing other members' presence metadata, including application-defined location, online-status, roster, viewing, or typing information. Deployments with uniform presence visibility have no differential, and postgres_changes row data is unaffected. This issue is fixed in version 2.111.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-21T20:17:27.470Z",
  "pubdate": "2026-09-21T20:17:27.470Z",
  "executiveSummary": "A broken access control vulnerability exists within Supabase Realtime prior to version 2.111.2, specifically concerning the handling of Presence feature authorization.\nThe vulnerability manifests when Row-Level Security (RLS) policies for 'presence.read' and 'presence.write' are configured differentially for private channels.\nAn authenticated attacker possessing 'presence.write' permissions—but explicitly denied 'presence.read' access—can bypass authorization checks to receive 'presence_diff' messages.\nThis unauthorized data exposure grants the attacker access to sensitive metadata belonging to other channel participants, including location, online status, roster information, and application-defined activity indicators.\nThe vulnerability affects deployments utilizing granular, non-uniform RLS policies for presence visibility; however, Postgres Changes and Broadcast features remain unaffected.\nThe risk implication is a compromise of user privacy and internal application state visibility, as attackers can passively exfiltrate metadata of other users connected to the same private channel despite explicit read prohibitions.",
  "technicalDetails": "The vulnerability resides in the Supabase Realtime WebSocket communication layer, specifically within the authorization logic responsible for enforcing RLS policies on the Presence extension.\nThe root cause is a flaw in the policy evaluation engine where the system fails to correctly honor a negative authorization (deny) for the 'presence.read' action when a client is already authorized for 'presence.write'.\nIn a secure implementation, Realtime should evaluate 'presence.read' independently for every subscriber. Instead, the implementation incorrectly correlates write-level privileges with read-level visibility during the delivery of 'presence_diff' broadcast messages.\nThe attack flow begins with a client establishing a WebSocket connection to the Supabase Realtime server. The client authenticates and joins a private channel configured with disparate RLS policies: granting 'presence.write' to allow the client to announce their own status, but explicitly denying 'presence.read' to restrict the client from viewing others.\nUpon a state change in the channel (e.g., another user joining or updating their presence), the server generates a 'presence_diff' payload intended for authorized subscribers. Due to the failure in authorization verification, the server incorrectly includes the malicious client in the distribution list for this sensitive metadata.\nThe client, despite lacking the required permissions to perform a presence read, receives the full 'presence_diff' packet. The payload typically contains structured metadata, including keys for 'location', 'online_status', 'roster', 'viewing', and 'typing' status.\nBecause the server's subscription management module assumes that valid session tokens and write permissions imply a authorized status for the channel's general state, it fails to perform a secondary, granular RLS check for read actions before egressing the packet.\nThis vulnerability is restricted to versions of Supabase Realtime prior to 2.111.2. The exposure is limited to clients who already possess valid authentication and write-access to the specific private channel, meaning it cannot be exploited by unauthenticated or unauthorized remote actors. The impact is strictly limited to the unauthorized disclosure of transient presence metadata and does not allow for unauthorized access to Postgres database rows or arbitrary code execution."
}