Supabase shipped supabase-js version 2.117.3 on October 7, 2026, and the changelog entry for that release lists a dependency bump described as a patch for an RCE affecting a realtime-js example. That phrase, RCE, is the kind on-call engineers do not scroll past. The changelog entry itself is confirmed. The underlying security advisory has not been opened, so the affected package, the CVE identifier if one exists, and the exploit path are all unknown at this point.
The word example matters here, and it is doing real work in that sentence. Realtime-js ships sample or demo code alongside its library in many open source projects, and vulnerabilities in example code do not always touch the code paths that production apps actually import and run. But sometimes they do, particularly when example code gets copied into starter templates or quickstart docs that teams paste directly into production. Nothing in the changelog extract says which case this is. Until the advisory is open, there is no way to confirm whether this bump matters to any given deployment or whether it is a hygiene fix with no real-world exposure.
Platform operators running supabase-js in production now have a specific, narrow decision to make rather than a vague one: check whether the current pinned version predates 2.117.3, and if so, pull the actual advisory before deciding whether to patch on an emergency basis or roll it into the next normal release cycle. The changelog entry alone does not establish severity, exploitability, or whether any realtime-js code reachable from a typical client integration is affected. Treating a one-line changelog mention as equivalent to a scored CVSS advisory is the mistake to avoid here. It might be nothing. It might not be.
What should happen next is straightforward and unglamorous. Someone with access needs to open the linked advisory on GitHub, read the affected version range, and cross-reference it against whatever lockfile or package manifest is running in each service that imports supabase-js or realtime-js directly. If the example code in question is not imported anywhere in production, the exposure is effectively zero regardless of severity score. If it is imported, even indirectly through a starter template someone forked eighteen months ago, the calculus changes fast, and that is the kind of thing dependency scanning tools often miss when the vulnerable code lives in an examples directory rather than the main package.
Supabase has not published, as of this writing, a separate security bulletin beyond the changelog line itself, at least not one reflected in this extract. That absence is worth noting rather than filling in. Companies sometimes follow a terse changelog entry with a fuller writeup once an advisory is assigned a formal identifier, and sometimes they do not, especially for fixes judged low severity after initial triage. Either way, the changelog confirms the bump happened on October 7. It does not confirm impact, does not confirm exploitability outside the example code, and does not confirm whether any customer-facing deployment was ever at risk.
The immediate, checkable fact is this: 2.117.3 is out, dated October 7, 2026, and it is the version to diff against whatever is currently pinned in dependency manifests. Everything past that line item, severity, blast radius, exploit mechanics, sits behind an advisory nobody has opened yet.