PostgreSQL 18.6 等五個版本同日釋出：修補 28 個資安漏洞，多個能執行任意程式碼

一句話看懂：PostgreSQL 一次更新 14 到 18 所有還在支援的版本，修補 28 個資安漏洞，用這套資料庫的網站與系統都該排進近期維護。

先用白話講：PostgreSQL 的「更新」是什麼？

PostgreSQL 是很多網站、App 背後的資料庫，像是一間倉庫，所有客戶資料、訂單都放在裡面。

官方會定期發布「小版本更新」，就像大樓的定期安檢：不會改變大樓格局（功能不變），只修補發現的安全破口與故障。這次的安檢一口氣找到 28 個資安問題。

發生什麼事

PostgreSQL 全球開發團隊在 8 月 13 日同時釋出：

• 18.6、17.11、16.15、15.19、14.24（所有支援中的版本）
• 19 Beta 3（測試版，不建議用在正式環境）

這次修補 28 個資安漏洞與 110 多個錯誤。另外，18.5 因為出現迴歸問題沒有發布，所以 18 這條線從 18.4 直接跳到 18.6。

漏洞嚴重嗎？

官方附上每個漏洞的 CVSS 分數（滿分 10）。我依官方列表自行統計：

其中官方標題寫明「可執行任意程式碼」的包括：regexp 緩衝區溢位（CVE-2026-14664）、to_char 緩衝區溢位（CVE-2026-14669）、pg_dump 緩衝區溢位（CVE-2026-19385）等。另外 CVE-2026-15741 是透過 EXTRACT 引數造成的 SQL 注入。

要留意的是，不只伺服器，psql 與 pg_dump 這類用戶端工具也有漏洞，例如 psql 的 COPY FROM STDIN 提早失敗時，會把資料行當成 psql 指令處理（CVE-2026-6464）。

更新要注意什麼？

官方說明：所有小版本更新都是累積的，不用 dump 再 reload，也不用 pg_upgrade，停止服務、換成新程式、再啟動即可。但有三種情況要多做一步：

1. GIN 索引：舊的平行建索引錯誤，可能讓資料表的 reltuples 變成怪值，導致 autovacuum 永遠不處理它。要檢查，異常就執行 ANALYZE
2. btree_gist：欄位若是 float4、float8（可能含 NaN）或 bit，需要重建索引
3. ltree：標籤超過約 14,653 個的索引可能損壞，需要重建

給開發者的技術細節

官方提供檢查 GIN 資料表的查詢：

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
JOIN pg_index i ON t.oid = i.indrelid
JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

• 發現數值異常的資料表，執行 ANALYZE 資料表名稱;
• 需要重建的索引，用 REINDEX INDEX 索引名稱;
• 之前跳過某些更新版本的人，要看更早版本的發行說明，可能有額外步驟
• 若是用 Docker 映像檔，記得確認標籤已經更新到對應版本

另外，PostgreSQL 14 將在 2026 年 11 月 12 日停止修補，還在跑 14 的專案要開始規劃升級。

我的看法

接案時常遇到客戶的資料庫「裝好就沒再動過」，連跑的是哪個小版本都不清楚。這種情況最危險：資料庫通常是整套系統最值錢的東西，卻最少人維護。

我的建議是三步：先查現在跑的版本，再看是否還在支援期，最後挑一個離峰時段更新並先做好備份。自架在 NAS 或小主機的人也一樣，別因為「只有內網在用」就放著。更新本身不難，麻煩的是 14 版這種快到期的，11 月之後就沒有安全修補了，現在規劃剛剛好。

名詞小辭典

• CVE：公開漏洞的編號，方便大家用同一個代號討論同一個問題。
• CVSS：漏洞嚴重程度的評分，0 到 10 分，越高越嚴重。
• 緩衝區溢位（Buffer Overflow）：程式把資料寫到不該寫的記憶體位置，嚴重時可能被拿來執行惡意程式。
• 索引（Index）：資料庫的「目錄」，讓查詢更快；索引壞了，查詢結果可能出錯。

資料來源

• PostgreSQL 官方公告：18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released（2026-08-13）