Critical Gemini Live Voice flaw lets attackers inject tools via misconfigured tokens

Key Takeaways

• A critical security flaw impacts implementations of Google’s Gemini Live API, allowing attackers to inject malicious tools and execute arbitrary code.
• The vulnerability stems from misconfigured ephemeral tokens, which fail to enforce server-side constraints on AI voice sessions.
• Attackers can hijack browser-based AI sessions, override system prompts, and trigger unauthorized code execution within Google’s gVisor sandbox.
• The flaw is exacerbated by Google’s own reference implementation, which ships with the misconfiguration by default.
• A fix involves adding a specific field to the token-minting process to lock session parameters.

A significant security vulnerability has been identified within applications leveraging Google’s Gemini Live API, enabling malicious actors to compromise AI voice sessions. This flaw permits attackers to inject unauthorized tools, manipulate system prompts, and execute arbitrary code by exploiting a misconfiguration in ephemeral access tokens. The issue originates from Google’s official reference implementation, leading many developers to inadvertently deploy vulnerable systems.

Security researcher Alvin Ferdiansyah intercepted and analyzed how the Gemini Live API facilitates real-time voice interactions through persistent WebSocket connections. The API offers two primary endpoints: BidiGenerateContent, intended for server-to-server communications using a raw API key, and BidiGenerateContentConstrained, designed for client-side browser use with short-lived, ephemeral tokens to prevent direct exposure of the API key.

Every Gemini Live session initiates with a setup frame sent by the client, specifying the AI model, system instructions, and available tools, which can include code execution, Google Search integration, and URL fetching. Crucially, all fields within this initial setup frame are optional. This means that any parameter not explicitly locked down by the backend server remains under the client’s control, creating a critical security loophole.

Ephemeral tokens are generated via a backend call that can incorporate a live_connect_constraints field, specifically bidi_generate_content_setup. This field is designed to enforce server-side restrictions on the AI model, system prompt, and available tools. Without this constraint, Google’s documentation confirms that the server will accept whatever the client transmits in its setup frame. Consequently, authentication and authorization become completely decoupled; a valid token merely confirms the client’s permission to connect, not its authorized actions within the session.

Compounding this issue, Google’s official reference repository, google-gemini/gemini-live-api-examples, provides a server.py script that mints tokens using only uses, expire_time, and new_session_expire_time. It entirely omits the crucial live_connect_constraints field. As a result, development teams building solutions based on this reference implementation inherently inherit this vulnerability.

Gemini Live Voice Session Flaw Exploitation

During his evaluation of a consumer voice assistant, Alvin Ferdiansyah captured the token-minting response via Burp Suite. He discovered that despite connecting to the “Constrained” endpoint, the response lacked the bidi_generate_content_setup field, indicating an unconstrained session. The researcher noted that obtaining a valid token required only an email and a one-time password (OTP), a process that took less than two minutes.

By directly connecting to the WebSocket, Ferdiansyah sent a tailored setup frame that overrode the default system instructions and enabled codeExecution. The server acknowledged this with a setupComplete response. A subsequent Python payload was then successfully executed within Google’s gVisor sandbox environment.

To definitively prove genuine code execution and rule out any potential “hallucinated” AI output, the researcher employed a nonce-based verification method. This involved computing SHA-256 hashes bound to a random value and the sandbox’s runtime kernel version. Since these hashes cannot be pre-computed without actual execution, their verification confirmed successful code execution within the sandbox.

While Google’s gVisor sandbox is designed to prevent outbound network access and host escape, thereby limiting the potential damage to sandboxed compute abuse and reconnaissance, the unrestricted access still poses significant risks. Any registered user could continuously consume billed API resources indefinitely through token renewal, leading to potential financial impact for the service provider.

Resolution and Mitigation

The solution to this vulnerability is straightforward, requiring a single modification to the token-minting call. Developers must populate the live_connect_constraints.bidi_generate_content_setup field with the intended AI model, system prompt, and an empty tools array. This action effectively locks all session parameters on the server side, completely mitigating the injection path.

Any product utilizing ephemeral tokens for browser-facing Gemini Live integrations that fails to implement this critical field is likely exposed to the same vulnerability class.

What You Should Do

• Developers: Immediately review your Gemini Live API token-minting logic. Ensure that the live_connect_constraints.bidi_generate_content_setup field is properly populated to lock down session parameters (model, system prompt, tools) on the server side.
• Organizations: Audit all applications that integrate with Google’s Gemini Live API, especially those using Google’s reference implementation (google-gemini/gemini-live-api-examples), to confirm that tokens are being generated with appropriate constraints.
• Security Teams: Monitor for unusual API usage patterns or unexpected tool activations in applications utilizing Gemini Live API. While gVisor limits direct host escape, unauthorized resource consumption remains a risk.
• Update Reference Implementations: If you’ve built on Google’s provided examples, pull the latest versions or manually apply the fix to your token generation logic.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.