2026年8月13日、PostgreSQLプロジェクトはバージョン18.6、17.11、16.15、15.19、14.24をリリースしました。

今回のリリースで28件のセキュリティ脆弱性と110件以上のバグが修正されました。

28件というCVE数は、PostgreSQL史上最多の単一リリースでの修正件数です。

それまでの最多記録は11件で、わずか1四半期前の5月に記録されたばかりでした。28件のうち17件はCVSSスコア8.0以上、9件はタイトルに「任意コード実行」が明記されています。

そして同じアナウンスの中で、期限も改めて示されました。PostgreSQL 14へのセキュリティ修正提供は、2026年11月12日で終了します。

PostgreSQLが「脆弱なソフトウェア」というわけではありません。むしろ逆です。

28件のCVEが1回のリリースで修正されたという事実は、セキュリティプロセスが正しく機能している証です。これまで以上に多くの研究者がPostgreSQLを精査し、実際のバグを発見し、コミュニティがスケジュール通りに修正している——それだけのことです。

問題は、あなたの使っているバージョンがそのスケジュールから外れたときに始まります。PostgreSQL 14に残されたセキュリティリリースはあと1回。それが終われば、以下のようなCVEはすべて、あなたのサーバー上で永久に未修正のまま残ります。

CVEカーブは急角度で上昇している

過去6回分の四半期セキュリティリリースのCVE件数を、PostgreSQLセキュリティページとリリースアナウンスから集計しました。その推移は次のような形をしています。

年単位で合計すると、傾向はさらに鮮明になります。2025年通年でのPostgreSQL CVEは7件。2026年はここまでで44件に達しており、リリースはまだあと1回残っています。

なぜこれほど急増しているのか。率直に言えば、答えは「劣化」ではなく「注目度」です。PostgreSQLが急にC言語を書くのが下手になったわけではありません。セキュリティ研究者やファジングパイプラインの関心が大幅に高まり、これまでにない深度でコードベースが監査されるようになったのです。バグの所在を見れば分かります。to_char()、正規表現マッチング、tsvector、文字列エスケープ――どれも何年も前から存在し、普段のアプリケーションが日常的に呼び出している機能です。

しかしこの説明は、PostgreSQL 14ユーザーを安心させるものではなく、むしろ警戒すべき材料です。研究者の関心の高まりによって押し上げられている発見率は、あなたの使うバージョンのEOL日を境に丁寧に止まってくれるわけではありません。今年44件のCVEを浮き彫りにしたのと同じ手法は、来年も同様にバグを発見し続けます。11月12日に変わるのは、ただ一つ、PostgreSQL 14が修正を受け取れなくなるという点だけです。

今回のバッチの中身

28件のCVEをただ羅列しても理解しづらいため、2026年の脆弱性を5つのテーマに分類しました。深刻度スコアとPostgreSQL 14への該当有無を含む全体の一覧表は、本記事末尾に掲載しています。

1. 日常的に呼び出される関数内のメモリ破壊

これが最も件数の多いカテゴリで、CVSS 8.8のスコアの多くもここに集中しています。to_char()（CVE-2026-14669）や正規表現マッチング（CVE-2026-14664）でのヒープバッファオーバーフロー。tsvectorとtsqueryで確保サイズを過小評価させる整数オーバーフロー（CVE-2026-14662）。カーソル操作（CVE-2026-16239）や関数引数（CVE-2026-14680）から到達可能な型混同。これらは特殊な管理者専用コードパスではありません。アプリケーションがSQL上で日付をフォーマットしたり正規表現を実行したりしていれば、このコードは実際に通っています。

2. ORMからは見えない場所でのSQLインジェクション

アプリケーション層でテストする類のインジェクションではありません。これはデータベース自身の内部処理を通じたインジェクションです。EXTRACT()呼び出しのデパース時にフィールド名がクォートされない問題（CVE-2026-15741）、REFRESH PUBLICATIONにおけるテーブル名（CVE-2026-6638）、pg_createsubscriberにおけるサブスクリプション名（CVE-2026-6476）。パラメータ化クエリやORMのエスケープ処理はここでは無力です。インジェクションはPostgreSQL自体の内部で発生するためです。

