The €87,000 Bill Behind a Single Click: A Warning About Gemini Cloud Billing Vulnerabilities

A Sky-High Invoice That Shattered Trust

A user named Ioannis Tsiokos took to Reddit to share a nightmare experience: after clicking a Google ad, he found his Google Cloud account charged €87,000 (roughly $100,000 USD) in Gemini image generation fees — all within two weeks.

For someone whose regular monthly bill runs around €150, that figure is almost surreal. What makes it even more disturbing is that it didn't happen because he carelessly leaked an API key. It was the cascading result of multiple security failures, one after another.

The Attack Chain: From an Ad to a Hijacked Account

According to the victim, the whole ordeal started with what appeared to be a normal Google ad. He clicked it intending to install Claude Code, was redirected to what looked like Anthropic's legitimate domain, and — recognizing the familiar interface — downloaded the corresponding binary.

During installation, he sensed "something was off" and ran a full system scan with Bitdefender, which came back clean. Only later did he realize the so-called Anthropic link was actually a "shared artifact" — a distribution vector that had been maliciously exploited.

Here's the attack chain as he reconstructed it:

• A Google Ads campaign served an ad pointing to a malware-laced link;
• His paid Gmail account was compromised;
• Because the accounts were linked, his Google Cloud (GCS) account was breached as well;
• The attackers used the hijacked account to bypass free/low-tier quota limits by creating multiple projects, then made massive calls to Gemini for AI image generation — racking up enormous charges in a short time.

A key technical detail worth highlighting: even when an account is on Tier 1 (free) or Tier 2 with low quotas, attackers can still circumvent per-project usage limits by bulk-creating multiple projects, generating massive charges within a short window.

This technique of distributing malware through search ads is known in security circles as malvertising, and attacks targeting developer tools have surged in recent years. Attackers typically bid on keywords closely associated with popular dev tools, routing users to spoofed pages that are visually near-identical to official sites — or they abuse legitimate platforms like GitHub or CDNs to host tampered installation packages as "shared artifacts." Since the ad itself may point to a path on a legitimate domain, traditional security scanners struggle to detect the threat based on URL patterns alone. The "shared artifact" mechanism mentioned here refers to attackers hosting malicious payloads on publicly accessible, legitimate storage nodes — such as Google Drive shared links, GitHub Releases, or Artifact Registry — to evade phishing domain filters. This also explains why Bitdefender's full scan didn't flag anything immediately: the threat may have used delayed execution or persistence techniques, or the core malicious activity occurred at the credential-theft stage rather than at the local file level.

The Gray Zone of Responsibility: Who Pays?

What stung the victim most was the ambiguity — and asymmetry — around accountability. In his post, he ran through a series of pointed questions, each implicating the same company at every step:

• Google Ads took money to run an ad containing a malicious link, but per its terms of service, the platform bears "no responsibility" for malware in ad links;
• Gmail and Chrome offer no security guarantees;
• Google Cloud provides no feature allowing users to set a hard spending cap.

In other words, from the ad platform to the email account to the cloud platform, every layer belongs to the same ecosystem — yet each layer uses its terms to disclaim liability, and the full bill lands squarely on the user.

Google Cloud offered to waive €65,000 as a "courtesy," leaving roughly €22,000 for his company to absorb. The victim wasn't appeased. He stated he wouldn't pay a cent, emphasizing that this wasn't a case of negligently leaking credentials — his system was the victim of a criminal intrusion. Greek authorities have opened an investigation, but that doesn't make the debt disappear. Days before his post, he received a warning that the debt was about to be sent to collections.

A Structural Flaw in Cloud Billing

Setting aside the emotional weight of this individual case, the incident exposes a long-standing pain point in cloud service billing: usage-based pricing with no hard spending cap.

Most cloud platforms operate on a pay-as-you-go model, billing users for actual consumption. This is great for enterprise-scale flexibility, but for ordinary users and small developers, it's a ticking time bomb. If an account is hijacked or code enters a runaway loop, costs can spiral out of control in an extremely short time — and users typically don't find out until the bill arrives.

The victim's repeated refrain says it all: "If this can happen to me, it can happen to any small fish out there." He wasn't a heavy cloud user — he simply created a Gemini account — and ended up with a debt hundreds of times larger than his normal spending.

The core tension here: platforms offer budget alerts, but not automatic hard circuit breakers. An alert is just a notification — it doesn't stop the service. When an attack happens in the middle of the night or while the user is offline, by the time you see the notification, the damage is already done.

Major cloud platforms differ significantly in how they approach spending controls. AWS and Azure also rely primarily on budget alerts rather than hard caps, but Azure's subscription tier can be configured with a Spending Limit that suspends service once exceeded rather than continuing to charge. Google Cloud's budget tools only support alert notifications — they cannot automatically stop API calls. Developers can use Quota management to cap daily or per-minute requests for specific APIs, but this requires users to manually configure each quota in the console. Critically, if an attacker can create new projects, those new projects inherit the default quota limits rather than the parent account's remaining quota. This was the key vulnerability exploited in this case: each new project received its own independent free tier and default quota, effectively multiplying billing capacity infinitely within the same billing account. For individual developers, a practical defensive measure is to restrict the account's ability to create new projects at the IAM level and apply the principle of least privilege to service accounts.

Practical Takeaways for Everyday Users

Regardless of how responsibility is ultimately assigned, this incident carries direct lessons for anyone using cloud AI services:

• Be wary of downloading via search ads: Even if you're redirected to what appears to be a legitimate official domain, always verify the download source through official channels. Ad slots have become a hotbed for malware distribution;
• Harden your account security: Enable strong multi-factor authentication (MFA) on your Google account, and regularly audit authorized third-party apps and linked projects;
• Proactively configure budget controls: Set budget alerts on your cloud platform, make use of available quota limits, and keep services you rarely use turned off;
• Periodically review your project list: One method attackers use to bypass quotas is creating multiple new projects. Regularly auditing the projects under your account can help you spot anomalies early.

How this dispute ultimately resolves remains unclear — the victim says he'll "see this through to the end." But whatever the outcome, it has put a sharp question on the table: when every layer of security is provided by the same ecosystem, and liability is stripped away clause by clause, how much protection does an ordinary user actually have left?

Note: This article is based solely on a single Reddit user's account. The details described have not been independently verified by official sources. Readers are encouraged to exercise critical judgment and refer to official statements for authoritative information.