A security flaw in how developers implement Google’s Gemini Live API allows attackers to hijack browser-based AI voice sessions, override system prompts, and trigger unauthorized code execution all through a token misconfiguration that traces back to Google’s own reference implementation.
Security Researcher Alvin Ferdiansyah observed that Gemini Live API powers real-time voice assistants through persistent WebSocket connections. Two endpoints exist: BidiGenerateContent, which uses a raw API key and is meant for server-to-server calls, and BidiGenerateContentConstrained, designed for browser clients using short-lived ephemeral tokens so the API key never reaches the client.
Every session begins with a client-sent setup frame defining the model, system instructions, and available tools including code execution, Google Search, and URL fetching. Critically, every field in this frame is optional, meaning anything not explicitly locked by the backend remains under client control.
Ephemeral tokens are minted via a backend call that can include a live_connect_constraints field, specifically bidi_generate_content_setup, to lock the model, system prompt, and tools.
Without it, Google’s own documentation confirms the server accepts whatever the client sends in its setup frame. Authentication and authorization become fully decoupled: a valid token proves the client was authorized to connect, not what it’s authorized to do.
Compounding this, Google’s official reference repository (google-gemini/gemini-live-api-examples) ships a server.py that mints tokens using only uses, expire_time, and new_session_expire_time—omitting live_connect_constraints entirely. Teams building from this reference inherit the vulnerability by default.
Gemini Live Voice Session Flaw
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. Self-registration required only an email and OTP, taking under two minutes to obtain a valid token.
Connecting directly to the WebSocket, the researcher sent a custom setup frame overriding the system instruction and enabling codeExecution. The server responded with setupComplete, confirming acceptance. A subsequent Python payload executed successfully inside Google’s gVisor sandbox.
To rule out hallucinated output, the researcher used a nonce-based proof: computing SHA-256 hashes bound to a random value and the sandbox’s runtime kernel version, which cannot be pre-computed without actual execution. The hashes verified, confirming genuine code execution.
The gVisor sandbox prevents outbound network access and host escape, limiting damage to sandboxed compute abuse and reconnaissance rather than lateral movement. Still, unrestricted access lets any registered user consume billed API resources indefinitely via token renewal.
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 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.
Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.