3. クライアントツールも標的になる

2026年に繰り返し見られたパターンです。侵害された、あるいは悪意あるサーバーが、接続元のツールを攻撃するというもの。COPY FROM STDINの失敗後にpsqlがデータ行をコマンドとして実行してしまう問題（CVE-2026-6464）、サーバー側のスーパーユーザーが接続元psqlクライアント上で任意コードを実行できる問題（CVE-2026-18408）、pg_dumpのヒープオーバーフロー（CVE-2026-19385）、ラージオブジェクト関数経由でのlibpqスタック上書き（CVE-2026-6477）、pg_basebackupが無関係なクライアントファイルを上書きしてしまう問題（CVE-2026-6475）。ダンプ・リストア運用、クロスサーバーのレプリケーション、完全には信頼できないデータベースへの接続を行っている場合、このカテゴリは他人事ではありません。

4. 静かに潜む認証・権限の隙

個々のスコアは低くても、集まると厄介です。SCRAM認証におけるユーザー列挙オラクル（CVE-2026-14672）。タイミングチャネルを通じたMD5パスワード漏洩（CVE-2026-6478）。ロール変更後も古いプランキャッシュに基づいて判定されてしまう行レベルセキュリティ（CVE-2026-14666）。SSLと組み合わせた際にGSSAPI暗号化の強制がバイパスされる問題（CVE-2026-14681）。これらは、足がかりを横展開に変えてしまうタイプのバグです。

5. contribモジュールも攻撃対象面である

無効化されたはずの暗号方式でpgcryptoが平文にフォールバックしてしまう問題（CVE-2026-14663）。fuzzystrmatchでの範囲外書き込み（CVE-2026-15742）。pg_stat_statements（CVE-2026-14676）とpg_trgm（CVE-2026-14678）でのバッファオーバーラン。refintにおけるプランキャッシュの型混同（CVE-2026-14671）。標準的なPostgreSQL 14インスタンスで\dxを実行すれば、これらのいくつかは導入済みのはずです。

28件すべてがPostgreSQL 14に該当する

14を使い続けている人にとって重要な数字がこれです。今回8月リリースの28件のCVEはすべて、14.24で修正が提供されました。14.24のリリースノートを確認すれば、一覧がそこにあります。2026年通年で見ても、44件中40件がPostgreSQL 14に該当していました。例外の4件は、より新しいバージョンで追加された機能のバグです。

5年選手のブランチが、これらの脆弱性から「卒業」しつつあるわけではありません。見つかっているバグの多くは、14がリリースされるずっと前から存在する安定コードの中にあり、それは14にも18にも等しく影響します。バージョン番号があなたを守ってくれるのではなく、パッチがあなたを守っているのです。

これらのバグは実際に悪用される

28件のパッチ済みCVEと言われても実感が湧かないなら、前回PostgreSQLのバグが攻撃者と出会ったときに何が起きたかを見てください。

2025年2月、Rapid7が公表した CVE-2025-1094は、無効なUTF-8の扱いに起因するPostgreSQLの文字列エスケープ処理のSQLインジェクション脆弱性でした。発見者のStephen Fewer氏は、BeyondTrustのゼロデイ（CVE-2024-12356）の悪用状況を調査する過程でこれを見つけています。このBeyondTrustの脆弱性は、2024年12月に発生し中国系国家支援アクターの犯行とみられる米財務省ワークステーションへの侵害で使われたものです。Rapid7の検証によれば、テストしたあらゆるシナリオにおいて、BeyondTrustの脆弱性を悪用するにはPostgreSQLの脆弱性も同時に悪用する必要がありました。CVE番号が割り当てられるより何カ月も前、PostgreSQLのバグはゼロデイとして、国家レベルの侵入において不可欠な役割を果たしていたということです。

