一句話：Grok Build 的分享連結沒有被破解，是被「查」出來的——隨機 App 名稱放在子網域，等於自動登記到公開的被動 DNS 資料庫，任何人用萬用字元查一次就拿到整份清單。43,601 個位址裡，35,578 個（94.7%）免登入就能開啟，其中 24 個是 SpaceXSI 自己員工做的內部 App。
規模：不是幾十個設定失誤，是預設值
資安研究公司 Claroc 在 2026 年 11 月 10 日公開《GhostShares 2: Grok Apps Exposed》。研究團隊在 11 月 8 日從公開網際網路、未登入任何帳號的狀態，逐一開啟每個 App 的首頁（等同無痕視窗的訪客），結果如下：
| 項目 | 數字 |
|---|---|
掃描的 grok.me 位址 | 43,601（Claroc 部落格另記一輪 43,551，兩者都是「四萬多」的量級） |
| 測試期間仍上線 | 37,571 |
| 免登入即可開啟 | 35,578（94.7%） |
| 需要登入（回 HTTP 401） | 1,993 |
| 由 SpaceXSI 與 X 員工自建 | 24 |
| 可辨識的受害組織 | 30 家（26 家員工超過 1,000 人、6 家 Fortune 500） |
| 判定含私人或內部資料 | 650–800 個（約每 10 個有 1 個敏感，約 2% 達高或重大等級） |
絕大多數公開 App 是遊戲、落地頁、計算機這類無害內容，這是可以理解的：Grok Build 的定位就是「用一句話生出小工具」。問題在於那 10%——一旦有人把真實的員工名冊、病患檢驗、報價單丟進去，一個「Anyone with the link」預設值就等於把它貼在牆上。
時間軸也值得記下來：
| 日期 | 事件 |
|---|---|
| 2026-08 | Grok Build 擴大開放，三個月內累積數萬個上線 App |
| 11-08 | Claroc 開始掃描，當天依 security.txt 通報首批（含一份到職計畫與廣告提案），並附上四項修法建議 |
| 11-09 | 補通報其餘 22 個內部員工 App 的細節 |
| 11-10 | 公開報告；Ars Technica 詢問 SpaceXSI 後數小時，24 個員工 App 全部下架，其餘三萬多個使用者 App 未處理 |
技術根因：把秘密放在網域左邊，DNS 就替你公開
Grok Build 幫每個發佈的 App 配一個獨立主機名稱，格式是四個隨機單詞加網域，例如 cinder-crane-sand-frost.grok.me。設計用意不難懂：四個隨機詞不好猜，只有拿到連結的人進得去。這是所謂 capability-based access control——「持有網址」本身就當授權。
問題是連線的第一步一定得查 DNS。使用者打開 App，瀏覽器先向遞迴解析器問「這個主機的 IP 是多少」；被動 DNS（passive DNS）感測器就架在遞迴解析器與權威伺服器之間，把每一次快取未命中的查詢記錄成「網域 → IP、首次看到、最後看到、次數」的歷史資料。商業情資庫再把這些記錄索引起來，支援 *.grok.me 這種萬用字元查詢。
於是隨機性完全失效：攻擊者不需要猜，資料庫已經幫他列好。Claroc 就是這樣拿到四萬多個位址的。
關鍵的對照是「隨機字串放在哪一層」：
| 做法 | 範例形式 | DNS 查詢看得到隨機碼嗎 |
|---|---|---|
| 子網域（Grok Build） | cinder-crane-sand-frost.grok.me | 看得到，整串進入 pDNS 歷史紀錄 |
| 路徑（Google Docs） | docs.google.com/document/d/1BxiMVs0… | 看不到，隨機碼藏在 HTTPS 路徑內 |
| 路徑（Claude Artifacts） | claude.ai/public/artifacts/… | 看不到 |
| 路徑（ChatGPT 分享） | chatgpt.com/share/… | 看不到 |
差別在於：DNS 只處理主機名稱，路徑要在 TLS 連線建立之後才會送出，而那段是密文。同一個「長亂碼 + 只有拿到連結的人知道」的設計，放在路徑上仍然成立；放在子網域上則等於向全世界登記。這不是 Grok 獨有的失誤——Claroc 指出 Lovable、Bolt、Replit 也為每個 App 配獨立主機名稱，同樣的列舉手法可以套用；Meta 的 Muse 在 2026 年 10 月就以同樣方式被掃出 6,800 多個分享（Claroc 稱之為 GhostShares 1），事後 Meta 暫停了分享功能。
到底開了什麼：從病患檢驗到明文密碼
Claroc 沒有公布主機名稱與連結，只描述類別與數字，並自行通知受害組織。已知的案例包括：
| 受害類型 | 內容 | 規模數字 |
|---|---|---|
| SpaceXSI 自家 | 企業銷售到職計畫（標註機密，含內部系統位址、19 個內部頻道）、594 個策略客戶的業務區域地圖、8 份 X 廣告提案（一份給美國聯邦機構）、4 個廣告主即時看板 | 24 個 App，僅 1 個設了密碼 |
| 醫療 | 秘魯建設公司的職業健康儀表板 | 3,784 份員工健檢紀錄 |
| 醫療 | 醫院集團員工名冊 | 約 3,500+ 人姓名與員工編號 |
| 醫療 | 加護病房簡報 | 1 名病患的檢驗值、影像、呼吸器狀態 |
| 員工資料 | Tesla 服務中心計分卡（含獎金狀態） | 22 名技師 |
| 員工資料 | 美國海軍物流包商的合約人力名單 | 108 人 |
| 員工資料 | 豪華郵輪廚房檢查表、消防局值班板 | 姓名、員工編號、警徽號碼 |
| 憑證 | 外包商工時表 App：瀏覽器下載的程式碼內含明文密碼 | 18 組帳號，含管理員 |
| 商業 | 汽車運輸報價台 | 約 4,000 筆訂單與利潤率 |
| 商業 | 建商銷售拜訪表、國防集團炸藥廠裝載調度板 | 583 名潛在客戶、載重程序 |
那份工時表是最能說明風險的一筆：資料不是存在伺服器後端，而是寫在前端程式碼裡，任何訪客的瀏覽器都會下載到——包含管理員的明碼密碼。這種「AI 幫你寫的內部小工具」特別容易產出前端直連資料庫、沒有登入層的架構。
第二個問題：AI 寫的登入邏輯，順序是反的
Claroc 另外做了兩個受控測試 App，第二個測試暴露更嚴重的問題。那份「四人業務團隊客戶名單」App，Grok 主動加上了 Google 與 X 登入按鈕，看起來很正確，但程式碼的順序是：
- 訪客完成 Google 登入
- 先把登入者加入團隊成員
- 才檢查「這個人是不是團隊成員」
第 3 步的檢查因此永遠通過。任何一個拿得到連結、有 Google 帳號的陌生人，都能讀取、修改、刪除整份客戶資料。Claroc 表示只在自家測試 App 上做過寫入與刪除測試。
這是「AI 生成的授權邏輯」比「AI 生成的排版」危險一整個量級的例證：畫面看起來對、按鈕也在，但檢查點的順序決定了它是不是後門。
官方怎麼說，研究方怎麼回
SpaceXSI 對記者的說法是：App 在建立者選擇分享前都是私密的，發佈需要多個步驟並附法律聲明，員工帳號預設為「Only you」。被 SpaceXSI 收購的 Cursor 代表也向 Ars Technica 表示「App 預設私密，除非建立者選擇分享，否則不會公開」，但未回覆後續追問。
Claroc 的反駁建立在實測上：在它使用的付費帳號中，按下發佈後跳出的存取面板，預設已勾選「Anyone with the link」，另兩個選項是「Invited users」與「Only you」。若需要「多步驟」才發佈，那麼這三萬多個公開 App 的建立者全都走過同樣的步驟——多點幾下滑鼠不會改變最後一格被預設成什麼。至於「員工帳號預設 Only you」，自家 24 個內部 App 就是反證。
另一個對照：ChatGPT 新建 App 分享時預設是「Only me」，位址同樣會進 DNS，但點進去只有本人能開。同一個技術條件，預設值不同，後果就不同。
開發者與企業現在該做的事
這起事件與其說是 Grok 的問題，不如說是一個可以套用到所有「一句話生 App」平台的操作清單：
- 清查影子 IT：問一輪團隊用過哪些 AI App 產生器（Grok Build、Lovable、Bolt、Replit 等），這些工具不需要 IT 核准就能上線。
- 用外部帳號實測存取：開無痕視窗、不登入，直接開連結。開得起來就是公開。
- 把「private」當成部分修補：切到 invited users 只解決人的部分，主機名稱早已在 pDNS 歷史裡；真要下線就得 unpublish（Grok 的下架在數秒內生效）。
- 搜前端原始碼找機密：AI 生成的小工具常把 API key、資料庫字串、帳密寫進前端程式碼，搜
password、secret、apikey一分鐘就有答案。 - 上傳前先分類資料：員工名冊、病患資料、未公開財報、客戶 PII 一律不進這類工具，測試用合成資料。
- 憑證視同外洩：只要曾在這類 App 裡出現過的密碼與金鑰，直接輪換，不要評估「應該沒人看到」。
- 平台端的三個修法（Claroc 給 SpaceXSI 的建議，也適用自建同類服務）：把 App 放到單一主機下的長路徑、預設改為「Only you」並在發佈前明示誰能開、偵測到「有資料庫但沒有登入」時主動警告。
對企業資安團隊還有一招：把 grok.me、lovable.app 這類網域加進 egress 日誌與被動 DNS 情資的監控清單，定期查自家公司名稱是否出現在公開 App 的標題或內容裡。
這不是 Grok 第一次
同一家公司在 2025 年 8 月被找到 37 萬則分享出去的 Grok 對話出現在 Google 搜尋結果；2026 年 7 月，Grok Build 的命令列工具被發現會把使用者的整個專案（含 Git 歷史與已提交的密鑰）上傳到公司雲端。加上這次，模式已經很清楚：功能跑得比存取控制快。
真正該記住的不是「Grok 又出事」，而是那個 94.7%。當一個平台的預設值讓「公開」變成不作為的結果，使用者要做的不是更小心地按下一步，而是假設自己按下的每一格都是公開的。
站內延伸閱讀
（本文含聯盟連結揭露：無。文中提及之研究與官方說法均依 2026-11-10 至 11-11 的公開資料整理，數字以 Claroc 報告與 Ars Technica 報導為準。）