PostgreSQLに脆弱性28件、18.6などで修正

2026年8月13日、PostgreSQL開発チームがサポート対象の全系統について更新版（18.6 / 17.11 / 16.15 / 15.19 / 14.24）を公開し、28件の脆弱性を一度に修正しました。うち14件がCVSS 8.8で、悪用されるとデータベースを動かしているOSユーザーの権限で任意コードが実行されます。

悪用は現時点で確認されていません（CISA KEVカタログ 2026.08.18版に該当CVEの登録なし、2026年8月19日時点）。ただし多くは「データベースにログインできる利用者」が起点で、業務アプリの接続アカウントやBIツールの参照アカウントも当てはまります。まずは自社のPostgreSQLがどこで動いているかの洗い出しから始めてください。

この記事でわかること

• 28件の内訳（サーバ18件／contribモジュール6件／クライアント4件）と、深刻度の読み方
• 「うちはPostgreSQLを導入していない」が通用しない理由
• 修正版が「18.5」ではなく「18.6」である落とし穴
• 更新しても直らない1件（pgcrypto）と、更新後に追加作業が必要な3ケース
• 影響判定に使えるSQLと確認手順

PostgreSQLとは何者か、どこで動いているのか

PostgreSQLとは、オープンソースのリレーショナルデータベース管理システム（RDBMS）です。業務アプリケーションのデータ保存先として、オンプレミスにもクラウドにも広く使われています。導入するのは多くの場合、開発部門や納入ベンダーであり、情シスの資産台帳に「データベース製品」として明示的に載っていないことがあります。

そして重要なのは、自分で入れた覚えがなくても、製品の内部で動いていることです。一次情報で確認できる例を挙げます。

• GitLab（Linuxパッケージ／Omnibus）：PostgreSQLを同梱しています。公式のバージョン対応表によれば、GitLab 19.3.0が同梱するのは 17.10 と 18.4（新規インストール既定は17.10）で、いずれも今回の修正版（17.11 / 18.6）より前です。
• Veeam Backup & Replication：構成データベースをMicrosoft SQL ServerまたはPostgreSQL上に置く設計で、バックアップサーバのローカルにPostgreSQLが同居する構成が公式ドキュメントに記載されています。「バックアップ機」だと思っている筐体がDBサーバでもある、という状態です。

このほかにも、アプライアンス製品や業務パッケージが内部DBとしてPostgreSQLを抱えていることがあります。推測で製品名を並べても意味がないので、実機で確認する方法を挙げておきます。

• Linux／Windowsとも psql --version、pg_dump --version が通るか
• TCP 5432 でListenしているプロセスがあるか（既定ポート。変更されている場合もある）
• 接続できるなら SELECT version(); または SHOW server_version; で正確なマイナーバージョンを取る

同梱型で見つかった場合、OSのパッケージマネージャで勝手に上げてはいけません。製品のサポート対象外になったり、製品側の管理スクリプトと食い違ったりします。GitLabのように製品ベンダーの更新を待つのが原則です。

何が起きたのか — 28件を一括修正

今回のリリースで修正されたCVEを、開発元の分類（Component）ごとに整理すると次のとおりです。

28件のうち23件はサポート対象の5系統すべて（18/17/16/15/14）に影響します。PostgreSQL 18のみが対象なのは2件（CVE-2026-16238、CVE-2026-14676）です。深刻度の分布は8.8が14件、8.2が1件、8.1が2件、7.2が1件、残り10件が6.5以下でした。

1回のリリースで28件は異例なのか？

異例です。開発元が公開している脆弱性一覧を数えると、2024年は通年で7件、2025年も通年で7件だったのに対し、2026年は8月時点で44件（うち28件が今回）に達しています。内訳を見ると「型混同（type confusion）」「整数ラップアラウンド」「ヒープバッファオーバーフロー」という同種の欠陥が並んでおり、体系的な監査が進んだ結果と読めます。ただし開発元は増加の理由を公表していないため、断定はできません。

実務上の受け止め方としては、「PostgreSQLが急に危険になった」ではなく「これまで見つかっていなかったものが掘り起こされている」と解釈するのが妥当です。裏を返せば、今後のマイナーリリースでも同種の修正が続く可能性が高く、DBのパッチ適用サイクル自体を見直す時期だということになります。

CVSS 8.8が14件。ただし前提は「DBに接続できること」

スコアの高いものを中心に、実務判断に効く8件を挙げます。

では、誰がデータベースにログインできるのか？

これが今回いちばん重要な問いです。多くの脆弱性は「認証済みの利用者」または「オブジェクトを作成できる利用者」が起点なので、影響判定は「うちはPostgreSQLを使っているか」ではなく「誰がDBに接続でき、誰がオブジェクトを作れるか」で切るべきです。棚卸しには次のSQLが使えます。

-- ログイン可能なロールと強い属性の一覧
SELECT rolname, rolsuper, rolcreatedb, rolcreaterole, rolreplication
FROM pg_roles
WHERE rolcanlogin
ORDER BY rolsuper DESC, rolname;