PostgreSQLはこれを数週間で修正し、17.3、16.7、15.11、14.16、そして13.19に反映しました。最後の13.19に注目してください。PostgreSQL 13がこの修正を受け取れたのは、サポート期間内に9カ月の余裕があったからです。もし同じバグが2026年に発見されていたら、世界中のPostgreSQL 13サーバーは今日もなお、修正が二度と来ないまま悪用可能な状態のはずです。そしてそれこそが、11月12日以降のPostgreSQL 14が置かれる状況そのものです。

11月12日以降の計算

PostgreSQLのバージョニングポリシーは明確です。5年間のサポート、その後1回の最終マイナーリリース、そして終了。PostgreSQL 14にとって、その最終リリースは2026年11月12日です。

この数字を先に進めてみましょう。2026年、PostgreSQL 14に該当するCVEは年間おおよそ40件のペースで修正されており、しかも発見ペースは鈍化するどころか加速しています。最終リリースの状態で凍結されたPostgreSQL 14インスタンスは、EOLから1年以内に、既知かつ文書化された未修正の脆弱性を何十件も蓄積することになります。その相当数はCVSS 8.0以上でしょう。そして各CVEには、公開された説明文と、新しいブランチでの公開済み修正コミットが付いてきます。つまり、修正を受け取れなかったバージョンに対するエクスプロイトを書くための「地図」が、公然と公開され続けるということです。

PostgreSQLの四半期セキュリティリリースは11月以降も続きます。しかしPostgreSQL 14ユーザーにとって、それは「パッチを当てられない脆弱性リスト」が増え続けていくだけの存在になります。

アップグレードが簡単なら、とっくにやっているはずだ

5年前のデータベースバージョンを、単なる怠慢で使い続けているチームなどいません。メジャーバージョンのPostgreSQLアップグレードは、それ自体が一つのプロジェクトです。拡張機能の互換性確認、論理レプリケーションによる切り替えまたはダンプ＆リストアによるダウンタイム、新しいオプティマイザの下でのクエリプランの変化、データベースに触れるすべてのサービスにわたるドライバ・ORMの回帰テスト。ベンダーアプリケーションが14でしか認定されていないチームもあれば、変更のタイミングが四半期単位でしか取れないチーム、数百インスタンス規模の環境で「とりあえずアップグレード」が1年がかりのエンジニアリング作業になるチームもあります。

いずれも正当な制約です。しかし11月12日という期限は、そうした事情を一切考慮してくれません。

選べる道は2つ

11月までにPostgreSQL 16、17、18のいずれかに移行できるなら、そうしてください。それがコミュニティの推奨であり、私たちの推奨でもあります。公式のアップグレードドキュメントに移行パスがまとめられていますし、バージョンを上げるごとに、スケジュール通りの修正が受けられる年数を稼ぐことができます。

しかし期限までにアップグレードが間に合わない場合は、PostgreSQL 14をそのまま放置しないでください。PostgreSQL向けHeroDevs Never-Ending Supportは、まさに本記事で紹介したような脆弱性に対して、コミュニティによる提供が終了した後もPostgreSQL 14へのセキュリティ修正を継続します。CVEリストが際限なく積み上がっていくデータベースを運用し続けることなく、移行を正しいペースで進める時間を確保できます。

PostgreSQL 14に残されたセキュリティリリースはあと1回。それを、あなたのデータベースが受け取る最後の修正にしないでください。

付録：2026年に修正されたPostgreSQLのCVE一覧

原文末尾にCVE一覧の表が掲載されています。表データ自体はHTML/グラフィック要素のため、本翻訳では省略しています。原文ページの該当箇所をご参照ください。

お問い合わせ

本記事の内容やHeroDevsのソリューション（NES等）について、日本語でのお問い合わせに対応しています。お気軽にHeroDevsお問い合わせページからご連絡ください。

原文:PostgreSQL 14 EOL Nov 2026: 44 CVEs This Year, One Patch Left