Supabase Realtime Presence Policy Bypass: What App Builders Should Check

On June 25, 2026, Supabase published GHSA-rcr8-2525-4r7p, also tracked as CVE-2026-62247. The advisory describes an authorization failure in private Realtime channels: a signed-in member allowed to write Presence data, but explicitly denied permission to read it, could still receive presence_diff messages containing other members' metadata.

This is a confidentiality issue in the Realtime server. It is not a Supabase Auth bypass, does not expose postgres_changes row data, and does not let the member alter another user's Presence metadata. Supabase Realtime 2.111.2 contains the fix.

What happened

Supabase Realtime Presence lets channel members announce application-defined state such as whether they are online, which document they are viewing, or a location selected by the application. Private channels can use authorization policies to decide separately who may read and write that state.

In Realtime 2.111.1, the initial Presence state respected presence.read, but later presence_diff broadcasts followed a fast delivery path that did not carry the subscriber's Presence read decision. A member who could join the private channel and write Presence data could therefore receive subsequent metadata updates even when a policy denied that member presence.read.

The upstream regression test models the important boundary directly: one private-channel member may read and write Presence, while another may read broadcasts and write Presence but is denied Presence reads. The second member must not receive the first member's presence_diff. That separation failed before the fix.

Version 2.111.2 carries the presence.read result in subscriber metadata and checks it when dispatching each presence_diff. It also handles the case where Presence is enabled after the channel is joined by authorizing the read operation before delivery.

I reviewed the official advisory, the Realtime 2.111.1 and 2.111.2 source tags, the fixing change, and its integration regression tests. I did not run an exploit or test any hosted or production Supabase project.

Who is affected

The official advisory lists supabase/realtime versions through 2.111.1 as affected and 2.111.2 or later as patched. Exposure requires all of these conditions:

The application uses an affected Supabase Realtime server.
It uses a private channel with Presence enabled, either at join time or later through a Presence track operation.
At least one channel member can write Presence data but is denied presence.read.
Other members publish metadata that the application treats as restricted.

The advisory highlights configurations where Presence visibility is narrower than broadcast visibility—for example, members may chat while only administrators may see the roster. If every member has the same Presence read visibility, there is no differential policy for this flaw to bypass.

The exposed data is whatever the application puts in Presence metadata. Depending on the product, that might include user identifiers, online status, typing state, a live location, or a "currently viewing" roster. Applications should not assume that all Presence metadata is harmless simply because it is ephemeral.

The affected package is the Realtime server, supabase/realtime. Seeing @supabase/realtime-js in a web application's lockfile does not by itself prove that its Supabase project runs an affected server version or uses the vulnerable policy shape.

Was VibeScan affected?

The VibeScan repository uses Supabase Auth and database APIs. Its lockfile also contains @supabase/realtime-js as a transitive dependency of @supabase/supabase-js, but a repository-wide search found no application calls to Supabase channel() or Presence APIs. The client package version does not identify the deployed Realtime server version.

That means the vulnerable Presence path is not evidenced in the VibeScan application code reviewed for this post. However, the connected Supabase project's deployed Realtime server version and authorization-policy inventory could not be queried, so their state remains unknown. No runtime exploit or production test was authorized or performed. We therefore are not claiming that production was tested or that historical exposure has been ruled out.

How to check safely

First, determine whether your application uses Realtime Presence. Search source code and generated clients for channel creation, Presence tracking, and Presence state reads:

rg '\.channel\(|\.track\(|presenceState\(|presence:' .

Next, identify the Realtime server version. Self-hosted operators should inspect the pinned supabase/realtime container or release tag and upgrade if it is 2.111.1 or earlier. Hosted Supabase users should use the project dashboard or Supabase support to confirm remediation if the platform does not expose the server version. Do not infer the server version from @supabase/realtime-js.

Finally, review private-channel authorization policies. Look specifically for a role or member that can join the channel and write Presence data while presence.read is denied. Then inventory every field placed in Presence payloads and classify whether disclosure to that member would matter.

A safe regression check should use a disposable project with two test identities:

Alice may read and write Presence.
Mallory may join the same private channel and write Presence, but her policy explicitly denies Presence reads.
Alice publishes a non-sensitive marker as Presence metadata.
Mallory must receive neither the initial presence_state nor Alice's later presence_diff.

Run that check only in an environment you control. Do not place real user data in the test payload, and do not test another organization's project without authorization.

Immediate mitigation and durable fix

Upgrade the Realtime server to 2.111.2 or later. For self-hosted deployments, pin the corrected image or release, redeploy it, and verify the running version rather than updating only a configuration file.

If an immediate server upgrade is impossible, remove the risky permission differential until the fix is deployed: do not allow a member to write Presence while denying that same member Presence reads in a channel carrying restricted metadata. Treat that as a temporary policy simplification, not a substitute for upgrading.

As additional defense in depth:

Keep sensitive or durable data out of Presence payloads.
Send only the minimum metadata needed for the user experience.
Add a two-identity regression test for both Presence enabled at join and Presence enabled later through tracking.
Review logs and application telemetry for unexpected Presence visibility during the affected period, while recognizing that ordinary Realtime logs may not prove which metadata a client rendered.

What VibeScan detects today

VibeScan does not currently detect this server-side Presence authorization condition. Its dependency analysis can inspect resolved application packages, but the @supabase/realtime-js client version does not reveal the deployed supabase/realtime server version or prove that a private channel has the vulnerable read/write policy differential.

Confirming this issue requires server-version evidence plus an authorized policy and runtime review. Until VibeScan has a tested check for those facts, it should not claim to identify CVE-2026-62247 from a URL or client lockfile alone.

Primary sources

Last reviewed: October 5, 2026.