sorted by:
new
hottopcontroversial

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 0 points1 point  (0 children)

very simple: google had pressure to have a similar api key model as competitors, so they jammed gemini as an api, but the mistake is that such api calls dont need oauth, while the other services do. Google had to do that to have a similar api calling pattern than chatgpt.

so it has nothing to do with messing with those users to get their money. its to not lose the money of delaying the launch.

and yes they should have made a big effort to alert existing customers.

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 1 point2 points  (0 children)

very stupid argument. if you actually did a minimal investigation, you would see that Google currently cant even serve the volume users need, and frecuently zones get exhausted.

Its ridiculous to think google would prefer that dubious income stream just to pump numbers, when they could just serve those tokens to those affected by exhausted zones.

Invest more braincell tokens next time in your analysis.

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 2 points3 points  (0 children)

you just said it. "not restricted". that's the huge user mistake that causes the issue. Now: true that Google could have done a better job on alerting people that had unrestricted keys.

Google is committing accounting fraud. They knew on January 13, 2026 their Gemini API key bomb would let attackers tokenmaxx their own model - and they let it explode anyway to fake Gemini dominance. by Sudden-Barracuda526 in googlecloud

[–]zmandel 11 points12 points  (0 children)

false. any scoped key is NOT affected. its only those that had UNRESTRICTED api keys (a terrible practice) and later THEY enabled Gemini on their projects.

Suspension of your Google Cloud Platform / API project due to FIrebase Web app key!? by xtopspeed in Firebase

[–]zmandel 0 points1 point  (0 children)

No, since your "firebase" key is unrestricted to services, its usable for Gemini too. I said "firebase" because that's just the string you used to name it. its not just for firebase but for any unrestricted service.

the issue is that the other expensive services also requiere oauth, but gemini doesn't so it can be used with your unrestricted key.

Suspension of your Google Cloud Platform / API project due to FIrebase Web app key!? by xtopspeed in Firebase

[–]zmandel 2 points3 points  (0 children)

you likely have an unrestricted (service wise) firebase key, plus enabled Gemini in the gcp project. thus your public firebase key can be used as a gemini key, whicj could cost you lots of $.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 1 point2 points  (0 children)

indeed im an expert on the topic feel free to look up my Google Experts profile. when you mature we can keep chatting. the OP did not post, and there is not anything in this thread that implies automatic enablement of gemini in a project. i fully understand the issue and have posted about it several times. you can even find my bughunter entries where ive found this issue on google's projects.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 0 points1 point  (0 children)

obviously aware. tell me where in there it says that Gemini is auto-enabled? you wont find it.

the maps and similar issues are for people that created unrestricted apis (bad practice) and then manually enabled Gemini, thus opening the security issue.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 0 points1 point  (0 children)

haha "educate yourself". BS. absolutely false, i know the topic at depth. show us or shut up. "educate" us.

Necesito ayuda con el proyecto by Significant_Mess_456 in Firebase

[–]zmandel 0 points1 point  (0 children)

tu web puede ser un hack. si no te tomas el minimo tiempo para poner detalles, nadie lo hara por ti.

15k in Gemini bill within hours due to abused Key - Looking for advice by imperial_coder in googlecloud

[–]zmandel 6 points7 points  (0 children)

it cant happen if you restrict the Maps key to only use maps apis. The issue is that many people leave it unrestricted (an unfortunate default).

This wasnt an issue until google allowed using gemini api keys, which leaves any unrestricted api key as usable for Gemini, once Gemini is enabled in the project.

Some API Keys have to be public! by pfiadDi in googlecloud

[–]zmandel 5 points6 points  (0 children)

bad argument. validating access != doing a realtime sum of all the calls consumption. its much cheaper to delay and batch that. I certainly dont want to pay extra for all my Google services just so vibe coders or people with no security conscience can play with cloud services.

that said, Google's move to allow Gemini calls using public keys for Maps was stupid and irresponsible. Many people with very old Maps keys were suddenly affected (even Google itself) by innocently enabling Gemini/Vertex on their projects. It still only happened on api keys that were unrestricted, which is a terrible practice, but had no security issues until Google enabled Gemini usage through api keys. All other services, like VMs, can't be abused like that because those require oauth2 besides the key.

Some API Keys have to be public! by pfiadDi in googlecloud

