Google Gemini Live API Vulnerability Allows Tool Injection and Code Execution
A flaw in Google's Gemini Live API, stemming from misconfigured ephemeral tokens, allows attackers to inject tools and execute code within AI voice sessions.
A security vulnerability has been identified in the implementation of Google's Gemini Live API, enabling attackers to hijack browser-based AI voice sessions and execute unauthorized code. The flaw, discovered by security researcher Alvin Ferdiansyah, arises from a misconfiguration of ephemeral tokens used for client-side integrations. Gemini Live API facilitates real-time voice interactions through persistent WebSocket connections, offering endpoints for both server-to-server and browser-based clients. The latter, BidiGenerateContentConstrained, is intended to use short-lived ephemeral tokens to prevent API keys from reaching the client.
During a session's initiation, a client sends a setup frame that defines parameters such as the AI model, system instructions, and available tools, including code execution, web search, and URL fetching. Crucially, these fields are optional. If the backend does not explicitly restrict them, the server accepts whatever the client sends. Ephemeral tokens can be minted with a live_connect_constraints field to lock down these parameters. However, if this field is omitted during token minting, the server defaults to accepting client-controlled session configurations.
Compounding the issue, Google's official reference repository for the Gemini Live API examples includes a server implementation that mints tokens without populating the live_connect_constraints field. This means that any developer building upon this reference implementation inherits the vulnerability by default. The researcher found that the token-minting process in the example server omitted the bidi_generate_content_setup field, confirming the session was unconstrained despite the endpoint's name.
Ferdiansyah demonstrated the exploit by obtaining a valid token with minimal effort and connecting directly to the WebSocket. By sending a custom setup frame, the researcher was able to override the system instructions and enable code execution. The server confirmed acceptance of these changes, and a subsequent Python payload was successfully executed within Google's gVisor sandbox environment. To validate the execution, a nonce-based proof involving SHA-256 hashes and the sandbox's kernel version was used, confirming genuine code execution.
The gVisor sandbox, while limiting the potential damage by preventing outbound network access and host escapes, still allows for compute resource abuse and reconnaissance. Attackers could potentially leverage this to consume billed API resources indefinitely through token renewal. The primary impact is the unauthorized execution of code and potential for reconnaissance within the sandboxed environment, rather than direct system compromise.
The fix for this vulnerability is straightforward: developers must populate the live_connect_constraints.bidi_generate_content_setup field during token minting. This field should specify the intended model, system prompt, and an empty tools array, effectively locking down all session parameters server-side and closing the injection vector.
Any application utilizing ephemeral tokens for browser-facing Gemini Live integrations that does not implement this constraint is likely susceptible to the same class of vulnerability. This highlights the importance of secure implementation practices, even when using reference code, and the need for rigorous security validation of AI service integrations.
This vulnerability underscores the ongoing challenges in securing AI platforms and their integrations, particularly concerning the control and validation of user-provided inputs and configurations within complex systems.