Supabase Realtime: Expired JWTs with string exp are accepted by REST broadcast authorization
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 2.103.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Supabase Realtime, the WebSocket service that provides Broadcast, Presence, and Postgres Changes features, is affected. An attacker holding an expired token with a string-encoded expiration claim can send messages to subscribers through the REST broadcast endpoint, which can have application-specific consequences depending on what the subscribers do with those messages.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Supabase Realtime provides Broadcast, Presence, and Postgres Changes via WebSockets. Prior to version 2.103.1, the REST broadcast endpoints accept an expired JWT when the exp claim is encoded as a JSON string instead of a JSON number. The same route rejects an expired integer exp token signed with the same tenant secret. The accepted request returns 202 and emits the broadcast to subscribers. This could allow an unauthenticated attacker can broadcast realtime messages to subscribers. The attack can be performed via the Internet/only from within the supabase project. The impact of broadcasting messages to subscribers is application specific. This issue has been patched in version 2.103.1.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- supabase realtime
fixed in 2.103.1