In Google AI Studio, Google documentation encourages to deploy vibecoded apps with an open proxy that allow equivalent AI billing abuse - giving the impression that the API key were secure because it is behind a proxy. Even an app with 0 AI features exposes dollars-per-query video models unless the key is manually scoped. Vulnerable apps (all apps deployed from AI Studio) are easily found by searching Google, Twitter or Hacker News. https://github.com/qudent/qudent.github.io/blob/master/_post...
cvoss
The headline really undersells the point and reads like clickbait. "Things were fine, then she turned the tables. Watch what happens next." I avoided even opening this article several times out of distaste for the headline. It should be something like "Google leaves your Gemini data vulnerable to non-secret API key exploit."
show comments
devsda
> Leaked key blocking. They are defaulting to blocking API keys that are discovered as leaked and used with the Gemini API.
There are no "leaked" keys if google hasn't been calling them a secret.
They should ideally prevent all keys created before Gemini from accessing Gemini. It would be funny(though not surprising) if their leaked key "discovery" has false positives and starts blocking keys from Gemini.
show comments
oompty
Ohh so that's how that happened. I had noticed (purely for research purposes of course) that some of Google's own keys hardcoded into older Android images were useable for Gemini (some instantly ratelimited so presumably used by many other people already but some still usable) until they all got disabled as leaked like two months ago. They also had over time disabled Gemini API access on some of them over them beforehand.
show comments
warmedcookie
What's frustrating is that a lot of these keys were generated a long time ago with a small amount of GCP services that they could connect to. (Ex. Firebase remote config, firestore, etc.)
When Gemini came around, rather than that service being disabled by default for those keys, Gemini was enabled, allowing exploiters to easily utilize these keys (Ex. a "public" key stored in an APK file)
show comments
louison11
This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?
show comments
umairnadeem123
this is what happens when a "public" key type quietly turns into a privileged key type without forcing people to re-scope it, not really a dev mistake IMO, it's a platform design bug and google needs hard separation between publishable and secret keys or this repeats every time they ship a new API. pretty disappointed in google tbh, looked up to them for security for the longest time
Havoc
Someone on the Google subreddit did report getting a 80k bill yesterday from a Gemini key.
I’m very careful with Google and co since they’re so intent on infinite scaling access to your wallet
show comments
lastdong
This is mind-blowing, and it defies all security common sense. Changing global API keys permissions? Come on! We’re accustomed to seeing issues like this from Redmond but didn’t expect it from Google.
show comments
827a
Is the implication at the end that Google has not actually fixed this issue yet? This is really bad; a massive oversight, very clearly caused by a rush to get Gemini in customers' hands, and the remediation is in all likelihood going to nuke customer workflows by forcing them to disable keys. Extremely bad look for Google.
show comments
blinding-streak
I think this is making at least some waves in google. I literally just got an email from them with the subject "[Action Advised] Review Google Cloud credential security best practices"
A slew of recommendations, one of them being:
Disable Dormant Keys: Audit your active keys and decommission any that show no activity over the last 30 days.
(Although I don't think this even addresses the underlying issue)
vincnetas
This totally reminds me of SSN use, when initially they were just a number (not secret) to identify a person, and then suddenly people started to use them as a key for authorisation, because someone had a bright idea how to implement things fast/simple/cheap (cheap part comes at expense of others)
show comments
neop1x
Many people wanted to be able to set a spending limit on google cloud account for many years but they were unable to implement anything, always suggesting a workaround by hosting a Cloud Run function which would remove billing from a project via API https://docs.cloud.google.com/billing/docs/how-to/disable-bi...
show comments
ZiiS
Unrestricted API keys were always secrets. They are created on a page called "Keys & Credentials". The fact that Google even allows unrestricted keys to be created has been a long standing security problem. The fact their docs encouraged it remains unforgivable.
show comments
klooney
> Retroactive Privilege Expansion. 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.
Malpractice/I can't believe they're just rolling forward
show comments
semiquaver
This is just embarrassing. It doesn’t even really qualify as a security vulnerability, more like a fatal flaw in the system’s design. I can see why the team pushed back on fixing it, seems like a massive pain.
It feels like something that would happen if you outsourced planning to an LLM.
show comments
voidUpdate
> This makes sense. These keys were designed as project identifiers for billing, and can be further restricted with (bypassable) controls like HTTP referer allow-listing. They were not designed as authentication credentials.
Can't you just run up a huge bill for a developer by spamming requests with their key? I don't see how this wasn't always an issue?
show comments
taf2
Am i reading this right - it was like impossible to get an api key for gemini but actually i could have just grabbed an API key from someone's google maps site and gotten started right away?
vessenes
Woof. Impedance mismatch outcome from moving fast - the GCP auth model was never designed to work like oAI's API key model; this isn't the only pain point this year, but it's a nasty one. I'm sympathetic, except that dealing with GCP has always been a huge pain in the ass. So I'm a little less sympathetic.
evo
Can’t wait til someone makes a Gemini prompt to find these public keys and launch a copy of itself using them.
IX-103
API keys were always secrets. They control billing for heaven's sake. If you had any per-call billed APIs (like some of the voice processing APIs) enabled on the project then they're effectively keys to your pocket book. Otherwise they're a key tool to manage denial-of-service attacks.
nkrisc
So even if they fix the issue, it sounds as though you can still shoot itself in the foot by essentially being at to arbitrarily change an existing key from “not a secret” to “is a secret”?
Even if you have a key that you use for maps (not secret) someone could add the generative AI scope to it and make it now necessarily secret (even though it’s probably already publicly available)?
procaryote
Arguably, calling it a key while insisting it's a non-sensitive ID was a mistake to start with
Changing the semantics of existing non-key keys, making them actually keys is horrendous
skirge
I reported few instances last year, some companies fixed it, some other didn't even understand the problem (or ghosted me).
jacquesm
Who knew there were downsides to forcefeeding your product to an unwilling audience?
This whole Gemini roll-out has me reminded of the Google '+' days when they thought they were going to die if they didn't do social.
kevincloudsec
the credential didn't change. the permissions changed underneath it. that's the worst kind of privilege escalation because nobody has a reason to go back and audit something they were told was safe a decade ago.
bob1029
What are the chances this isn't intentional to some extent? This wouldn't be the first time we've traded downstream legal trouble for short term gains.
Making AI utilization appear to go up is the only thing that matters right now if you're in the boardroom at one of these companies. Whether or not that utilization was actually intended by the customer is entirely irrelevant. From here, the only remaining concern is mitigating legal issues which google seems to be immune to.
show comments
kelvinjps10
They said they were going to disable it for leaked keys isn't better to just disable it for leaked keys. Isn't better to make the default behavior from now on to not have access to Gemini or I misunderstood?
xpertweb
I’ve been exploring this exact problem space from the angle of extreme constraints (single-digit MB memory, no cloud assumptions).
I documented what broke first and why here, in case it’s useful:
https://github.com/nullclaw/nullclaw
chrisjj
> 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.
This destroys Google's right to pursue an unpaid "AI" bill as a debt.
Happened to me recently, I got a warning in Gemini Studio that a key leaked. I was perplexed initially and then realized what had happened. The proper fix is to limit the key to just Maps APIs. Of course even this is not so easy, as there's a long list of APIs with complicated names. It was at least limited to my domain.
habosa
This is true but also not as new as the author claims. There have been various ways to abuse Google API keys in the past (at least to abuse them financially) and it’s always been very confusing for developers.
Humphrey
Seems like the kind of bug caused by using Gemini to vibe code the GCP.
show comments
phantomathkg
> 2,863 Live Keys on the Public Internet
It will be more interesting if they scan GitHub code instead. The number terrified me. Though I am not sure how many of that are live.
show comments
0pteron
Uh what? Google maps API keys have always been separate and they have always adviced to lock it down to your domain such that others can abuse it.
gverrilla
Thousands of engineers.
Culture rot.
sandrello
Since I've never used them, how could API keys for Firebase or Maps be safe for embedding in client side code?
I mean, I get that authentication to the service is performed via other means, but what's the use of the key then?
I'm guessing it's just a matter of binding service invocations to the GCP Project to be billed, by first making sure that the authenticated principal has rights on that project, in order to protect from exfiltration. That would still be a strange use case for what gets called an "API key".
show comments
AntiDyatlov
This is so weird, this feels like an incredibly stupid bug that any average developer would've noticed, but Google is so incredibly selective with their tech screen. What exactly is the point of those if they're going to fuck up in obvious ways?
liveoneggs
it's just firebase part 2
sylware
Wait, I can get such a key and perform gemini API requests with curl? (probably limited in some ways)
stevage
I'm a bit surprised by the timeline which seems to say that:
- 6 weeks ago Google said they would fix it
- 3 weeks ago Google said they were working on it
...but we're publishing the info anyway, so everyone can go nuts with it.
show comments
selridge
Great write-up. Hilarious situation where no one (except unwieldiness) is the villain.
dakolli
Dang, another obvious reason (among many others) you shouldn't be uploading documents to any LLM client (or use them on anything important).
bpodgursky
ChatGPT writing a blog post attacking Gemini security flaws. It's their world now, we're just watching how it plays out.
show comments
the_arun
Private data should not be allowed to be accessed using public keys. That is the core problem. It is not about Google API keys are secret or not.
show comments
friendzis
Explain It Like I'm Five.
From TFA:
> Last month, a developer on your team enabled the Gemini API for an internal prototype.
> The result: thousands of API keys that were deployed as benign billing tokens are now live Gemini credentials sitting on the public internet.
Benign, deployed openly without any access restrictions whatsoever, billing tokens can be used to bill for a service under the account it is enabled for. That's the intended behavior, literally. Maps API keys are used to give your users access to Google Maps on your credit card.
What's the problem here? Yes, the defaults could have been stricter, but it's not like it costs anything to create a bunch of internal projects that do not have good-for-billing access keys floating around open internet. People moved fast, deployed LLM generated code, broke things and then blame everyone else but themselves?
In Google AI Studio, Google documentation encourages to deploy vibecoded apps with an open proxy that allow equivalent AI billing abuse - giving the impression that the API key were secure because it is behind a proxy. Even an app with 0 AI features exposes dollars-per-query video models unless the key is manually scoped. Vulnerable apps (all apps deployed from AI Studio) are easily found by searching Google, Twitter or Hacker News. https://github.com/qudent/qudent.github.io/blob/master/_post...
The headline really undersells the point and reads like clickbait. "Things were fine, then she turned the tables. Watch what happens next." I avoided even opening this article several times out of distaste for the headline. It should be something like "Google leaves your Gemini data vulnerable to non-secret API key exploit."
> Leaked key blocking. They are defaulting to blocking API keys that are discovered as leaked and used with the Gemini API.
There are no "leaked" keys if google hasn't been calling them a secret.
They should ideally prevent all keys created before Gemini from accessing Gemini. It would be funny(though not surprising) if their leaked key "discovery" has false positives and starts blocking keys from Gemini.
Ohh so that's how that happened. I had noticed (purely for research purposes of course) that some of Google's own keys hardcoded into older Android images were useable for Gemini (some instantly ratelimited so presumably used by many other people already but some still usable) until they all got disabled as leaked like two months ago. They also had over time disabled Gemini API access on some of them over them beforehand.
What's frustrating is that a lot of these keys were generated a long time ago with a small amount of GCP services that they could connect to. (Ex. Firebase remote config, firestore, etc.)
When Gemini came around, rather than that service being disabled by default for those keys, Gemini was enabled, allowing exploiters to easily utilize these keys (Ex. a "public" key stored in an APK file)
This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?
this is what happens when a "public" key type quietly turns into a privileged key type without forcing people to re-scope it, not really a dev mistake IMO, it's a platform design bug and google needs hard separation between publishable and secret keys or this repeats every time they ship a new API. pretty disappointed in google tbh, looked up to them for security for the longest time
Someone on the Google subreddit did report getting a 80k bill yesterday from a Gemini key.
I’m very careful with Google and co since they’re so intent on infinite scaling access to your wallet
This is mind-blowing, and it defies all security common sense. Changing global API keys permissions? Come on! We’re accustomed to seeing issues like this from Redmond but didn’t expect it from Google.
Is the implication at the end that Google has not actually fixed this issue yet? This is really bad; a massive oversight, very clearly caused by a rush to get Gemini in customers' hands, and the remediation is in all likelihood going to nuke customer workflows by forcing them to disable keys. Extremely bad look for Google.
I think this is making at least some waves in google. I literally just got an email from them with the subject "[Action Advised] Review Google Cloud credential security best practices"
A slew of recommendations, one of them being:
Disable Dormant Keys: Audit your active keys and decommission any that show no activity over the last 30 days.
(Although I don't think this even addresses the underlying issue)
This totally reminds me of SSN use, when initially they were just a number (not secret) to identify a person, and then suddenly people started to use them as a key for authorisation, because someone had a bright idea how to implement things fast/simple/cheap (cheap part comes at expense of others)
Many people wanted to be able to set a spending limit on google cloud account for many years but they were unable to implement anything, always suggesting a workaround by hosting a Cloud Run function which would remove billing from a project via API https://docs.cloud.google.com/billing/docs/how-to/disable-bi...
Unrestricted API keys were always secrets. They are created on a page called "Keys & Credentials". The fact that Google even allows unrestricted keys to be created has been a long standing security problem. The fact their docs encouraged it remains unforgivable.
> Retroactive Privilege Expansion. 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.
Malpractice/I can't believe they're just rolling forward
This is just embarrassing. It doesn’t even really qualify as a security vulnerability, more like a fatal flaw in the system’s design. I can see why the team pushed back on fixing it, seems like a massive pain.
It feels like something that would happen if you outsourced planning to an LLM.
> This makes sense. These keys were designed as project identifiers for billing, and can be further restricted with (bypassable) controls like HTTP referer allow-listing. They were not designed as authentication credentials.
Can't you just run up a huge bill for a developer by spamming requests with their key? I don't see how this wasn't always an issue?
Am i reading this right - it was like impossible to get an api key for gemini but actually i could have just grabbed an API key from someone's google maps site and gotten started right away?
Woof. Impedance mismatch outcome from moving fast - the GCP auth model was never designed to work like oAI's API key model; this isn't the only pain point this year, but it's a nasty one. I'm sympathetic, except that dealing with GCP has always been a huge pain in the ass. So I'm a little less sympathetic.
Can’t wait til someone makes a Gemini prompt to find these public keys and launch a copy of itself using them.
API keys were always secrets. They control billing for heaven's sake. If you had any per-call billed APIs (like some of the voice processing APIs) enabled on the project then they're effectively keys to your pocket book. Otherwise they're a key tool to manage denial-of-service attacks.
So even if they fix the issue, it sounds as though you can still shoot itself in the foot by essentially being at to arbitrarily change an existing key from “not a secret” to “is a secret”?
Even if you have a key that you use for maps (not secret) someone could add the generative AI scope to it and make it now necessarily secret (even though it’s probably already publicly available)?
Arguably, calling it a key while insisting it's a non-sensitive ID was a mistake to start with
Changing the semantics of existing non-key keys, making them actually keys is horrendous
I reported few instances last year, some companies fixed it, some other didn't even understand the problem (or ghosted me).
Who knew there were downsides to forcefeeding your product to an unwilling audience?
This whole Gemini roll-out has me reminded of the Google '+' days when they thought they were going to die if they didn't do social.
the credential didn't change. the permissions changed underneath it. that's the worst kind of privilege escalation because nobody has a reason to go back and audit something they were told was safe a decade ago.
What are the chances this isn't intentional to some extent? This wouldn't be the first time we've traded downstream legal trouble for short term gains.
Making AI utilization appear to go up is the only thing that matters right now if you're in the boardroom at one of these companies. Whether or not that utilization was actually intended by the customer is entirely irrelevant. From here, the only remaining concern is mitigating legal issues which google seems to be immune to.
They said they were going to disable it for leaked keys isn't better to just disable it for leaked keys. Isn't better to make the default behavior from now on to not have access to Gemini or I misunderstood?
I’ve been exploring this exact problem space from the angle of extreme constraints (single-digit MB memory, no cloud assumptions). I documented what broke first and why here, in case it’s useful: https://github.com/nullclaw/nullclaw
> 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.
This destroys Google's right to pursue an unpaid "AI" bill as a debt.
This firm is doing great work, I still refer to this post ("Anyone can Access Deleted and Private Repository Data on GitHub"): https://trufflesecurity.com/blog/anyone-can-access-deleted-a...
Happened to me recently, I got a warning in Gemini Studio that a key leaked. I was perplexed initially and then realized what had happened. The proper fix is to limit the key to just Maps APIs. Of course even this is not so easy, as there's a long list of APIs with complicated names. It was at least limited to my domain.
This is true but also not as new as the author claims. There have been various ways to abuse Google API keys in the past (at least to abuse them financially) and it’s always been very confusing for developers.
Seems like the kind of bug caused by using Gemini to vibe code the GCP.
> 2,863 Live Keys on the Public Internet
It will be more interesting if they scan GitHub code instead. The number terrified me. Though I am not sure how many of that are live.
Uh what? Google maps API keys have always been separate and they have always adviced to lock it down to your domain such that others can abuse it.
Thousands of engineers. Culture rot.
Since I've never used them, how could API keys for Firebase or Maps be safe for embedding in client side code?
I mean, I get that authentication to the service is performed via other means, but what's the use of the key then?
I'm guessing it's just a matter of binding service invocations to the GCP Project to be billed, by first making sure that the authenticated principal has rights on that project, in order to protect from exfiltration. That would still be a strange use case for what gets called an "API key".
This is so weird, this feels like an incredibly stupid bug that any average developer would've noticed, but Google is so incredibly selective with their tech screen. What exactly is the point of those if they're going to fuck up in obvious ways?
it's just firebase part 2
Wait, I can get such a key and perform gemini API requests with curl? (probably limited in some ways)
I'm a bit surprised by the timeline which seems to say that:
- 6 weeks ago Google said they would fix it
- 3 weeks ago Google said they were working on it
...but we're publishing the info anyway, so everyone can go nuts with it.
Great write-up. Hilarious situation where no one (except unwieldiness) is the villain.
Dang, another obvious reason (among many others) you shouldn't be uploading documents to any LLM client (or use them on anything important).
ChatGPT writing a blog post attacking Gemini security flaws. It's their world now, we're just watching how it plays out.
Private data should not be allowed to be accessed using public keys. That is the core problem. It is not about Google API keys are secret or not.
Explain It Like I'm Five.
From TFA:
> Last month, a developer on your team enabled the Gemini API for an internal prototype. > The result: thousands of API keys that were deployed as benign billing tokens are now live Gemini credentials sitting on the public internet.
Benign, deployed openly without any access restrictions whatsoever, billing tokens can be used to bill for a service under the account it is enabled for. That's the intended behavior, literally. Maps API keys are used to give your users access to Google Maps on your credit card.
What's the problem here? Yes, the defaults could have been stricter, but it's not like it costs anything to create a bunch of internal projects that do not have good-for-billing access keys floating around open internet. People moved fast, deployed LLM generated code, broke things and then blame everyone else but themselves?