A newly disclosed vulnerability affects web applications that build real-time voice features on Google’s Gemini Live API.
Security Researcher Alvin Ferdiansyah found that the flaw stems not from a bug in Google’s code, but from a documentation-and-reference-implementation gap that leads developers to ship ephemeral tokens with no security constraints.
Gemini Live API powers real-time voice assistants through persistent WebSocket sessions. Two endpoints exist: BidiGenerateContent, a raw API-key endpoint meant for server-to-server calls, and BidiGenerateContentConstrained, designed for browser clients that authenticate with short-lived tokens, so the API key never reaches the client.
Gemini Live API Vulnerability
Every session opens with a client-sent setup frame defining the model, system instructions, and available tools.
Critically, every field in this frame is optional, and any field not explicitly locked by the backend’s token remains under client control. Available tools include Python code execution, live web search, and outbound URL fetching.
Tokens are minted via a live_connect_constraints field that, when populated with a bidi_generate_content_setup object, locks the model, system prompt, and tools server-side.
Google’s own documentation confirms that when this field is absent, the effective setup message is instead taken from whatever the client sends over the connection, meaning the server accepts unrestricted input.
The gap traces back to Google’s own reference implementation. Alvin Ferdiansyah’s research found this isn’t a developer oversight in isolation, teams building browser-facing Gemini Live integrations by following the official example code inherit the vulnerability by default, since the sample token-minting call omits live_connect_constraints entirely.
During testing of a consumer voice assistant, Alvin Ferdiansyah intercepted the token-mint response via Burp Suite and found no bidi_generate_content_setup field, confirming the session was unconstrained despite the “Constrained” endpoint name.
Connecting directly and sending a custom setup frame that overrides the system instruction and enables code execution returned a successful setup completion, confirming that the server imposed no restrictions.
To rule out the model merely simulating plausible output, a nonce-binding protocol was used: computing sha256(nonce) locally and comparing it against a sandbox-computed hash bound to the sandbox’s own kernel version string, a value unknowable in advance.
Matching hashes confirmed genuine code execution inside Google’s gVisor-based sandbox. The gVisor sandbox limits damage: no outbound network access, no persistence, no path to the host application’s infrastructure.
But attackers gain unlimited free compute billed to the victim’s API account, with token renewal easily automated given no visible rate limiting on the mint endpoint.
The fix requires a single addition to the token-minting call: populating live_connect_constraints.bidi_generate_content_setup with the intended model, system prompt, and an empty tools array.
This locks all session parameters on the server side, closing the injection path entirely. Any product using ephemeral tokens for browser-facing Gemini Live integrations without this field is likely exposed to the same class of vulnerability.
Organizations running voice assistant features on Gemini Live should audit their token-mint responses for the presence of bidi_generate_content_setup immediately.
Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.
