Supabase shipped v2.117.3-canary.0 on October 2, bumping a next dependency to patch a remote code execution vulnerability located in the realtime-js example code, according to the release notes posted on GitHub. That is the whole confirmed fact set. The notes do not specify a CVE identifier, an affected version range, or whether the flaw was ever exploited. They do not say whether the vulnerable code shipped in any production package or stayed confined to example or demo material bundled with realtime-js.
The distinction between example code and library code matters here, and it is the first thing to check. Example code in SDK repositories often exists to demonstrate usage patterns in documentation or quickstart guides, not to run in production deployments. If that is the case here, exposure may be limited to developers who copied demo code directly into live services, a known but hard-to-quantify pattern in client-side SDKs. Supabase's notes do not confirm or rule out that scenario, so operators cannot yet assume the blast radius is small.
For on-call engineers, the immediate task is inventory, not patching reflexively. Pull every service that imports supabase-js or realtime-js and check whether any copied code resembles the official examples, particularly around realtime channel setup or websocket handling, since RCE bugs in example code usually trace back to unsafe eval patterns or unvalidated input passed into dynamic execution. Canary tags carry less testing than stable releases, so teams running canary builds in production, intentionally or by dependency drift, face different risk than teams pinned to stable supabase-js versions. Check lockfiles now, not after a stable release lands.
The next dependency bump itself is worth separate attention. A bump inside a JavaScript SDK repository, rather than a patch to realtime-js's own code, suggests the vulnerability may trace to a transitive dependency rather than Supabase's first-party logic. That distinction affects remediation speed: fixing a transitive dependency often means waiting for upstream next releases to stabilize, while a first-party fix can ship on Supabase's own timeline. The notes do not clarify which next version introduced or resolved the issue, so teams cannot yet confirm whether simply upgrading next independently of supabase-js would have mitigated exposure.
What stays unresolved is severity. No CVSS score, advisory link, or exploit report accompanies the release notes, and GitHub's canary tag format implies this fix has not yet reached a stable, broadly tested release. Platform operators should treat canary as a signal to start review, not a signal to deploy. The six-day gap, if any, between this canary and a stable v2.117.3 release will determine how long teams can reasonably wait before acting. Until Supabase publishes a stable tag or an advisory with more detail, the safest move is auditing for copied example code today.