pgjdbc 修補 requireAuth 全排除反而不設限的漏洞
PostgreSQL JDBC Project · 版本 2026-10-07，公告貼文 2026-10-09
pgjdbc 的 requireAuth 連線參數原本在「排除所有已知驗證方法」時，不是拒絕連線，而是完全不做限制，42.7.14 把它改成直接失敗。同一版還修掉另一個問題：短於宣告長度的值，其填充位元組不再是零，而是同一連線上先前訊息的殘留內容。兩者分別是 CVE-2026-107314 與 CVE-2026-107315，GitHub 評級皆為 Moderate。
漏洞機制：null 同時代表「沒設定」與「全禁止」
GHSA-rhp9-mr79-r74h（CVSS 5.9，CWE-636）的根因在 AuthMethod.parseRequireAuth：它在屬性未設定與「沒有任何方法被允許」兩種情況下都回傳 null，而 checkAuth 把 null 解讀為不限制。
所以有人為了「禁用一切弱驗證」把六種已知方法（password、md5、gss、sspi、scram-sha-256、none）全部排除，或寫出像 requireAuth=, 這種不含任何方法的值，驅動程式實際上什麼都沒擋。
// 42.7.11 ~ 42.7.13：以下設定等於沒設
requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none
requireAuth=,位於應用程式與資料庫之間的攻擊者可以要求明文密碼驗證，並取得資料庫密碼。advisory 將攻擊複雜度與機密性影響分別評為高與高。更麻煩的是，受影響的部署看起來完全正常，因為連線照樣成功。
第二個問題：填充位元組帶出舊訊息
GHSA-f64h-wr5q-3qf3（CVSS 5.3，CWE-201、CWE-226）發生在應用程式宣告的長度大於實際寫入資料時。驅動程式為了維持已送出的協定訊息長度，會補上差額；42.7.3 以前補零，從 42.7.4 起，writeZeros 在送出緩衝區為空時沒有清零，卻把殘留的緩衝內容送了出去。
受影響的入口包括：
PreparedStatement.setObject搭配ByteStreamWriterCopyIn.writeToCopy（兩個 overload）PGCopyOutputStream.write，寫入量超過其 64 KiB 緩衝時LargeObject.write與Blob.setBytes
被存進資料庫的值可能夾帶先前語句的 SQL 文字與參數值，包含連線池中其他請求的語句。填充量最多可達 maxSendBufferSize（預設 8192 位元組，GSS 加密時為 16320）。若攻擊者能讓應用程式存下這種值再讀回，就能反覆蒐集先前的流量。
受影響版本
| CVE | 影響版本 | 修補版本 |
|---|---|---|
CVE-2026-107314 | 42.7.11 至 42.7.13 | 42.7.14 |
CVE-2026-107315 | 42.7.4 至 42.7.13 | 42.7.14 |
影響範圍與修補
第一個問題只影響用排除式寫法設定 requireAuth 的服務。未設定、正向清單（如 requireAuth=scram-sha-256）或部分排除（如 requireAuth=!password,!md5）都不受影響。升級後，排除全部方法的值會以 SQLState 08004 拒絕連線，不含方法名的值（如 ,）則以 SQLState 22023 失敗，參見release notes。換句話說，升級後原本「正常」的連線會斷，要先把設定改成伺服器實際使用方法的正向清單。
無法立即升級時，advisory 列出的緩解是：
- 以正向清單取代
requireAuth的值。 - 走 SCRAM over TLS 的話設
channelBinding=require，會拒絕包含明文密碼在內的非 SCRAM 方法；需伺服器支援SCRAM-SHA-256-PLUS，因此不適用 md5、GSS、SSPI。 - 對受信任的 CA 使用
sslmode=verify-full，防止偽造伺服器。
第二個問題沒有連線屬性可以關閉。正確的應用程式不受影響，因此要檢查的是：用 ByteStreamWriter、COPY 或 LargeObject 寫入時，宣告長度是否與實際寫入量一致。advisory 也提醒，受影響版本已經寫入的資料可能含有殘留內容，升級不會清掉它們；是否需要清查歷史資料，release notes 未說明。
原始來源：PostgreSQL 公告、GHSA-rhp9-mr79-r74h、GHSA-f64h-wr5q-3qf3、42.7.14 release notes