Gemini 賬戶 48 小時被盜刷 57 萬，三人創業團隊站在破產邊緣

作者 | 冬梅

“我現在處于震驚和恐慌之中。”

這是帖子的開頭。沒有鋪墊，沒有背景說明，只有一句情緒幾乎溢出屏幕的自白。

開發者 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 實時憑證。

之所以說這是權限提升而不是配置錯誤，是因為事件發生的順序。

1. 開發者創建了一個 API 密鑰并將其嵌入到地圖網站中。（此時，該密鑰是無害的。）

2. Gemini API 已在同一項目中啟用。（現在，同一個密鑰可以訪問 Gemini 的敏感端點。）

3. 開發人員從未被告知密鑰的權限在其底層發生了變化。（密鑰從公共標識符變為秘密憑證

雖然用戶可以限制 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://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

會議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產，Agentic AI 的探索也將從局部試點邁向體系化工程建設！

QCon 北京 2026 已正式啟動，本屆大會以“Agentic AI 時代的軟件工程重塑”為核心主線，推動技術探索從「AI For What」真正落地到可持續的「Value From AI」。從前沿技術雷達、架構設計與數據底座、效能與成本、產品與交互、可信落地、研發組織進化六大維度，系統性展開深度探索。開往 2026 的 Agentic AI 專列即將啟程！匯聚頂尖專家實戰分享，把 AI 能力一次夯到位！

今日薦文

你也「在看」嗎？