PostgreSQL Global Development Groupは2026年5月14日、PostgreSQL 18.4、17.10、16.14、15.18、14.23を公開しました。今回のリリースでは、11件のセキュリティ脆弱性と60件超の不具合が修正されています。
今回の更新で特に注意が必要なのは、CVSS v3.1スコア8.8の脆弱性が複数含まれている点です。PostgreSQLサーバ側のメモリ破壊、refintモジュールにおける任意コード実行、libpq経由のクライアント側メモリ破壊、pg_basebackupやpg_rewindのファイル上書きなど、運用形態によってはデータベースサーバや管理端末に影響する可能性があります。
また、PostgreSQL 14については、2026年11月12日に修正提供が終了することもあわせて告知されました。PostgreSQL 14を本番環境で利用している組織は、今回のマイナーアップデート対応だけでなく、PostgreSQL 15以降への移行計画も進める必要があります。
この記事のサマリー
- PostgreSQL 18.4、17.10、16.14、15.18、14.23が公開されました。
- 今回のリリースでは、11件のセキュリティ脆弱性と60件超の不具合が修正されています。
- CVSS 8.8の高危険度脆弱性として、CVE-2026-6473、CVE-2026-6475、CVE-2026-6477、CVE-2026-6637が含まれます。
- 影響範囲はPostgreSQL 14〜18が中心ですが、一部はPostgreSQL 16〜18、17〜18、18のみが対象です。
- PostgreSQL 14は2026年11月12日に修正提供が終了します。
- PostgreSQLのマイナーアップデートでは、通常、ダンプ・リストアや
pg_upgradeは不要で、バイナリ更新とサービス再起動で対応できます。 - 情シス・DBA・SREは、稼働中のPostgreSQLバージョン、利用拡張、バックアップ運用、論理レプリケーション、MD5認証の有無を確認する必要があります。
目次
何が起きたか
PostgreSQL Global Development Groupは、サポート対象の全ブランチに対するセキュリティアップデートとして、PostgreSQL 18.4、17.10、16.14、15.18、14.23を公開しました。今回のリリースは、11件のセキュリティ脆弱性と60件超の不具合修正を含みます。
PostgreSQL 14〜18の広い範囲に影響する脆弱性が複数含まれており、特にCVSS 8.8の脆弱性は、任意コード実行、メモリ破壊、ファイル上書き、クライアントツールへの影響など、運用形態によって深刻な被害につながる可能性があります。
影響範囲
影響を受けるのは、PostgreSQL 18.4、17.10、16.14、15.18、14.23より前の対象バージョンです。
PostgreSQL 14〜18の全般に影響する脆弱性が多く含まれていますが、一部の脆弱性は特定バージョンに限定されます。
CVE-2026-6476はPostgreSQL 17〜18、CVE-2026-6638はPostgreSQL 16〜18、CVE-2026-6575はPostgreSQL 18のみが対象です。
| 確認対象 | 見落としやすいポイント |
|---|---|
| 本番DBサーバ | OSパッケージ管理外で手動導入されたPostgreSQL |
| 検証・開発DB | 本番より古いバージョンが残りやすい |
| バックアップサーバ | pg_dump、pg_basebackup、pg_rewind、libpqが古いまま残る可能性 |
| アプリケーションサーバ | libpqやPostgreSQLクライアントツールを同梱している場合がある |
| コンテナイメージ | ベースイメージ内のPostgreSQLクライアントが古い可能性 |
| Kubernetes環境 | StatefulSet、Operator、サイドカー、管理ツールのバージョン確認が必要 |
| 製品同梱DB | バックアップ製品、監視製品、業務アプリに同梱されたPostgreSQL |
修正された主な脆弱性
| CVE | CVSS | 影響バージョン | 概要 |
|---|---|---|---|
| CVE-2026-6472 | 5.4 | 14〜18 | CREATE TYPEでmultirangeスキーマのCREATE権限確認が不十分 |
| CVE-2026-6473 | 8.8 | 14〜18 | サーバ機能の整数ラップアラウンドにより、領域不足のメモリ確保と境界外書き込みが発生する可能性 |
| CVE-2026-6474 | 4.3 | 14〜18 | timeofday()でサーバメモリの一部が漏えいする可能性 |
| CVE-2026-6475 | 8.8 | 14〜18 | pg_basebackupとpg_rewindで、元サーバのスーパーユーザーがローカルファイルを上書きできる可能性 |
| CVE-2026-6476 | 7.2 | 17〜18 | pg_createsubscriberのサブスクリプション名を悪用したSQLインジェクション |
| CVE-2026-6477 | 8.8 | 14〜18 | libpqのlo_*関数経由で、サーバスーパーユーザーがクライアント側スタックメモリを上書きできる可能性 |
| CVE-2026-6478 | 6.5 | 14〜18 | MD5ハッシュ済みパスワードをタイミングチャネルで推測される可能性 |
| CVE-2026-6479 | 7.5 | 14〜18 | SSL/GSSネゴシエーションの再帰処理によりDoSが発生する可能性 |
| CVE-2026-6575 | 4.3 | 18 | pg_restore_attribute_stats()で統計配列の範囲外読み取りが発生する可能性 |
| CVE-2026-6637 | 8.8 | 14〜18 | refintモジュールのスタックバッファオーバーフローとSQLインジェクション |
| CVE-2026-6638 | 3.7 | 16〜18 | 論理レプリケーションのREFRESH PUBLICATIONでテーブル名を悪用したSQLインジェクション |
特に注意すべき脆弱性
CVE-2026-6637:refintモジュールで任意コード実行の恐れ
CVE-2026-6637は、PostgreSQLのrefintモジュールに存在するスタックバッファオーバーフローとSQLインジェクションの脆弱性です。
公式発表では、権限のないデータベースユーザーが、データベースを実行しているOSユーザーの権限で任意コードを実行できる可能性があると説明されています。また、アプリケーションがユーザー制御可能な列をrefintのカスケード主キーとして扱い、その列の更新を許可している場合、SQLインジェクションにより更新実行ユーザーの権限で任意SQLを実行される可能性もあります。
refintは現在の一般的な設計では積極的に使われる機能ではありませんが、古いアプリケーションやレガシーDB、過去に構築された業務システムでは残っている可能性があります。PostgreSQLを長期間運用している環境では、拡張機能や古いモジュールの利用有無を確認する必要があります。
CVE-2026-6477:libpq経由でpg_dumpやpsqlにも影響
CVE-2026-6477は、PostgreSQLのクライアントライブラリlibpqのlo_export()、lo_read()、lo_lseek64()、lo_tell64()などに関係する脆弱性です。
公式発表では、サーバスーパーユーザーが任意に大きいレスポンスを返すことで、クライアント側のスタックバッファを上書きできる可能性があると説明されています。psqlの\lo_exportやpg_dumpもlo_read()を呼び出すため、悪意ある、または侵害されたデータベースサーバに接続してバックアップや操作を行うクライアント側に影響する可能性があります。
この脆弱性は、PostgreSQLサーバだけを更新すればよい問題ではありません。DB管理者の端末、バックアップサーバ、CI/CD内のダンプ取得ジョブ、移行用サーバにインストールされているpsqlやpg_dump、libpqも確認対象です。
CVE-2026-6475:pg_basebackupとpg_rewindによるファイル上書き
CVE-2026-6475は、pg_basebackupのplain形式とpg_rewindにおいて、シンボリックリンクの扱いにより、元サーバのスーパーユーザーがローカル側の無関係なファイルを上書きできる可能性がある脆弱性です。公式発表では、例としてPostgreSQL OSユーザーの.bashrcの上書きが挙げられています。
PostgreSQLプロジェクトは、この攻撃が実務上問題になるのは、コマンド実行後からサーバ起動までの間に、ファイルを別VMへ移す、VMスナップショットを取得するなどの特定操作を行う場合だと説明しています。
それでも、バックアップ・リストア・レプリカ構築・災害復旧の手順にpg_basebackupやpg_rewindを組み込んでいる環境では、対象バージョンと運用手順を確認する必要があります。
CVE-2026-6473:サーバ側の整数ラップアラウンド
CVE-2026-6473は、複数のPostgreSQLサーバ機能で整数ラップアラウンドが発生し、メモリ確保サイズが不足した状態で境界外書き込みにつながる可能性がある脆弱性です。公式発表では、アプリケーション入力の提供者がこの問題を引き起こし、セグメンテーションフォルトに至る可能性があると説明されています。
直接的な情報漏えいやRCEとして説明されているわけではありませんが、データベースサーバのクラッシュは業務停止につながります。外部入力を受け付けるWebアプリケーションやSaaSでPostgreSQLを利用している場合、可用性の観点からも早期更新が必要です。
PostgreSQL 14のEOLに注意
今回のリリースでは、PostgreSQL 14のEOLも明示されました。
PostgreSQL 14は、2026年11月12日に修正提供が終了します。本番環境でPostgreSQL 14を利用している場合、PostgreSQL 15以降のサポート対象バージョンへの移行計画を進める必要があります。
PostgreSQLは、メジャーバージョンをリリースから5年間サポートし、5年経過後の最後のマイナーリリースをもってEOLとなり、その後はサポート対象外になります。
EOL後は、新たな脆弱性が見つかってもコミュニティから修正が提供されません。PostgreSQL 14を使い続ける場合、脆弱性対応、監査対応、セキュリティ基準への適合、障害時の原因切り分けでリスクが高まります。
CI/CD・コンテナ環境での確認
PostgreSQLクライアントは、アプリケーションのビルドやマイグレーション処理、バックアップ自動化、テスト環境構築のために、CI/CDやコンテナイメージ内に含まれていることがあります。
特に確認すべきなのは、以下です。
# コンテナ内で確認する例
docker run --rm your-image psql --version
docker run --rm your-image pg_dump --version
Kubernetes環境では、PostgreSQL Operator、StatefulSet、サイドカー、バックアップ用Job、CronJob、管理用Podのイメージを確認してください。








