“我现在处于震惊和恐慌之中。”
这是帖子的开头。没有铺垫，没有背景说明，只有一句情绪几乎溢出屏幕的自白。
开发者 Gemini 账户被盗，48 小时损失 57 万
在 Reddit 发帖的人，是一家位于墨西哥的初创公司联合创始人，公司只有三名开发者，规模很小，每月在谷歌云服务上的正常支出大约 180 美元。对他们来说，云账单是一项可控成本，是创业早期可以精确计算的变量。
但 2 月 11 日至 12 日这 48 小时，一切都失控了。
在这两天里，他们的 Google Cloud API 密钥被盗用。具体怎么发生的，他们至今不清楚。“我们不知道是怎么回事，也没有发现明显的错误。”他说。
但账单记录非常清晰：总额 82,314.44 美元（约合人民币 57 万）。几乎全部来自两项服务——Gemini 3 Pro 图像与 Gemini 3 Pro 文本。
180 美元与 82,314 美元之间，是 457 倍的差距。
那一刻，这不再是技术问题，而是生存问题。
他们第一时间采取了所有能想到的补救措施：删除泄露的密钥，禁用 Gemini API，轮换全部凭证，在所有账号上启用双因素认证，收紧身份与访问管理（IAM）权限，并向谷歌提交了支持请求。从操作流程上看，这是一次标准、迅速且完整的安全响应。
但真正让他感到恐慌的，是随后与平台沟通的结果。
根据他的说法，谷歌方面提到了 Google Cloud 的“共享责任模式”——平台负责基础设施安全，用户负责凭证管理。因此，这笔未经授权产生的 API 费用，仍然需要由客户承担。
“这真的让我非常担心。”他写道，“如果谷歌试图强制收取哪怕三分之一的费用，我们公司就会破产。”这不是夸张的修辞。对一家现金流本就紧张、寄希望于产品爆发的三人团队而言，哪怕 2 万多美元的账单，都足以击穿银行账户余额。
他反复强调，他们是一家小公司。这笔账单远远超出了公司的承受能力。
但让他难以理解的，不只是费用归属问题，而是整个系统的风控逻辑。
在他看来，这 82,000 多美元并不是“正常波动”，而是明显的异常滥用行为。48 小时内，从月均 180 美元的基线，暴涨到 8.2 万美元，系统却没有触发任何强制停止机制。
“为什么没有针对灾难性使用异常情况的基本防护措施？”他提出一连串问题——
为什么当使用量达到历史水平的 5 倍或 10 倍时，没有自动硬性停止？
为什么在极端峰值下，不需要强制确认？
为什么在审查期间，没有临时冻结？
为什么没有默认的单 API 消费上限？
这些问题并不带有攻击性，更像是一个技术人员在复盘事故时的困惑。对他来说，API 密钥被盗已经是既成事实，但计费系统为什么允许异常规模在 48 小时内持续放大，是另一层无法理解的风险。
帖子的最后，他向社区求助：有没有人成功申诉过类似情况？有没有减免费用的经验？他甚至向 FBI 提交了网络犯罪报告，希望通过正式渠道记录这次攻击。
截至发帖时，谷歌方面的态度仍然是：除了付款，没有别的选择。
这篇帖子之所以引发大量关注，并不是因为 8 万美元这个数字本身，而是它折射出的结构性焦虑。生成式 AI API 的调用成本远高于传统 Web 服务接口，一旦凭证泄露，高并发调用可以在极短时间内累计巨额费用。对于大企业而言，这或许只是一次可谈判的异常账单；对于小团队而言，却可能是一次致命打击。
“简而言之，”他在帖子中总结，“Gemini API 密钥被盗，48 小时内产生 82,314 美元费用。我们正常月费 180 美元，飙升 457 倍。我们已经采取安全措施，但谷歌以‘共同责任’为由拒绝赔偿。如果坚持收取费用，我们将破产。”
目前尚不清楚这家墨西哥公司的最终结局。是否减免费用、是否达成和解、是否能继续运营，都还是未知数。但可以确定的是，这 48 小时，已经成为他们创业过程中最沉重的一课。
研究员揭露谷歌 API 密钥核心问题
《The Register》援引安全公司 Truffle Security 安全研究员 Joe Leon 的博客内容，进一步揭示了问题的结构性根源。Leon 在 2 月 25 日的文章中写道：“有了有效的密钥，攻击者就可以访问上传的文件、缓存的数据，并将 LLM 使用量计入您的帐户。”
它意味着风险并不局限于“刷调用次数”导致账单飙升，还可能涉及数据访问与缓存内容读取。API Key 不再只是计费通道，而可能成为访问路径。
Joe Leon 在博客中详细解释了为什么谷歌 API 密钥（例如用于地图、Firebase 等服务的密钥）并非秘密这件事在以前没什么问题，但 Gemini 出来后，情况就变了，核心问题到底是什么。
Joe Leon 在博客中提到，Google Cloud 使用单一 API 密钥格式 ( AIza...) 用于两个根本不同的目的：公开身份识别和敏感身份验证。
多年来，谷歌一直明确告知开发者，API 密钥可以安全地嵌入客户端代码中。Firebase 自身的安全检查清单也指出，API 密钥并非秘密信息。
注意：这些与用于支持 GCP 的服务帐户 JSON 密钥截然不同。
Google Maps JavaScript 文档还直接指示开发者将密钥直接粘贴到 HTML 中。
这合情合理。这些密钥被设计为用于计费的项目标识符，并且可以通过诸如 HTTP Referer 允许列表之类的（可绕过的）控制措施进一步限制。它们并非设计为身份验证凭据。
但 Gemini 出现后情况变了。
在 Google Cloud 项目中启用 Gemini API（生成式语言 API）时，该项目中现有的 API 密钥（包括网站公共 JavaScript 代码中的密钥）可能会在后台静默访问敏感的 Gemini 端点。
没有任何警告、确认对话框或电子邮件通知。
这就产生了两个截然不同的问题：
追溯性权限扩展。比如三年前，您创建了一个 Maps 密钥，并按照 Google 的指示将其嵌入到您网站的源代码中。上个月，您团队的一位开发人员为内部原型启用了 Gemini API。现在，您的公钥已变成 Gemini 凭证。任何抓取该凭证的人都可以访问您上传的文件、缓存的内容，并导致您的 AI 费用飙升。没有人告诉过您这一点。
不安全的默认设置。在 Google Cloud 中创建新的 API 密钥时，默认设置为“不受限制”，这意味着它立即对项目中所有已启用的 API（包括 Gemini）都有效。用户界面会显示“未经授权使用”的警告，但这种默认架构完全开放。
结果是：数千个原本作为良性计费 token 部署的 API 密钥现在变成了存在于公共互联网上的 Gemini 实时凭证。
之所以说这是权限提升而不是配置错误，是因为事件发生的顺序。
开发者创建了一个 API 密钥并将其嵌入到地图网站中。（此时，该密钥是无害的。）
Gemini API 已在同一项目中启用。（现在，同一个密钥可以访问 Gemini 的敏感端点。）
开发人员从未被告知密钥的权限在其底层发生了变化。（密钥从公共标识符变为秘密凭证
虽然用户可以限制 Google API 密钥（按 API 服务和应用程序），但漏洞在于不安全的默认设置 (CWE-1188) 和不正确的权限分配 (CWE-269)：
隐式信任升级：Google 将敏感权限追溯性地应用于已在公共环境中合法部署的现有密钥（例如，JavaScript 包）。
密钥分离不足：安全的 API 设计需要针对不同的环境（公开密钥与私钥）使用不同的密钥。如果对两者都使用同一种密钥格式，系统就容易出现安全漏洞和混乱。
安全默认值失效：通过 GCP API 面板生成的密钥的默认状态允许访问敏感的 Gemini API（假设已启用）。用户在为地图组件创建密钥时，会在不知情的情况下生成具有管理权限的凭据。
那攻击者能做什么？
攻击者访问您的网站，查看页面源代码，并 AIza...从地图嵌入中复制您的密钥。然后他们运行：
curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"
403 Forbidden 他们得到的不是 a，而是 200 OK。攻击者由此可以：
访问私有数据。`and`/files/端点可以/cachedContents/包含上传的数据集、文档和缓存的上下文。项目所有者通过 Gemini API 存储的任何内容均可访问。
账单飙升。Gemini API 的使用并非免费。根据具体模型和上下文窗口，攻击者如果滥用 API 调用，可能每天仅一个受害者账户就会产生数千美元的费用。
用完您的配额。这可能会导致您的 Gemini 合法服务完全停止。攻击者根本不会触碰你的基础设施。他们只是从公共网页上窃取密钥。
为了解问题的严重程度， Truffle Security 扫描了 2025 年 11 月的 Common Crawl 数据集，这是一个庞大的（约 700 TiB）网页存档，其中包含从互联网上公开抓取的 HTML、JavaScript 和 CSS 网页。 Truffle Security 团队发现了 2,863 个存在权限提升漏洞的 Google API 密钥。
前端源代码中用于 Google Maps 的示例 Google API 密钥，但也可以访问 Gemini。
Truffle Security 团队指出，这些并非业余爱好者的副业项目。受害者包括大型金融机构、安全公司、全球招聘公司，以及谷歌自身。如果供应商自己的工程团队都无法避免这个陷阱，指望每个开发者都能正确应对是不现实的。
在 Truffle Security 团队提出一系列漏洞及其相关证据后，GCP VDP 团队开始认真对待这个问题。
他们扩展了泄露凭证检测流程，将 Truffle Security 团队报告的密钥纳入其中，从而主动保护真正的谷歌客户免受利用其 Gemini API 密钥的威胁行为者的侵害。他们还承诺修复根本原因，但 Joe Leon 表示他们尚未看到具体成果。
Joe Leon 写道：“构建像谷歌这样规模的软件极其困难，而 Gemini API 沿用了为不同时代设计的密钥管理架构。谷歌已经意识到我们报告的问题，并采取了切实有效的措施。目前尚待解答的问题是：谷歌是否会告知客户其现有密钥存在的安全风险，以及 Gemini 最终是否会采用不同的身份验证架构。”
网友：我可能会跪求谷歌退款！
这位墨西哥开发者的经历，很快在技术社区引发了广泛讨论。围绕责任归属、平台机制以及开发者自身配置问题，观点分化明显。
不少 Reddit 用户对他的处境表示强烈同情。一位网友直言，如果自己遇到这种情况，“恨不得飞到谷歌总部，跪在地上求他们退款。”在这些人看来，对于一家仅有三名成员的小公司而言，8 万多美元的账单几乎等同于“致命打击”。即便技术上存在疏漏，平台也应在极端异常场景下提供更多缓冲或协商空间。
但也有用户将讨论焦点转向机制设计本身。他们指出，Google Cloud 的 API Key 体系确实应该提供更明确、可配置的“硬性消费上限”。一旦触及某个阈值，系统应自动中断服务，而不是仅发送提醒。与此同时，也有人提到技术实现层面的复杂性——云费用往往并非实时结算，而是在产生后 24 小时甚至 36 小时内逐步计入账单。如果计费数据本身存在延迟，那么要做到真正意义上的“即时硬性封顶”，在系统架构上可能并不简单。
还有网友认为谷歌方面没什么错，而是他们自己忽略硬性设置造成的错误。他表示：
“但现在已经有了这些硬性限制设置，我完全不明白楼主为什么还要因为他们糟糕的配置错误而责怪谷歌……至少要承认，没有设定硬性限制是一个巨大的错误。”
在这起 API 账单风波引发广泛讨论后，一位有多年云服务经验的网友给出了相对冷静的分析。
他首先提出一个关键问题：“所谓‘被盗’，究竟是什么意思？”在他看来，这个定义本身至关重要。
“是有人真正入侵了系统、突破防线窃取数据？还是开发者在配置或代码管理过程中无意间泄露了凭证？这两种情况在责任划分与后续处理上完全不同。如果是系统层面的安全入侵，性质更严重；如果是凭证暴露，则更可能被视为配置风险。厘清这一点，是与平台沟通的第一步。”
这位网友还提醒，当事人应检查是否拥有网络安全或技术责任相关的保险。有些公司会为云服务异常账单或安全事件投保，在特定条件下可以申请理赔。虽然这并不能解决根本问题，但在现金流紧张时，可能成为缓冲手段。
还有网友表示，通过权限访问比通过密钥访问要靠谱得多。
“这就是为什么应该通过权限而不是密钥来授予访问权限，以及为什么工作负载身份如此重要的原因。”
参考链接：
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules
