48小时“烧光”56万!三人创业团队濒临破产,仅因Gemini API密钥被盗:“AI账单远超我们的银行余额”

48小时“烧光”56万!三人创业团队濒临破产,仅因Gemini API密钥被盗:“AI账单远超我们的银行余额”

整理 | 苏宓

出品 | ZEEKLOG(ID:ZEEKLOGnews)

「仅过了 48 小时,一笔 8.2 万美元的天价费用凭空出现,较这家小型初创公司的正常月费暴涨近 46000%。」

这不是假设的虚幻故事,而是一家墨西哥初创公司正在经历的真实危机。

近日,一位名为 RatonVaquero 的开发者在 Reddit 发帖求助称,由于他的 Gemini API 密钥被盗用,原本每月仅约 180 美元(约 1242 元)的费用,在短短 48 小时内暴涨到 82,314.44 美元(约 56.8 万元)。对于这家只有三名开发者的小型创业团队来说,这笔突如其来的账单,几乎等同于灭顶之灾。

“我现在整个人都处在震惊和恐慌之中。”RatonVaquero 在帖子开头这样写道。

初创公司遭遇“天价账单”

根据 RatonVaquero 在 Reddit 上的描述,他的 Google Cloud API 密钥在 2 月 11 日至 12 日之间被泄露了,具体是怎么泄露的,他也不知道,也没有在软件中发现明显的错误。

随后,有未知攻击者利用该密钥疯狂调用 Gemini 3 Pro 的图像和文本接口,最终在短短两天内累计产生了 82,314.44 美元的费用。

对这家只有三个人的小公司来说,这个数字极其夸张——他们平时每月支出只有 180 美元。也就是说,这次异常调用带来的费用,直接飙升到了正常水平的约 455 倍。

发现异常后,团队立即展开紧急处理。他们删除了被盗的 API 密钥,禁用了 Gemini 相关接口,同时更换了所有访问凭证,全面启用双重验证,并收紧 IAM 权限配置。

与此同时,他们也向 Google Cloud 提交了支持工单,希望能获得官方协助。

但目前得到的回复并不乐观。

Google 方面在沟通中提到了“Shared Responsibility Model(共享责任模式)”。根据这一原则,云平台负责基础设施安全,而账户和密钥的管理则由用户自行负责。因此,即便是密钥被盗导致的调用费用,也可能需要用户承担。

“如果谷歌要求我们支付哪怕三分之一的费用,公司都会直接破产。”RatonVaquero 无奈地表示,“我们现在只是勉强维持运营,还寄希望于某个产品能够成功。我们只是墨西哥的三个开发者组成的小团队。”

截至目前,Google 尚未明确说明是否会强制要求该公司支付全部费用,也没有表态是否会承担部分损失。

开发者的疑问:“为什么没有基本的异常保护机制?”

这起事件也让 RatonVaquero 对 Google Cloud 的安全机制产生了疑问。

在他看来,从每月 180 美元到 48 小时 8.2 万美元的支出暴涨,显然不属于正常波动,而是非常明显的异常行为。

然而在使用过程中,Gemini 并没有触发任何自动保护机制,例如在使用量突然达到历史水平数倍时自动停止服务、在费用出现极端增长时要求额外确认,或在异常情况下暂时冻结账户等待审核。

对于一家小公司来说,这样的风险几乎是致命的。“这笔账单远远超过我们银行账户里的钱。” RatonVaquero 写道。

数千个 API 密钥可能被滥用

更值得注意的是,这起事件可能只是更大问题的一部分。

据外媒 The Register 报道,美国网络安全公司 Truffle Security 的研究人员在对数百万个网站进行扫描后发现,至少 2863 个 Google API 密钥原本只用于标识计费项目,如今却可以直接用于 Gemini API 身份验证。

这意味着,一旦攻击者获取这些密钥,就可能直接调用大模型接口,不仅能访问相关账户中的上传文件和缓存数据,还能不断消耗 API 配额,把所有计算费用转嫁到密钥拥有者身上。

对此,Truffle Security 研究员 Joe Leon 不久前也发了一篇长文进行了深度解析为什么会有这种情况发生。

Truffle Security 指出,问题的根源,是 Google Cloud 使用同一种 API Key 格式(以 AIza... 开头)来处理两种本质上完全不同的用途:公开身份识别和敏感认证。

多年来,Google 一直明确告诉开发者,API Key 可以安全地嵌入客户端代码中。Firebase 官方的安全清单中也明确指出,API Key 并非机密信息。

注意:这些 API Key 与用于驱动 GCP 的服务账户 JSON Key 是完全不同的。

Google Maps JavaScript 文档也指导开发者,将 API Key 直接粘贴到 HTML 中。

这在当时是合理的。API Key 的设计初衷是作为项目的标识符,用于计费,并可以通过 HTTP Referer 白名单等方式进行限制(虽然这些限制可以被绕过)。它们并非设计为认证凭证。

