Large banks and Google itself are among the enterprises vulnerable to data exfiltration via Gemini, using nothing more than API keys Google recommended making public, Truffle Security said on Wednesday.
The security company published details of what it reported as a privilege escalation, after the standard 90-day disclosure window. It said that by early February, Google was still working on a root-cause fix for what it eventually classified as a tier 1 vulnerability – having at first filed the report under "intended behaviour".
Google itself did not respond to questions from The Stack before publication.
See also: Five Eyes issues urgent warning over Cisco SD-WAN 0day exploitation
Google historically treated API keys as customer identifiers, explicitly telling developers to embed them in public-facing web sites for use in scenarios such as embedding Google Maps.
That continues to be best practice in Google documentation, alongside a warning that unrestricted keys are potentially dangerous. But unrestricted keys are the default behaviour said Truffle, and it was standard to activate Gemini on existing projects using existing keys.
Keys as passwords
With Gemini, though, the API key acts as a password, making for scenarios where public credentials can easily be upgraded to sensitive access tokens silently, said Truffle.
"You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you."
With a Gemini API key, you can request a list of uploaded documents, then ask for a description of contents, or search for embedded secrets.
Thousands exposed
In a scan in November, Truffle said, it found 2,863 publicly exposed keys that were activated on Gemini. Exposed organisations included security vendors, major banks, and Google itself.
In Google's case, it said, "a key that was deployed years ago for a completely benign purpose had silently gained full access to a sensitive API without any developer intervention."
Google appears to be blocking known leaked keys from Gemini access, but it is not clear if it is actively scanning for misuse beyond unusual billing patterns for Gemini activity.
Update | Google provided a statement after publication of this article. It reads, in full:
"We are aware of this report and have worked with the researchers to address the issue. Protecting our users’ data and infrastructure is our top priority. We have already implemented proactive measures to detect and block leaked API keys that attempt to access the Gemini API.”
See also: 28 days later, Copilot is probably not ingesting "confidential" email anymore
Sign up for The Stack
Interviews, insight, intelligence, and exclusive events for digital leaders.
No spam. Unsubscribe anytime.