一次点击背后的8.7万欧元账单：Gemini云计费漏洞警示

一封天价账单引发的信任危机

一位名叫 Ioannis Tsiokos 的普通用户在 Reddit 上讲述了自己遭遇的一场噩梦：因为点击了一条 Google 广告，两周后他的 Google Cloud 账户被扣除高达 8.7 万欧元（约 10 万美元）的 Gemini 图像生成费用。

对于一个月常规账单仅约 150 欧元的用户来说，这个数字近乎荒诞。而更令人不安的是，这一切并非源于他主动泄露 API 密钥，而是一连串安全环节失守后的连锁后果。

攻击链条：从一条广告到账户被劫持

根据当事人的描述，整个事件的起点是一条看似正常的 Google 广告。他点击广告想要安装 Claude Code，页面跳转到了 Anthropic 的合法域名，界面也很熟悉，于是他下载了对应的二进制文件。

安装过程中他察觉到"有些不对劲"，随即用 Bitdefender 做了全盘扫描，但没有发现任何异常。事后他才意识到，那个所谓的 Anthropic 链接其实是一个"共享构件（shared artifact）"——一个被恶意利用的分发入口。

他梳理出的攻击路径大致是这样的：

• Google Ads 投放了一条指向携带病毒链接的广告；
• 他的付费 Gmail 账户被入侵；
• 由于账户关联，其 Google Cloud（GCS）账户随之被攻破；
• 攻击者利用被劫持的账户，绕过免费/低配额度限制，通过创建多个项目大量调用 Gemini 生成 AI 图像，最终堆积出天价费用。

值得关注的技术细节是：即便账户处于 Tier 1（免费）或 Tier 2 的低配额状态，攻击者依然可以通过"批量创建多个项目"的方式突破单项目的用量上限，从而在短时间内产生巨额消费。

这类通过搜索广告分发恶意软件的手法在安全领域被称为"恶意广告（Malvertising）"，近年来针对开发者工具的攻击尤为猖獗。攻击者通常竞价购买与热门开发工具高度相关的关键词广告位，将用户引导至视觉上几乎与官方网站完全一致的仿冒页面，或利用 GitHub、CDN 等合法平台的"共享构件"托管经过篡改的安装包。由于广告本身指向的可能是合法域名下的某个路径，传统安全扫描工具难以通过 URL 特征识别威胁。此次事件中提到的"shared artifact"机制，是指攻击者将恶意载荷托管在某个可公开访问的合法存储节点（如 Google Drive 分享链接、GitHub Release 或 Artifact Registry），从而规避针对钓鱼域名的过滤。这也解释了为何 Bitdefender 全盘扫描未能立即发现异常——威胁可能以延迟执行或驻留方式潜伏，或者核心恶意行为发生在凭证窃取阶段而非本地文件层面。

责任的灰色地带：谁该为此买单

事件中最刺痛用户的，是责任归属的模糊与不对等。当事人在帖子中做了一连串追问，直指几个关键环节都指向同一家公司：

• Google Ads 收了钱投放了含病毒的链接，但按照服务条款，平台对广告链接携带病毒"不承担责任"；
• Gmail 和 Chrome 本身不提供安全保证；
• Google Cloud 不提供让用户设置"绝对消费上限"的功能。

换句话说，从广告投放、邮箱账户到云平台，每一环都出自同一生态，但每一环又都通过条款免除了自身责任，最终账单却完整地落到了用户头上。

Google Cloud 方面表示会作为"一种善意（courtesy）"减免 6.5 万欧元，留下约 2.2 万欧元的债务由其公司承担。当事人对此并不领情，他明确表示不会支付一分钱，并强调这不是自己疏忽泄露密钥，而是系统遭到刑事级别的入侵，希腊警方已经介入调查——但这并不能消除账面上的债务。几天前，他还收到了债务即将转入催收的警告。

云计费机制的结构性隐患

抛开个案的情绪，这起事件暴露出云服务计费模式中的一个长期痛点：用量型计费缺乏硬性支出上限。

大多数云平台采用后付费模式，用户按实际消耗量结算。这种模式对企业弹性扩容很友好，但对普通用户和小型开发者却是一颗定时炸弹——一旦账户被盗用或代码出现失控循环，费用可以在极短时间内失控增长，而用户往往在账单出现时才后知后觉。

当事人反复强调的一句话很有代表性："如果这能发生在我身上，就能发生在任何一条小鱼身上。"他并非重度云用户，只是创建了一个 Gemini 账户，却因此背上了远超日常消费数百倍的债务。

这里的核心矛盾在于：平台提供了预算告警（alert），却没有提供自动硬性熔断（hard cap）。告警只是通知，不会自动停止服务；而当攻击发生在深夜或用户离线时，等看到通知，损失早已铸成。

主流云平台在支出控制设计上存在显著差异。AWS 和 Azure 同样主要依赖预算告警而非硬性熔断，但 Azure 的订阅层级可以设置支出限制（Spending Limit），超额后会暂停服务而非继续计费。Google Cloud 的预算功能仅支持告警通知，不能自动停止 API 调用；开发者可以通过配额（Quota）管理来限制特定 API 的每日或每分钟请求数，但这需要用户主动在控制台逐项配置，且攻击者若能创建新项目，则新项目会继承默认配额上限而非继承父账户的剩余配额。这正是本案中攻击者通过"批量创建项目"放大消费的关键漏洞：每个新项目均获得独立的免费额度与默认配额，相当于在同一账单账户下无限复制消费能力。对于个人开发者，一个实用的防御措施是在 IAM 层面限制账户创建新项目的权限，并为服务账号（Service Account）设置最小权限原则。

给普通用户的现实启示

无论最终责任如何认定，这起事件对每一位使用云 AI 服务的用户都有直接的警示意义：

• 警惕搜索广告下载：即便跳转到看似合法的官方域名，也要通过官方渠道核实下载入口，广告位早已成为分发恶意软件的高发区；
• 强化账户安全：为 Google 账户开启强多因素认证（MFA），并定期检查授权的第三方应用与关联项目；
• 主动配置预算控制：在云平台上设置预算告警，尽可能利用可用的配额限制，对不常用的服务保持关闭状态；
• 定期审查项目列表：攻击者绕过配额的手法之一是创建多个新项目，定期清点账户下的项目能帮助尽早发现异常。

这起纠纷的最终走向尚不明朗，当事人表示会"把这件事进行到底"。但无论结果如何，它已经把一个尖锐的问题摆到了台面上：当安全防线全部由同一家生态提供，而责任却被条款层层剥离时，普通用户究竟还剩下多少保护？

提示：本文基于单一 Reddit 用户的自述整理，相关细节尚未获得官方独立核实，请读者理性看待并以官方信息为准。