觀點 · 資訊分享
Argo CD 唯讀帳號可透過 ServerSideDiff 讀到明文 Secret：5 月 1 日已公告，3.3.9 修正
Argo CD 3.2.0 到 3.3.8 的 ServerSideDiff 端點沒有遮蔽 Kubernetes Secret，擁有唯讀權限的使用者可能取得明文機密。專案在 5 月 1 日已公告嚴重等級 Critical（9.6）並釋出 3.2.11 與 3.3.9，NVD 在 5 月 2 日收錄。
- 發布
- 2026-05-03
- 篇幅
- 約 4 分鐘 · 1,658 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：Argo CD 3.2.0 到 3.3.8 的 ServerSideDiff 端點沒有遮蔽 Kubernetes Secret，有唯讀權限的使用者可能拿到明文機密；專案 5 月 1 日已公告並釋出修正版。
先用白話講：Argo CD 和 Secret 是什麼？
Argo CD 是很多團隊用來把程式部署到 Kubernetes（一種管理大量伺服器的系統）的工具，它會比對「Git 裡寫的樣子」和「叢集裡實際的樣子」。Secret 則是 Kubernetes 用來存密碼、API 金鑰、憑證這類機密的地方。
正常情況下，Argo CD 顯示資源狀態時，會把 Secret 的內容遮成一排星號。這次的問題是：有一個叫 ServerSideDiff 的比對功能，漏掉了遮蔽。
發生什麼事
- 5 月 1 日：Argo CD 專案發布安全公告 GHSA-3v3m-wc6v-x4x3，嚴重等級 Critical，CVSS 9.6，並釋出修正版
- 5 月 2 日：NVD 收錄 CVE-2026-43824，描述的受影響版本相同；公告頁另外標示 CVE-2026-42880
所以這不是 5 月 3 日才揭露的新漏洞，而是專案早已公告、之後陸續補上公開編號。
問題出在哪？
依官方公告，Argo CD 其他回傳資源狀態的端點（例如取得 manifest、取得資源）都會呼叫遮蔽函式；只有 ServerSideDiff 端點把未遮蔽的資料直接放進回應。
公告還說明：Argo CD 本來有另一層防護，會剔除不屬於它管理的欄位，避免真實的 Secret 值透過比對流出；但當應用程式帶有 argocd.argoproj.io/compare-options: IncludeMutationWebhook=true 的標註時，這層防護會被整個略過。
| 項目 | 內容 |
|---|---|
| 受影響版本 | 3.2.0 到 3.3.8 |
| 修正版本 | 3.2.11、3.3.9 |
| 需要的權限 | 只需讀取（唯讀）權限 |
| 影響 | 可取得明文的服務帳號權杖、憑證、資料庫帳密與 API 金鑰等 Secret 內容 |
給開發者的技術細節
- 公告指出，每位已登入的 Argo CD 使用者，在預設的
role:catch-all政策下就有 get 權限，所以「只有唯讀」並不代表風險低 - 要讓機密真的流出，Secret 的 data 欄位需要被至少一個非 Argo CD 的 Server-Side Apply 欄位管理者持有，這是公告列出的利用條件之一
- 官方沒有提供不升級的暫時緩解方式，建議直接升級；升級後可以順便檢查哪些帳號有叢集的讀取權限，並視需要輪替可能暴露過的機密
我的看法
我自己的服務以單一 NAS 為主，沒有用到 Argo CD，但這件事對團隊很有參考價值：很多人會認為「唯讀帳號很安全，隨便發給大家」。這個漏洞說明，只要有任何一個端點忘了遮蔽，唯讀就等於能看到機密。
如果你的團隊有用 Argo CD，我會做三件事：先升級；再盤點誰有登入權限，尤其是預設的 catch-all 政策；最後把可能被讀到的機密當成已外洩評估，必要時輪替。升級修的是程式，但已經被拿走的機密不會因此失效。
名詞小辭典
- GitOps：把系統該長什麼樣子寫在 Git 裡，由工具自動讓實際環境和 Git 保持一致的做法。
- Kubernetes Secret：Kubernetes 用來存放密碼、金鑰等機密資料的物件。
- Server-Side Apply：Kubernetes 讓多個管理者共同維護同一個資源欄位的機制。
- CVSS：漏洞嚴重度評分，滿分 10，9.0 以上屬於嚴重。