然而,随着 Gemini 的出现,情况发生了变化。

当你在 Google Cloud 项目中启用 Gemini API 时,该项目中现有的 API Key(包括那些已经嵌入在你网站公共 JavaScript 中的 Key)会在不发出任何警告、确认对话框或邮件通知的情况下悄然获得访问敏感 Gemini 端点的权限。

这带来了两个问题:

  1. 权限溯源扩张(Retroactive Privilege Expansion)。你三年前创建了一个 Maps Key,并严格按照 Google 的指引嵌入到网站源代码中。上个月,你团队的某个开发者为内部原型启用了 Gemini API。现在,你的公共 Maps Key变成了 Gemini 的认证凭证。任何抓取到它的人都可以访问你的上传文件、缓存内容,并让你的 AI 账单飙升。没有人通知你这一变化。
  2. 默认配置不安全(Insecure Defaults)。当你在 Google Cloud 创建一个新的 API Key 时,默认状态是“无限制”,意味着它立即对项目中所有已启用的 API(包括 Gemini)有效。UI 会显示“未经授权使用”的警告,但架构上的默认配置本身是完全开放的。

结果:成千上万原本用于计费的无害 API Key,如今成为了公开网络上的 Gemini 凭证。

在这种情况下,攻击者可以访问你的网站,查看页面源代码,然后从 Maps 嵌入中复制你的 AIza... Key。接着他们运行:

curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"

结果不是 403 Forbidden,而是直接返回 200 OK。从这里开始,攻击者可以:

  • 访问私有数据:/files/ 和 /cachedContents/ 端点可能包含上传的数据集、文档和缓存的上下文。项目所有者通过 Gemini API 存储的任何内容都可以被访问。
  • 造成账单费用激增:Gemini API 的使用并非免费。根据模型和上下文窗口大小,攻击者如果不断调用 API,单个受害账号每天可能产生数千美元的费用。
  • 耗尽配额:这可能会彻底中断你合法的 Gemini 服务。

攻击者甚至不需要接触你的基础设施,他们只需从公共网页抓取一个 Key 就能完成攻击。

而当前墨西哥开发者 RatonVaquero 正在经历上述的一种情况。


漏洞披露后修复进展缓慢

实际上,Truffle Security 这家安全公司早在 2025 年 11 月就已经向 Google 的漏洞披露项目提交过相关报告,但当时 Google 将其认定为“预期行为”,并未引起重视。

直到同年 12 月 1 日,研究人员提交了一个来自 Google 自身基础设施的案例——一个在 2023 年部署于公开网站上的 API 密钥,如今仍然可以直接调用 Gemini API——Google 才重新评估这一问题。

随后,Google 将该报告从“客户问题”重新归类为“系统漏洞”,并提高了问题严重等级,开始推进修复工作,同时向 Truffle Security 索要那 2863 个暴露密钥的完整清单。

然而截至 2026 年 2 月 2 日,Google 向研究人员反馈称,仍在研究和努力修复问题。

随着 90 天漏洞披露窗口期的结束,Truffle Security 团队将这一问题公开出来。研究员 Joe Leon 表示,目前尚未看到任何“具体结果”。

社区讨论:问题究竟出在哪里?

如今 RatonVaquero 的遭遇也在开发者社区引发了讨论。

有网友怀疑,这起事件是否与最近流行的“氛围编码”有关,认为自动生成代码的工具可能会在无意中泄露密钥。但 RatonVaquero 很快回应称,他们并没有使用这类方式开发。

也有开发者给出了更现实的建议,“说实话,坚持联系 Google 可能是唯一的办法,不要放弃,希望总是存在的。”

对此,你怎么看这一问题?

参考:

https://old.reddit.com/r/googlecloud/comments/1reqtvi/82000_in_48_hours_from_stolen_gemini_api_key_my/

https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules

https://www.theregister.com/2026/03/03/gemini_api_key_82314_dollar_charge

推荐阅读:

Agent取代App、机器人“盲区”、RAG成本失控……2026 奇点智能技术大会首批议题发布

万人大厂一夜裁员4000+人!她拼命用AI提效,却在凌晨12:30等来解雇通知

岗位一朝被Meta砍掉,工程师转头训练小狗敲键盘,竟靠Claude把乱码做成了游戏,还开源了!

未来没有前后端,只有 AI Agent 工程师。

这场十倍速的变革已至,你的下一步在哪?

4 月 17-18 日,由 ZEEKLOG 与奇点智能研究院联合主办「2026 奇点智能技术大会」将在上海隆重召开,大会聚焦 Agent 系统、世界模型、AI 原生研发等 12 大前沿专题,为你绘制通往未来的认知地图。

成为时代的见证者,更要成为时代的先行者。

奇点智能技术大会上海站,我们不见不散!

Read more

【性能提升300%】:基于Python的多模态数据分块存储优化实践

