CVE-2026-48495 is an OAuth state parameter abuse that enables lateral movement between workspaces in TypeBot. The vulnerability stems from embedding workspace identity data (workspaceId, typebotId, blockId) directly into the OAuth state parameter as base64-encoded JSON, then trusting this data on the callback without cryptographic integrity verification. When a user initiates a Google Sheets OAuth flow, an attacker can modify these values in the state parameter to attach their own Google Sheets credentials to a victim workspace instead of the legitimate user's credentials.
The critical failure is architectural, not merely implementation-level. The OAuth state parameter is designed as an opaque CSRF correlation handle — it should contain no authorization-relevant data. TypeBot used it as a routing token, which inverted its purpose: the parameter meant to protect the flow became the attack vector. Worse, the callback route is authenticated but lacks per-resource authorization checks, creating a situation where proving your identity is sufficient to modify any workspace rather than just your own.
What makes this CVE more severe than its CVSS 7.1 suggests is the persistence of compromise. Unlike session hijacking with a 24-hour window, the attacker who successfully modifies the state parameter establishes a sticky foothold — their Google Sheets credentials remain attached to the target workspace indefinitely, surviving token refreshes and re-authentication cycles. There is no active session to revoke. The credential lives in TypeBot's workspace context, not in your Google account's OAuth dashboard where you would normally audit authorized apps. This creates two layers of obscurity: the attacker exits after a single request, and the credential is invisible to standard audit processes.
Your immediate priorities: first, verify whether your TypeBot deployment is on version 3.17.0 or later. Second, audit every Google Sheets OAuth integration across all workspaces in your deployment — look for credentials you don't recognize, particularly those attached by users who should not have had access to those workspaces. This audit is critical because the patch in 3.17.0 fixes the vulnerability but does not retroactively revoke credentials already attached by an attacker. Third, determine what integrity mechanism 3.17.0 implemented — HMAC signing of the state parameter, server-side session-to-state binding, or explicit authorization checks (or some combination). If the fix only adds HMAC signing without authorization checks, other code paths may still permit lateral movement. If it only adds authorization checks without cryptographic integrity, the state parameter manipulation vector remains exploitable.