SCRAM 缺 nonce，PgBouncer 未驗證就當機
PostgreSQL News · 2026-09-23
漏洞機制
PgBouncer 是 Postgres 最常見的連線池中介層，攻擊者甚至不需要通過驗證，就能把它打到當機。核心問題出在 SCRAM 驗證流程：只要客戶端送出的 client-final-message 缺少必要的 nonce 欄位，PgBouncer 在處理時就會觸發程式崩潰，這正是 CVE-2026-19888 的成因。由於驗證流程尚未完成，攻擊者不需要任何合法帳號密碼即可送出這種畸形封包。單一連線就能讓服務程序中斷，直接影響所有仰賴它做連線池的資料庫服務。
同一批修補裡還有另外兩個 CVE，機制各不相同。其中一個同樣不需要驗證身分：封包緩衝區成長邏輯裡有整數溢位，觸發後會讓 PgBouncer 陷入無窮迴圈而失去回應，這是 CVE-2026-6668。第三個則反過來，是由惡意的 PostgreSQL 後端伺服器觸發：SCRAM 的疊代次數沒有上限，後端只要回傳超大疊代次數，PgBouncer 登入處理就會被迫做無上限的運算，這是 CVE-2026-6669。三者共通點都是輸入驗證不足，只是觸發角色不同。
CVE-2026-19888：未驗證客戶端送出缺 nonce 的 SCRAM client-final-message，觸發當機。CVE-2026-6668：未驗證客戶端觸發封包緩衝區成長邏輯的整數溢位，造成無窮迴圈。CVE-2026-6669：惡意 PostgreSQL 伺服器回傳無上限的 SCRAM 疊代次數，造成登入階段無上限運算。
受影響版本
官方公告指出三項 CVE 均已在 PgBouncer 1.26.0 修復，公告本身沒有列出明確的受影響版本區間，只確認修復版本號。同樣地，公告與 pgbouncer.org 的發布說明都沒有附上 CVSS 分數，因此本文只能如實標注：官方公告未提供 CVSS。若團隊仍在使用舊於 1.26.0 的版本，應假設三個問題都存在，盡快排入升級排程。
修補與緩解
從三個 CVE 的機制反推，修補的方向是替每一步輸入補上邊界檢查：SCRAM 訊息缺 nonce 時直接拒絕並安全地結束連線，而不是繼續處理到崩潰；封包緩衝區成長改用避免整數溢位的計算方式；SCRAM 疊代次數則加上上限，超過就視為異常並拒絕。這三個修法都對應同一個原則，也就是不再信任對方送來的數值，不論來源是客戶端還是後端。
對維運團隊而言，最直接的緩解就是升級到 PgBouncer 1.26.0，這也是官方公告唯一給出的修補建議。在升級之前，可以先用網路層限制降低曝險，例如只允許受信任的來源連進 PgBouncer 監聽埠，減少未驗證客戶端能直接送出畸形封包的機會。至於 CVE-2026-6669 這種由後端觸發的情境，則需要重新檢視所連接的 PostgreSQL 伺服器是否都在信任邊界內，因為這個弱點的前提是後端本身已經不可信。
原始來源：PostgreSQL News：PgBouncer 1.26.0 released - Fixes three CVEs、pgbouncer.org：PgBouncer 1.26.0 changelog