CloudNativePG 監控匯出器漏洞：低權限資料庫帳號可升成超級使用者，請升到 1.28.3 或 1.29.1

一句話看懂：CloudNativePG 的監控程式用「超級使用者」身分連進資料庫，只是在上面蓋一層低權限的外衣；外衣可以被脫掉，低權限帳號就可能升成超級使用者並在資料庫 Pod 內執行系統指令，請升到 1.28.3 或 1.29.1。

先用白話講：這個漏洞怎麼發生的？

想像一位保全每天要巡視大樓，為了方便，他拿的是「總鑰匙」，但上班前被要求「穿上實習生制服」，假裝只有實習生權限。問題是：制服可以自己脫掉，脫掉後總鑰匙還在手上。

CloudNativePG 的指標匯出器就是這樣：它用 postgres 超級使用者連線，再用 SET ROLE 降成 pg_monitor（監控專用角色），但連線的真實身分還是超級使用者。

發生什麼事

GitHub 公告（5 月 11 日）說明：

• 在匯出器執行的查詢裡，只要有運算式能呼叫 RESET ROLE，就能恢復超級使用者權限
• 接著可利用 COPY … TO PROGRAM，在主要 Pod 內以 postgres 身分執行作業系統指令
• 從低權限資料庫角色到取得這些能力，可在一個抓取週期內（30 秒以內）完成
• GitHub 公告列的 CVSS 為 9.9（嚴重）

兩條受影響的路徑

公告還提到：若應用程式本身有 SQL 注入，攻擊者也可能藉此一路打到資料庫 Pod。

修補方式與版本

• 修補版本：1.28.3（1.28 系）與 1.29.1（1.29 系）
• 預設查詢改為明確指定結構（schema-qualify）：關閉路徑 2；若你把預設監控設定複製到自己的 ConfigMap，必須自行修改
• 專用角色：匯出器改用 cnpg_metrics_exporter（只有 pg_monitor 權限、無超級使用者），從根本解決問題
• 縱深防禦：監控交易會把 pg_catalog 放到 search_path 最前面

升級時要注意

• 原本靠超級使用者權限的自訂查詢（例如讀取沒有授權給新角色的使用者資料表，或 pg_authid 這類系統表）會失敗，需要對 cnpg_metrics_exporter 明確授權
• 有複本叢集時，要先升級來源主叢集，再升級複本叢集，否則複本會因為缺少該角色而抓取失敗

來不及升級的暫時做法（官方列的）

1. 在自訂指標查詢中，把所有目錄函式與檢視加上 pg_catalog 前綴，這只是部分緩解
2. 限制只有完全可信的角色才能擁有被抓取叢集裡的資料庫；PostgreSQL 15 以前 public 預設把 CREATE 權限給所有人，風險更高

給開發者的技術細節

• 公告特別說明，只把連線降成 pg_monitor 或用 SET SESSION AUTHORIZATION 都不夠，因為認證身分仍是 postgres；只有改用不同的認證身分才能徹底關閉問題
• 專用角色是無密碼的，帶外設定的密碼會在下次協調時被清掉

我的看法

這個漏洞最值得注意的一點是：問題出在「監控」這種大家覺得無害的附屬功能，而且預設設定就中。自架 Kubernetes 資料庫的人常把心力放在備份與高可用，容易忽略監控元件擁有的權限。

實務上我的建議是：先升級並確認新角色上線；接著盤點自己的自訂監控查詢；最後檢討「誰能擁有資料庫」，因為這個漏洞需要有資料庫擁有權或建立物件的權限才能觸發。多租戶或給客戶共用的資料庫叢集，更要優先處理。

名詞小辭典

• CloudNativePG：在 Kubernetes 上管理 PostgreSQL 的開源營運工具。
• 超級使用者：資料庫裡權限最高的角色，什麼都能做。
• 指標匯出器：定期向資料庫查詢狀態，提供給監控系統的小程式。
• search_path：資料庫解析名稱時搜尋結構的順序，順序被利用就可能引到假的物件。

資料來源

• GitHub 安全公告：GHSA-423p-g724-fr39（CloudNativePG，2026-05-11 發布）