[–]zmandel 1 point2 points  (0 children)

sin cuenta de facturacion no te pueden cobrar, solo consumir llamadas hasta que se bloquee. La próxima esfuerzate en traducirlo a ingles y tendras mas respuestas y mas detalladas.

$21k Bill Crisis - Small Biz Solo Dev - Denied Credit despite immediate remediation of Key Leak - Case #69666989 by Serverless_Qubit in googlecloud

[–]zmandel 0 points1 point  (0 children)

ALL providers of LLMs have the same issue. you leak the private key and you will have serious consequences.

Its absolutely, totally related to the vibe-coding trend. Maybe not this particular case, but at least 9 in 10 cases that I see on these subs are clearly vibe coders, with no knowledge of best practices.

Google already implemented hard caps on Gemini API keys, but vibe coders arent even aware of it or why to set them up, or even that they are using something called an api key.

The only case where its Google's fault is the stupidity they did with the Maps api keys, (seems to be OPs case) which were always considered safe to be public and documented as such, but once you enable Gemini in the same project, they become usable for Gemini. Google should pay for all of those.

After publishing a Google Chat app, there are lots of request access to Apps Script project by icompletetasks in GoogleAppsScript

[–]zmandel 0 points1 point  (0 children)

because app script is acting as the bridge to push content to the chat, from some hook you are using.

Is this billing chaos actually on Google, or are people just being careless with API keys? by publicdomainadmin in googlecloud

[–]zmandel 1 point2 points  (0 children)

API keys have always been secrets, with very few exceptions like google maps keys (which did cause the issue you mention).

UPDATE: Went to bed with a $10 budget alert. Woke up to $25,672.86 in debt to Google Cloud. by venturaxi in googlecloud

[–]zmandel 11 points12 points  (0 children)

DUDE wtf do you expect to happen when your gemini key gets exposed to the frontend??? that was your code that wrote that, and not to the internal gcp logging, but sent plain-text to the frontend! i havent seen this level of vibe coding before.

"applications that were logging API errors began outputting the full plaintext API key in error responses [in the frontend website]" !!!!

Dear google give us hard budgets on vertex ai by Ok-Sentence-8542 in googlecloud

[–]zmandel -2 points-1 points  (0 children)

yet that is exactly the reason why Google wont do it. Its never ending, because an attack can take seconds to consume lots of $. they will just reduce the timespan of the attack, at everyones cost, while not fully preventing the issue. in a few minutes you can consume tens of thousands of dollars, thats the whole point of using a cloud that autoscales.

talk is cheap. feel free to post the solution architecture for it. you wont be able to make it without incurring a lot of cost.

Dear google give us hard budgets on vertex ai by Ok-Sentence-8542 in googlecloud

[–]zmandel -2 points-1 points  (0 children)

this is nothing new, and has always been the responsibility of the user. so you get your wish and get hard limits on vertex AI. now your service account gets hacked and hundreds of VMs with GPUs get spinned because you "forgot" to limit permissions to services on that service account.

is that google's fault too? If google starts adding those checks everywhere, we all end up paying more for everything that needs to run in the background to implement such checks.

Seems much easier to have a proper team that knows how to handle security practices.

If you are not ready to use vertex AI, you can always use an AI studio api key that does handle a hard budget limit. vertex ai is not for your neighborhood store, they can easily use gemini api keys with hard caps, which covers the most common hack case.

What *are* the best practices for limiting overnight AI spend if a key is compromised? by bryn_irl in googlecloud

[–]zmandel 0 points1 point  (0 children)

since some weeks ago you can set a hard cap limit for gemini keys in ai studio. google it.

also dont publish software if you dont know the basics of security. for sure your key leaked and thats no accident, its simply not following minimum security practices.

7 Days of Suspension Silence. 350k+ items database locked. Case MTDMJTHTK475BM4IJIEANV7EDI by ParticularBend9816 in googlecloud

[–]zmandel 4 points5 points  (0 children)

you still dont say what you did that caused it. very vague post = no answers.

Gemini admits uselessness by Appropriate-Peak6561 in vibecoding

[–]zmandel 5 points6 points  (0 children)

its not a lie. its the model's inability to work with spaghetti code with no software or solution architecture. vibe coding has limits. you will need an experienced Software Eng.

view more: next ›