第一章:【性能提升300%】:基于Python的多模态数据分块存储优化实践 在处理图像、文本与传感器数据等多模态数据时,传统单一存储结构常导致I/O瓶颈和内存浪费。通过引入分块存储策略与异步写入机制,结合Python中的HDF5与Zarr库,可显著提升数据读写效率。 设计高效的分块策略 合理的分块大小能平衡磁盘访问与内存占用。对于高分辨率图像与长序列文本,采用动态分块策略: * 图像数据:按 (64, 64, 3) 分块,适配常见卷积网络输入 * 文本序列:按 token 数量切分为长度为512的块 * 传感器数据:按时间窗口(如每秒100条)进行分段 使用Zarr实现压缩与并行访问 Zarr支持分层数组存储,并内置多种压缩算法。以下代码展示如何将多模态数据写入Zarr容器: # 导入必要库 import zarr import numpy as np # 创建根组 root = zarr.group() # 存储图像块,使用Blosc压缩 images = root.zeros('

By Ne0inhk
基于Python的医院运营数据可视化平台:设计、实现与应用(上)

基于Python的医院运营数据可视化平台:设计、实现与应用(上)

一、引言 1.1 研究目的与意义 在信息技术日新月异的当下,医疗行业正处于深刻的变革之中,逐渐朝着信息化、智能化方向大步迈进。医院每天都会产生海量的数据,涵盖患者信息、诊疗记录、药品库存、设备使用状况等多个关键领域。这些数据宛如一座蕴藏丰富的宝藏,若能加以科学有效的管理与分析,将为医院的运营管理提供强大的支持,成为提升医疗服务质量、优化资源配置的关键要素。然而,传统的数据处理方式,如过度依赖 Excel 表格和简单的统计工具,在面对如此庞大且复杂的数据时,显得力不从心,效率极为低下,难以满足医院日益增长的复杂分析需求。 基于此,本研究旨在构建一个基于 Python 的医院运营数据可视化平台,将 Python 语言的强大功能与数据可视化技术深度融合,为医院运营管理开辟全新的路径。Python 作为一种高级编程语言,以其简洁性、易读性以及丰富多样的扩展库,如 Pandas、Matplotlib 等,在数据处理和可视化领域展现出卓越的优势,能够高效地实现数据清洗、分析以及可视化图表的生成。 本研究具有重要的现实意义。对于医院管理而言,该平台能够极大地提高运营管理的效率。

By Ne0inhk

Python 爬虫实战:爬取音乐平台(网易云 / QQ 音乐)歌曲信息

前言 音乐平台汇聚了海量的歌曲资源,包含歌名、歌手、专辑、播放量、歌词等核心信息,这些数据在音乐趋势分析、个性化推荐研究、音乐版权管理等场景中具有重要价值。传统手动整理歌曲信息的方式效率极低,而基于 Python 的爬虫技术能够批量采集音乐平台的歌曲数据,大幅提升数据获取效率。本文以网易云音乐和 QQ 音乐两大主流平台为例,系统讲解歌曲信息爬取的技术方案、接口解析方法及数据结构化处理,为音乐数据分析师和开发者提供可落地的实战指南。 摘要 本文聚焦音乐平台歌曲信息的爬取实战,分别以网易云音乐网页版和QQ 音乐网页版为核心操作对象(可直接点击进入对应平台),从抓包分析接口、构造请求参数,到多维度歌曲信息提取、数据清洗与存储,完整实现歌名、歌手、专辑、播放量、时长等核心字段的采集。文中包含可直接运行的代码案例、接口参数说明表格及数据输出结果,兼顾技术深度与实操性,帮助读者掌握不同音乐平台歌曲数据爬虫开发的核心技术。 一、技术栈与原理概述 1.1 核心技术栈 < 技术 / 库功能说明

By Ne0inhk
详解如何从零用 Python复现类似 GPT-4o 的多模态模型

详解如何从零用 Python复现类似 GPT-4o 的多模态模型

🧠 向所有学习者致敬! “学习不是装满一桶水,而是点燃一把火。” —— 叶芝 我的博客主页:https://lizheng.blog.ZEEKLOG.net 🌐 欢迎点击加入AI人工智能社区! 🚀 让我们一起努力,共创AI未来! 🚀 我们将逐步编写一个非常简单的类似 GPT-4o 的多模态架构,它可以处理文本、图像、视频和音频,并且能够根据文本提示生成图像。帮助你详细理解逐步实现的过程。 这里推荐一个非常棒学习网站,点击跳转学习 项目代码 以下是这个简单多模态模型将具备的功能: * 像语言模型(LLM)一样用文本聊天(使用 Transformer) * 用图像、视频和音频聊天(使用 Transformer + ResNet) * 根据文本提示生成图像(使用 Transformer + ResNet + 特征方法) 简单的 GPT-4o 架构 Tiny GPT-4o 架构 下文我们将实现以下内容: 1. 从头开始编写了自己的 BPE

By Ne0inhk