-- 導入済みの拡張（contribモジュール系CVEの該当判定に使う）
SELECT extname, extversion FROM pg_extension ORDER BY 1;

-- publicスキーマの権限（ACLに空グランティの「=UC/」があれば全ユーザーがCREATE可能）
SELECT nspname, nspacl FROM pg_namespace WHERE nspname = 'public';

ここで注意したいのが最後のクエリです。PostgreSQL 15以降は、public スキーマに対するPUBLIC（全ユーザー）のCREATE権限が既定で外れました。しかし公式リリースノートは「クラスタのアップグレードやダンプのリストアでは、publicの既存権限が引き継がれる」と明記しています。つまり「バージョン15以降だから安全」とは言えず、14以前から上げてきた環境や、ダンプから復元した環境は旧来の緩い設定のままである可能性があります。

また、アプリケーション側にSQLインジェクションがある場合、これらの脆弱性と連鎖すると「DB内のデータが読まれる」で止まらず、DBサーバのOSレベルでのコード実行まで届きます。PHPのSQLインジェクション脆弱性やMetabaseのSQLインジェクションのようなアプリ層の穴を、DB側の脆弱性とセットで評価する必要があります。

スコアだけで並べず、前提条件の記述を読む

逆に、CVSSが高くても実際には当たりにくいものもあります。CVE-2026-14662（tsvector/tsquery、8.8）について、開発元は「これらの型は通常アプリケーションのロジックが生成するもので、アプリの利用者が入力する値ではない。したがってアプリを経由して利用者がDBを攻撃することは起こりにくい」と明記しています。

28件を機械的にスコア順に並べて上から潰すのではなく、1件ずつ「誰が、どの立場で成立させられるのか」を読む。それが優先順位づけの実務です。全件を同じ緊急度で扱うと、かえって適用が止まります。

サーバだけ直しても終わらない — クライアント4件

28件のうち4件は、サーバではなくクライアントツール（pg_dump / psql / ECPG）の脆弱性です。攻撃を受けるのは、それを実行している管理者の端末やバッチサーバです。

とくにCVE-2026-18408は経緯が示唆的です。これは2025年8月に修正されたCVE-2025-8714への対策が不十分だったケースで、当時導入された \restrict / \unrestrict というメタコマンドのうち、\unrestrict だけで攻撃が成立してしまいました。同じ「前回修正に不備」の型はpgAdmin 4の事例でも起きています。

現場的な意味に翻訳すると、こうなります。

• 夜間バッチの pg_dump が高権限のOSアカウントで回っているなら、そのバッチサーバが標的になりうる
• 他部門や委託先から受け取ったダンプを psql で自環境に流し込む運用は、ダンプの提供元を信頼していることになる
• クライアントツールはサーバとは別に更新が必要。管理端末に入れたクライアント、Windows用インストーラ、CI/CDやコンテナイメージに焼き込まれた pg_dump も対象

更新しても直らない1件 — pgcryptoの平文化

28件のなかで、パッチ適用だけでは終わらないものが1件あります。CVE-2026-14663（pgcrypto、CVSS 6.5）です。

OpenSSL側の設定やバージョンによって無効化されている暗号方式をpgcryptoが使おうとした場合、暗号化されずに平文が保存され、しかも誤った鍵でも復号が成功してしまうという不具合です。対象は pgp_sym_encrypt、pgp_sym_decrypt、pgp_pub_encrypt、pgp_pub_decrypt と、それぞれの _bytea 版です。改ざん検知（MDC）による保護も失われます。

問題は、パッチはこれから先の書き込みを正すだけで、すでに保存されたデータは平文のまま残るという点です。FIPSモードやディストリビューションの暗号ポリシーで特定の方式を無効化している環境では、「暗号化列」だと思っていたカラムが平文である可能性を疑う必要があります。該当した場合は、更新に加えて保存済みデータの確認と再暗号化、状況によっては情報漏えい相当としての扱いの検討まで踏み込むことになります。

CVSSは6.5と中程度ですが、実務インパクトはスコアより大きくなりうる典型例です。SELECT extname FROM pg_extension WHERE extname = 'pgcrypto'; でまず利用有無を確認してください。

修正版は「18.6」。「18.5」は存在しない

ここは実際に引っかかりやすいので独立して書きます。開発元のセキュリティ情報ページで各CVEを開くと、PostgreSQL 18系の修正版は「18.5」と表示されます。ところが18.5は回帰（regression）のため出荷されていません。リリース告知にも「18.4から18.6までをスキップし、18.5は回帰のため出荷しなかった」と明記されています。18.5を探しても見つからないので、入手すべきは18.6です。

ディストリビューションのパッケージを使っている場合は、上流のバージョン番号ではなくディストリ側の版で判断します。Debianのセキュリティトラッカーによれば、trixieは postgresql-17 17.11-0+deb13u1（DSA-6438-1）、bookwormは postgresql-15 15.19-0+deb12u1（DLA-4740-1）で修正済みです。一方、bullseyeの postgresql-13 は上流のサポートが終了しているため修正されません。

そしてPostgreSQL 14は、今回の更新（14.24）を受けられるものの2026年11月12日でサポート終了です。残り約3か月しかありません。今回のパッチ適用作業と同じタイミングで、15以降への移行計画を立てておくのが現実的です。サポート終了直前の製品更新は、どうしても「最後の1回」で終わりがちですが、その後に脆弱性が出ても打つ手がありません。

更新後に追加作業が必要な3ケース

今回のリリースは通常のマイナー更新（停止→バイナリ更新→起動）で適用でき、ダンプ／リストアや pg_upgrade は不要です。ただし開発元が「更新後に追加の手順が必要になりうる3つの問題」を明示しています。セキュリティ修正ではなくバグ修正側の話ですが、放置すると運用障害になります。

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;

あわせて、PostgreSQL 14・15・16では前回のマイナーリリースで入った回帰により、古いマイナーバージョンが生成したWALのリプレイ中にスタンバイがハングしうる問題も修正されています。レプリケーション構成では、この点も更新理由になります。

現場目線の課題 — 止められないサーバに28件

データベースは「止められない資産」の代表格です。Webサーバなら深夜に数分の再起動が通っても、基幹DBは月次締めや夜間バッチの都合があり、調整だけで数週間かかることも珍しくありません。「28件、うち14件がCVSS 8.8」と言われても、現場が最初にやる作業はどこでPostgreSQLが動いているかの洗い出しで、正直これがいちばん時間を食います。

しかも今回の多くは「ログインできる人」が起点です。つまりパッチ適用と同じくらいDBアカウントの棚卸しが効くのですが、古い業務システムほど、アプリが実質スーパーユーザー相当の1アカウントで接続していて分離できません。「わかっているが直せない」の典型で、更新作業の合間に片付く話でもない。ここは正直、もどかしいところです。

同梱型はさらに厄介です。GitLabのように製品ベンダーの更新を待つしかないケースでは、情シスにできるのは「待っている状態である」ことを記録し、経営層や監査に説明できるようにしておくことだけです。一見なにもしていないように見えますが、後で「認識していたのか」を問われたときに効くのはこの記録です。

情シスはどうすべきか

個別の対策チェックリストを自前で積み上げるより、公的機関の指針を土台にしたほうが確実です。資産管理と更新管理の考え方は、IPAの中小企業の情報セキュリティ対策ガイドラインが整理しています。「何がどこで動いているかを把握する」という原則に戻る話なので、今回のように台帳に載っていない同梱ソフトが問題になる場面ほど効きます。利用部門への周知には、IPAの対策のしおりのような、そのまま配れる資料を使うのが早道です。地道な啓発ですが、「開発部門が入れたDBを情シスが把握していない」という構図は、教育と申請フローでしか埋まりません。

そのうえで、今回に限った実務手順は次の順です。

1. 棚卸し：psql --version／5432番ポート／SELECT version(); で、単体導入分と製品同梱分の両方を洗い出す
2. 該当判定：pg_extension で導入済み拡張を確認し、contribモジュール系6件の要否を絞る
3. アカウント棚卸し：pg_roles と public スキーマのACLで、「誰が接続でき、誰がオブジェクトを作れるか」を出す
4. 更新計画：単体導入分は18.6／17.11／16.15／15.19／14.24（またはディストリの該当版）へ。同梱分はベンダーの更新予定を確認し、待ち状態を記録する
5. クライアント側：管理端末・バッチサーバ・コンテナイメージの pg_dump／psql も更新対象に入れる
6. pgcrypto利用時：保存済みデータが平文になっていないかを確認し、必要なら再暗号化
7. 更新後：GIN／btree_gist／ltreeの3ケースに該当しないか確認する

まとめ

1. 2026年8月13日のPostgreSQL更新で28件の脆弱性が修正された。14件がCVSS 8.8、23件がサポート対象の5系統すべてに影響する。悪用は未確認だが、修正版（18.6 / 17.11 / 16.15 / 15.19 / 14.24）への更新計画を早めに立てるべき。「18.5」は出荷されていないので18.6を取ること。
2. 影響判定は「使っているか」ではなく「誰がDBに接続・オブジェクト作成できるか」で切る。加えて、GitLabなど製品に同梱されたPostgreSQLは資産台帳に載らないため、実機での確認が要る。
3. パッチだけで終わらない部分が2つある。pgcryptoの1件（CVE-2026-14663）は保存済みデータが平文の可能性があり再暗号化が要る。またクライアント側4件は、管理端末やバッチサーバの pg_dump／psql を別途更新しないと残る。

出典

• PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released!（PostgreSQL Global Development Group、2026年8月13日）
• PostgreSQL: Security Information（各CVEの影響系統・CVSS・Component）
• JPCERT/CC Weekly Report 2026-08-19
• PostgreSQL 15 リリースノート（publicスキーマのCREATE権限変更）
• Debian Security Tracker: CVE-2026-14662（DSA-6438-1／DLA-4740-1）
• PostgreSQL versions shipped with the Linux package（GitLab Docs）
• Veeam Backup & Replication Configuration Database（Veeam Help Center）
• CISA Known Exploited Vulnerabilities Catalog