PostgreSQL 16.15セキュリティ更新：任意コード実行を含む28件の脆弱性とDocker本番環境の対応手順

公開日：2026年8月15日
最終確認日：2026年8月15日

2026年8月13日、PostgreSQL Global Development Groupは、PostgreSQL 18.6、17.11、16.15、15.19、14.24を公開しました。

今回のマイナーアップデートでは、28件のセキュリティ脆弱性と110件を超える不具合が修正されています。

28件の中には、PostgreSQLを実行しているOSユーザー権限で任意コードを実行できる脆弱性が複数含まれています。

この記事では、PostgreSQL 16.14を使用していたDocker本番環境を例に、

何が起きたのか
自分のPostgreSQLが影響を受けるのか
なぜ任意コード実行につながるのか
Docker環境で何を確認するのか
PostgreSQL 16.15へどう更新するのか
更新後に何を確認するのか
WAF・IPS・EDRで何を補助できるのか

まで、実際の運用手順を含めて解説します。

結論・この記事の要点

PostgreSQL 16.14以前は今回修正された複数の脆弱性の影響を受ける。
PostgreSQL 16系の今回の修正版は16.15である。
28件中18件がCVSS 7.0以上で、CVSS 8.8の脆弱性が複数存在する。
CVE-2026-14680では低権限DBユーザーからPostgreSQL実行OSユーザー権限の任意コード実行につながる。
サーバーだけでなくpsql、pg_dumpなどクライアント側にもコード実行脆弱性がある。
PostgreSQL 16.14から16.15への更新では通常pg_upgradeやdump/restoreは不要である。
Dockerではpostgres:16-alpineだけではなく、修正版タグとレビュー済みdigestを固定する方が再現性が高い。
更新後はGIN、btree_gist、ltreeなどについて追加確認が必要になる場合がある。
WAF・IPS・EDRは補助対策であり、PostgreSQL本体の更新の代替にはならない。

PostgreSQL公式は16.15について、16.Xからの更新ではdump/restoreは不要としています。ただし、個別の設定変更やインデックス確認が必要になるケースがあります。

この記事で分かること

この記事を読むと、次の内容を理解できます。

PostgreSQL 2026年8月セキュリティ更新の概要
任意コード実行がどのように成立するのか
PostgreSQL 16.14が影響を受ける理由
Docker環境のバージョン確認方法
postgres:16-alpineの注意点
PostgreSQL 16.15への更新方法
psql、pg_dump、pg_restoreを確認する理由
更新後のDjango動作確認
GIN・btree_gist・ltreeの追加確認
WAF・IPS・EDRによる補助対策
同じ問題を繰り返さないためのバージョン管理方法

対象読者・前提環境

この記事は、次のような環境を運用している人を対象としています。

PostgreSQL 14～18を利用している
Docker / Docker ComposeでPostgreSQLを動かしている
DjangoなどのWebアプリケーションからPostgreSQLを利用している
本番データベースを安全にマイナーアップデートしたい
PostgreSQLのセキュリティ情報を確認したい

今回の実環境では、更新調査開始時点で次の状態でした。

項目	状態
PostgreSQL	16.14
コンテナ	Docker
ベース	Alpine
元イメージ指定	`postgres:16-alpine`
server	16.14
`psql`	16.14
`pg_dump`	16.14
コンテナ状態	healthy
アプリケーション	Django

公開記事では、内部のコンテナ名、DB名、ロール名などは一般化して記載します。

何が起きたのか

2026年8月13日、PostgreSQL Projectは全サポート対象メジャーバージョン向けのマイナーアップデートを公開しました。

PostgreSQL	公開された修正版
18	18.6
17	17.11
16	16.15
15	15.19
14	14.24

この更新では28件のセキュリティ脆弱性と110件を超える不具合が修正されています。

PostgreSQL 18だけ少し特殊です。

各CVEページでは18系の修正版が18.5と記載されていますが、PostgreSQL Projectは18.5をリグレッションのため出荷せず、18.6を公開しました。

したがって実際に導入する公開版は18.6です。

28件の脆弱性

PostgreSQL公式発表に掲載された28件を整理すると次のようになります。

CVE	CVSS	主な問題
CVE-2026-6464	8.1	`psql COPY FROM STDIN`のSQLインジェクション
CVE-2026-6469	3.8	Extended Statisticsの所有権問題
CVE-2026-6470	4.3	Type USAGE権限チェック不足
CVE-2026-6471	7.2	Logical Decodingから任意ファイルを`dlopen`
CVE-2026-14662	8.8	`tsvector` / `tsquery`の整数wraparound
CVE-2026-14663	6.5	`pgcrypto`で暗号化されない可能性
CVE-2026-14664	8.8	regexp Heap Buffer Overflowによるコード実行
CVE-2026-14666	4.2	Row Level Securityのキャッシュ問題
CVE-2026-14668	8.1	`ctid` Type Confusionによる情報漏えい
CVE-2026-14669	8.8	`to_char()` Heap Buffer Overflow
CVE-2026-14670	8.8	PL/Perl Heap Buffer Overflow
CVE-2026-14671	8.8	`refint` Type Confusion
CVE-2026-14672	5.3	SCRAM応答差によるユーザー存在判定
CVE-2026-14673	3.8	`amcheck`のsearch_path問題
CVE-2026-14676	8.8	`pg_stat_statements` Heap Buffer Overflow
CVE-2026-14677	8.8	32bit PL/Tcl・PL/Perl整数wraparound
CVE-2026-14678	4.3	`pg_trgm` OOB Read
CVE-2026-14679	8.2	Stack Buffer Overflow
CVE-2026-14680	8.8	`internal`型Type Confusion
CVE-2026-14681	4.2	GSSAPI暗号化の適用不備
CVE-2026-15741	8.8	Expression deparse SQL Injection
CVE-2026-15742	8.8	`fuzzystrmatch`の危険なメモリ書き込み
CVE-2026-16238	8.8	`pg_restore_attribute_stats()` Type Confusion
CVE-2026-16239	8.8	Cursor lifecycle Type Confusion
CVE-2026-16241	3.8	ECPG Integer Underflow
CVE-2026-18024	4.3	`ascii()` OOB Read
CVE-2026-18408	8.8	`psql \unrestrict`を利用したコード実行
CVE-2026-19385	8.8	`pg_dump` Heap Buffer Overflow

CVSS 3.xの一般的な区分で整理すると、

High：18件
Medium：7件
Low：3件

となります。

Criticalに分類される9.0以上のCVEはありません。

しかし、CVSS 8.8の任意コード実行が多数含まれているため、「Criticalがないから急がなくてもよい」という判断は適切ではありません。

特に重要なCVE-2026-14680とは

今回特に注意したいのがCVE-2026-14680です。

CVSSは8.8です。

PostgreSQLのinternal型を処理する際のType Confusionにより、低権限のDBユーザーから、PostgreSQLを動かしているOSユーザーとして任意コードを実行できる可能性があります。

Type Confusionとは

簡単に例えると、

「荷物の箱に書かれた種類を取り違え、本来とは違う扱い方をしてしまう」

ような問題です。

正式には、プログラムがあるデータを本来とは異なる型として扱うことで、誤ったメモリアクセスなどが発生する問題です。

今回の場合、

DBユーザー
   ↓
細工した関数呼び出し
   ↓
internal型の扱いを混乱させる
   ↓
Type Confusion
   ↓
PostgreSQLプロセスのメモリ処理を破壊
   ↓
postgres OSユーザー権限でコード実行

という危険があります。

公式CVSS Vectorは、

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

です。

重要なのはPR:Lです。

つまり一般的には、攻撃者には何らかの低権限DBアクセスが必要です。

ただしWebアプリケーション側に、

SQL Injection ─────────┐
                       │
DB資格情報の漏えい ───┼→ DBでSQL実行・接続
                       │        ↓
内部侵害 ─────────────┘  PostgreSQL脆弱性
                                ↓
                     OSユーザー権限でコード実行

という連鎖が発生すると、被害範囲が大きくなります。

これは代表的な攻撃チェーンの一例であり、すべてのCVEがこの経路で悪用できるという意味ではありません。

regexpでもOSコード実行につながる

CVE-2026-14664はPostgreSQL本体のregexp処理に存在するHeap Buffer Overflowです。

不正なエンコーディングデータを利用することで、クエリ作成者がPostgreSQLを実行するOSユーザーとして任意コードを実行できるとされています。

CVSSは8.8です。

細工した文字列
    ↓
regexp処理
    ↓
Heap Buffer Overflow
    ↓
メモリ破壊
    ↓
任意コード実行

Cursor操作でも任意コード実行

CVE-2026-16239は、PostgreSQLのPortal / Cursor lifecycleに存在するType Confusionです。

異なる型を使ってCursorやPortalを再生成することによって、PostgreSQL OSユーザーとしてコードを実行できる可能性があります。

CVSSは8.8です。

Logical Decodingを使用している環境も注意

CVE-2026-6471では、REPLICATION権限を持つ非superuserがLogical Decoding Pluginを選択することで、PostgreSQL実行OSユーザーから参照できる任意ファイルをdlopen()できる問題がありました。

結果としてPostgreSQL OSユーザーとしてコード実行につながります。

16.15では新しい、

output_plugin_libraries

設定が追加され、利用可能なLogical Decoding Pluginを制限できるようになりました。

デフォルトではPostgreSQL同梱の、

pgoutput
test_decoding

が許可されます。

独自Logical Decoding Pluginを利用している環境では、16.15への更新後に設定変更が必要になる可能性があります。

サーバーだけではなくpg_dumpも危険

今回の重要ポイントです。

PostgreSQLサーバーの更新だけ確認して終わってはいけません。

CVE-2026-19385はpg_dumpに存在するHeap Buffer Overflowです。

細工されたfunction transform listによって、pg_dumpを実行しているOSユーザーとして任意コードを実行できる可能性があります。

CVSSは8.8です。

psqlにも任意コード実行問題がある

CVE-2026-18408は、psqlの\unrestrictに関連する問題です。

悪意あるdump元サーバーのsuperuserがdumpデータへ細工を行うことで、復元時にpsqlを実行するクライアントOSユーザーとして任意コードを実行できる可能性があります。

pg_dumpallも影響します。

pg_restoreを使用してplain-format dumpを生成するケースも影響対象です。

したがって、

postgres server
       +
psql
       +
pg_dump
       +
pg_restore

をセットで確認する必要があります。

悪用状況について

2026年8月15日時点で、PostgreSQL Projectの今回のセキュリティ告知には、これら28件について実際の攻撃キャンペーンで悪用されているという記載は確認できません。

したがって、

「すでにインターネット上で大規模悪用されている」

と断定することはできません。

一方、16.15のリリースノートではCVE-2026-14669について、任意コード実行につながるexploitが報告された旨が記載されています。

「コード実行可能性が実証・報告されていること」と「攻撃者による実悪用が観測されていること」は別です。

この記事では悪用状況を**確認できないものは「確認できない」**として扱います。

今回の環境は影響を受けるのか

更新前の実測値はPostgreSQL 16.14でした。

CVE-2026-14680をはじめ、今回の主要CVEでは、

PostgreSQL 16.15より前

が影響対象です。

したがって、

16.14

は修正前です。

16.15へ更新する必要があります。

当初16.14へ固定した理由

実際の初動では、

image: postgres:16-alpine

で稼働していました。

ここには運用上の問題があります。

16-alpineは特定のpatch releaseそのものを表す固定値ではありません。

再pullや再作成のタイミングによって、そのタグが指すイメージが変化する可能性があります。

そのため、初動では実際に確認できた16.14へ、

image: postgres:16.14-alpine

と固定しました。

同時に、

MIN_DOCKER_IMAGE_VERSIONS["postgres"]

についても16.14未満を失敗させるよう変更しました。

この判断には意味がありました。

確認できていないCVEや存在を確認していないイメージタグを根拠に、本番環境を更新したと扱わなかったためです。

ただし、これはあくまでその時点の暫定措置です。

2026年8月15日に再確認したところ、PostgreSQL公式から16.15が公開されていることを確認できました。

さらにDocker Official Imagesのsource of truthにも、

16.15-alpine
16-alpine
16.15-alpine3.24

が登録されています。

したがって現在の下限は、

16.15

へ改定する必要があります。

Dockerではタグだけでなくdigestも固定する

Dockerタグは変更可能です。

一方、digestは特定のイメージ内容を指す不変識別子です。

Dockerも再現性やSupply Chain Integrityを高める方法としてdigest pinningを案内しています。

本番環境では、

image: postgres:16.15-alpine@sha256:<reviewed-digest>

のように、

バージョンタグ
+
digest

の両方を使用すると、レビューしたイメージと実際に起動するイメージを一致させやすくなります。

<reviewed-digest>をそのまま使用してはいけません。

必ず実際に利用するDocker Official Imageのdigestを確認してください。

更新前の確認方法

以下は公開用にコンテナ名、DB名、ユーザー名を一般化しています。

1. 実際に動いているDocker Imageを確認する

目的

Composeファイルの設定値ではなく、現在実際に動いているコンテナを確認します。

実行場所

Dockerホスト。

コマンド

docker inspect <postgres-container> \
  --format '{{.Config.Image}} {{.Image}}'

正常例

postgres:16.14-alpine sha256:...

異常例

postgres:16-alpine sha256:...

設定したつもりの固定タグと異なる場合も異常として扱います。

判断方法

レビュー済みのタグ・Image IDと一致しているか確認します。

server・psql・pg_dump・pg_restoreを確認する

目的

サーバーだけでなくクライアントツールも修正版か確認します。

実行場所

PostgreSQLコンテナを実行しているDockerホスト。

コマンド

docker exec <postgres-container> postgres --version
docker exec <postgres-container> psql --version
docker exec <postgres-container> pg_dump --version
docker exec <postgres-container> pg_restore --version

16.15更新後の正常例

postgres (PostgreSQL) 16.15
psql (PostgreSQL) 16.15
pg_dump (PostgreSQL) 16.15
pg_restore (PostgreSQL) 16.15

異常例

postgres (PostgreSQL) 16.14

またはserverは16.15でも、

pg_dump (PostgreSQL) 16.14

のようにクライアントツールだけ古い場合です。

判断方法

今回のPostgreSQL 16系では、

16.15以上

を合格条件にします。

PostgreSQL自身へ問い合わせる

目的

実際に起動しているPostgreSQL serverのバージョンをSQLから確認します。

実行場所

Dockerホスト。

コマンド

docker exec <postgres-container> \
  psql -U <db-user> -d <db-name> \
  -c 'SHOW server_version;'

正常例

 server_version
----------------
 16.15

異常例

16.14

または接続エラーです。

判断方法

postgres --versionとSHOW server_versionの結果がともに16.15以上であることを確認します。

拡張機能を確認する

目的

今回の更新では複数のcontrib moduleも影響を受けています。

利用中の拡張機能を事前に把握します。

コマンド

docker exec <postgres-container> \
  psql -U <db-user> -d <db-name> \
  -c 'SELECT extname, extversion FROM pg_extension ORDER BY extname;'

特に確認したいのは、

pg_stat_statements
pgcrypto
pg_trgm
fuzzystrmatch
btree_gist
ltree
amcheck
refint
plperl
pltcl

などです。

利用していない拡張のCVEまで、必ずしも同じ条件で攻撃可能という意味ではありません。

コンテナのHealthを確認する

目的

PostgreSQLプロセスが起動しただけではなく、Docker Healthcheckも成功しているか確認します。

コマンド

docker ps \
  --filter name=<postgres-container> \
  --format '{{.Names}} {{.Status}}'

正常例

postgres-container Up ... (healthy)

異常例

unhealthy

または再起動を繰り返している状態です。

判断方法

healthyだけでセキュリティ更新完了とは判断しません。

バージョン・SQL接続・アプリケーション動作確認も必要です。

バックアップを確認する

更新前には、既存バックアップ監視が正常であることを確認します。

重要なのは、

バックアップが存在する

だけではありません。

取得できている
        ↓
保存できている
        ↓
復元できる

まで確認する必要があります。

また、今回pg_dump自体にもCVE-2026-19385があります。

そのため「アップデート前だから、とりあえず古いpg_dumpを使って何でもバックアップする」という運用も、接続先DBを信用できない場合には注意が必要です。

PostgreSQL公式ドキュメントでは、新しいpg_dumpから同じメジャーの古いPostgreSQL serverをdumpできます。

バックアップ方式は組織の既存手順を優先してください。

資格情報を、

Shell history
CI log
作業メモ
チャット

などへ直接残さないことも重要です。

PostgreSQL 16.15への更新手順

手順1：公式情報を確認する

最初にPostgreSQL ProjectのSecurity AnnouncementとRelease Notesを確認します。

今回の16系修正版は、

16.15

です。

手順2：Docker Official Imageを確認する

Docker Official Imagesのsource of truthでは、現在、

16.15-alpine

が登録されています。

まず対象イメージを取得します。

docker pull postgres:16.15-alpine

目的

利用予定のイメージが実際に取得可能であることを確認します。

実行場所

Dockerホスト。

正常

pullが成功する。

異常

manifest unknown

などが出る。

判断方法

未確認のタグをComposeへ先に書かず、取得可能性を確認してからデプロイ対象にします。

手順3：digestを確認する

docker image inspect postgres:16.15-alpine \
  --format '{{json .RepoDigests}}'

目的

実際にpullしたDocker Imageのdigestを取得します。

正常例

["postgres@sha256:..."]

異常例

[]

または対象イメージが存在しない。

判断方法

取得したdigestをレビュー・運用記録と照合します。

この記事では本番環境の実digest値は掲載しません。

手順4：Composeを16.15へ変更する

概念的には、

services:
  postgres:
    image: postgres:16.15-alpine@sha256:<reviewed-digest>

とします。

さらに、デプロイ前検査の最低バージョンも、

MIN_DOCKER_IMAGE_VERSIONS["postgres"] = "16.15"

へ変更します。

タグだけ16.15にして、

predeploy_check = 16.14

のままにすると、将来16.14へ戻っても検査を通過する可能性があります。

宣言値と検査値は同時に変更します。

手順5：デプロイ前検査を実行する

今回の環境では、

python scripts/predeploy_check.py --fast

を実行します。

目的

本番デプロイ前に、最低バージョンなどのルール違反を検出します。

実行場所

プロジェクトルート。

正常

終了コード0。

PostgreSQLの最低バージョンチェックも成功する。

異常

16.15未満として失敗する、または設定不整合が検出される。

判断方法

本番へ反映する前に必ず成功させます。

関連するユニットテストも同時に実施します。

手順6：通常のComposeデプロイ手順で反映する

PostgreSQL 16.14から16.15は同一メジャー内のマイナーアップデートです。

PostgreSQL Projectはマイナーアップデートについて、通常はdump/restoreやpg_upgradeを必要とせず、サーバー停止・バイナリ更新・再起動で更新できるとしています。

Docker環境では新しいイメージからコンテナを再作成します。

PostgreSQLの永続データVolumeを削除してはいけません。

特に、

docker compose down -v

のようにVolumeを削除する操作を安易に実行しないでください。

-vは永続データを削除する可能性があります。

通常の組織・プロジェクトのデプロイ手順を使用してください。

更新後の確認

更新後は再び、

docker exec <postgres-container> postgres --version
docker exec <postgres-container> psql --version
docker exec <postgres-container> pg_dump --version
docker exec <postgres-container> pg_restore --version

を確認します。

さらに、

SHOW server_version;

を確認します。

すべて、

16.15

以上であることを確認します。

Djangoの確認

PostgreSQLだけ正常でも、Djangoから接続できなければ更新成功とは言えません。

Django Deployment Check

python manage.py check --deploy

目的

Djangoの本番向け設定に重大な問題がないか確認します。

実行場所

Djangoアプリケーションの実行環境。

正常

重大なERRORがない。

異常

DB設定やSecurity設定などのERROR。

判断方法

PostgreSQL更新による接続・設定問題が発生していないことを確認します。

Migration確認

python manage.py migrate --check

目的

未適用Migrationが残っていないか確認します。

正常

終了コード0。

異常

未適用Migrationが存在する。

判断方法

DB更新とアプリケーションschema状態を分けて確認します。

このコマンド自体はMigrationを適用しません。

アプリケーションの実動作確認

最後に本番サイトの代表的なルートを確認します。

Browser / HTTP
        ↓
Reverse Proxy
        ↓
Django
        ↓
PostgreSQL

の経路全体が正常であることを確認します。

最低でも、

HTTP成功
ログインなどDB参照処理
DB更新処理
直近ログにconnection errorがない
Migration errorがない
PostgreSQL containerがhealthy

を確認します。

GIN Indexを確認する

今回のリリースではParallel GIN Index Buildの不具合も修正されています。

不具合によってpg_class.reltuplesが、

Infinity
NaN

などの不正値になると、autovacuum / autoanalyzeが対象テーブルを処理できなくなる可能性があります。

PostgreSQL公式が案内する確認SQLは次です。

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;

目的

GIN Indexを持つテーブルのreltuplesを確認します。

実行場所

対象PostgreSQL database。

正常

現実的な行数に近い値。

異常

Infinity
NaN

など。

対処

公式案内では、不正な値が確認された場合、

ANALYZE <table>;

などで値を修正します。

本番でANALYZEを実行するときは、対象テーブルと負荷を確認してから実行してください。

btree_gistを使用している場合

16.15ではbtree_gistにも修正があります。

特に、

float4
float8
bit
bit varying

を利用したIndexでは再構築が必要になる場合があります。

公式例は、

REINDEX INDEX your_index_name;

です。

REINDEXはI/OやLockへ影響する可能性があります。

本番環境では対象Index、サイズ、Lock、メンテナンス時間を確認してから実行してください。

ltreeを使用している場合

ltreeでは、約14,653を超える非常に多数のlabelを持つ値の比較にInteger Overflowが存在しました。

該当するB-tree Indexは破損している可能性があるため、必要に応じてREINDEXします。

pgcryptoを使用している場合は特に注意

CVE-2026-14663では、OpenSSLが要求された暗号方式を拒否した場合に、pgcryptoが失敗を検出できず、事実上暗号化されていないデータを暗号化済みのように扱う可能性がありました。

対象となり得る古いCipherを利用していた場合は、

アップデート
        ↓
影響データ特定
        ↓
復号・状態確認
        ↓
安全なCipherで再暗号化

というデータクリーンアップまで検討する必要があります。

16.15へ更新しただけで、過去に誤って暗号化されたデータまで自動的に安全になるわけではありません。

暫定対策

すぐに16.15へ更新できない環境では、更新までの間に攻撃成立条件を減らします。

ただし、以下はアップデートの代替ではありません。

PostgreSQLをインターネットへ直接公開しない
DB接続元を必要なホスト・ネットワークへ限定する
不要なDBユーザーを停止する
REPLICATION権限を必要最小限にする
不要なCREATE権限を削減する
不要なPostgreSQL extensionを有効化しない
信頼できないPostgreSQL serverに古いpg_dumpを接続しない
出所不明のdumpを古いpsqlでrestoreしない
PostgreSQL containerからの不要な外向き通信を制限する
SQL Injection対策を再確認する

権限の削除はReplicationやアプリケーション機能を停止させる可能性があります。

本番では依存関係を確認してから変更してください。

WAFで防げるのか

WAFはPostgreSQLのメモリ破壊そのものを修正できません。

PostgreSQLが通常、

Internet
   ↓
WAF
   ↓
Web Application
   ↓
PostgreSQL

という構成であれば、WAFはSQL Injectionなど最初の侵入経路を減らす補助防御として利用できます。

ただし、

盗まれたDB資格情報
内部侵害
直接DB接続
悪意あるDBユーザー
悪意あるdump

などは、Web WAFだけでは防げません。

WAFがあるからPostgreSQLを更新しなくてもよい、という判断はできません。

IPS・NDRによる補助対策

IPS/NDRでは、

PostgreSQLへの想定外接続
不審なReplication接続
通常存在しない接続元
異常な接続頻度
PostgreSQLからの不審な外向き通信

などを監視できます。

一方、PostgreSQL通信がTLSで暗号化されている場合、ネットワーク上からSQL本文を詳細に検査できないことがあります。

Unix Socket経由の通信もネットワークIPSからは直接見えません。

したがって、

WAF
+
IPS/NDR
+
Host/Container Runtime Monitoring

を組み合わせる必要があります。

EDR・Container Runtime監視

任意コード実行が成功した場合、

postgres process
        ↓
不審なnetwork connection
        ↓
不審なfile write
        ↓
shell / downloader等

が発生する可能性があります。

EDRやRuntime Securityでは、

PostgreSQLから通常発生しない子プロセス
PostgreSQL containerからの異常な外部通信
不審な実行ファイル生成
通常書き込まないディレクトリへの書き込み
コンテナ内の異常なprocess tree
権限変更
Container Escapeにつながる挙動

などを監視すると防御層を増やせます。

ただしコード実行がPostgreSQLプロセス内部だけで完結する場合もあるため、EDRだけで必ず検出できるわけではありません。

再発防止

今回の対応で最も重要なのは、単に16.15へ更新することではありません。

古いpatch versionが将来再び本番へ戻らない仕組みを作ることです。

今回採用した、

Docker Image Version Pin
        +
Digest Pin
        +
Predeploy Minimum Version Check

は有効です。

構成すると、

PostgreSQL Security Release
        ↓
公式情報を確認
        ↓
Docker Official Image確認
        ↓
Tag + Digestレビュー
        ↓
MIN_VERSION更新
        ↓
CI / predeploy check
        ↓
Deploy
        ↓
Runtime Version確認
        ↓
Application Test

という流れになります。

自動検査で16.14へのロールバックを止める

たとえばCI/CDで、

PostgreSQL >= 16.15

を強制します。

これによって、

image: postgres:16.14-alpine

へ誤って戻した場合でも、本番デプロイ前に検出できます。

今後新しいセキュリティアップデートが公開された場合は、

16.15
 ↓
16.xx

と最低バージョンを更新します。

今回の実施内容をレビューして改善したい4点

今回の初動には良い部分がある一方、そのまま最終状態にしてはいけない点もあります。

1. 16.14固定は現在では不十分

16.14へ固定したことで16-alpineの可変性は排除できました。

しかし、現在公式に16.15が公開されているため、16.14固定を「セキュリティ対応完了」とすることはできません。

16.15へ更新する必要があります。

2. バージョンタグだけでは完全な再現性がない

postgres:16.15-alpine

まで固定しても、タグ自体は理論上更新可能です。

本番で厳密な再現性を求めるならdigestまで固定した方が安全です。

3. `healthy`だけでは更新成功を証明できない

Dockerが、

healthy

でも、

server = 16.15
pg_dump = 16.14

という状態ならクライアント脆弱性が残る可能性があります。

server、psql、pg_dump、pg_restoreを別々に確認する必要があります。

4. 本番内部識別子を公開記事へそのまま載せる必要はない

コンテナ名、DB名、DBロール名は単独では秘密情報ではありません。

それでも技術記事の目的に不要なら、

<postgres-container>
<db-name>
<db-user>

のように一般化した方がよいでしょう。

実際の値は内部Runbookや運用記録へ残せば十分です。

更新後チェックリスト

PostgreSQL公式で対象メジャーの修正版を確認した
Docker Official Imageの対象タグを確認した
postgres:16.15-alpine以上を使用している
レビュー済みdigestを固定した
postgres --versionが16.15以上
SHOW server_versionが16.15以上
psql --versionが16.15以上
pg_dump --versionが16.15以上
pg_restore --versionが16.15以上
PostgreSQL containerがhealthy
SQL接続が成功する
python manage.py check --deployが成功する
python manage.py migrate --checkが成功する
本番アプリケーションの代表ルートが正常
DB接続エラーがログへ出ていない
使用中extensionを確認した
Logical Decodingを使用する場合output_plugin_librariesを確認した
pgcrypto利用環境では影響データを確認した
GIN Indexのreltuplesを確認した
btree_gistのREINDEX要否を確認した
ltreeのREINDEX要否を確認した
Replication環境ではReplication状態を確認した
Backup監視が正常
Restore Testの結果を記録した
predeploy最低バージョンを16.15以上へ変更した

よくある誤解

PostgreSQLをインターネット公開していないから関係ない？

関係ないとは言えません。

今回のCVEにはDBユーザー権限を前提とするものがあります。

SQL Injection、Credential Leak、内部侵害などからDBアクセスを取得された後、さらにOSコード実行へ進む攻撃チェーンが考えられます。

CVSS Criticalがないなら急がなくていい？

推奨できません。

CVSS 8.8でOSコード実行可能な脆弱性が複数存在します。

環境ごとの攻撃成立条件を確認しつつ、サポート対象の修正版へ更新するべきです。

Dockerならコンテナを再起動すれば更新される？

いいえ。

ローカルに古いイメージが残っている場合やpull policyによっては、期待したイメージにならない可能性があります。

実際に動いているイメージとPostgreSQLのバージョンを確認してください。

`postgres:16-alpine`なら常に最新16系？

タグが現在何を指しているかと、本番で実際にどのImage IDを動かしているかは別問題です。

必ずRuntimeを確認します。

16.14から16.15へ上げるためにpg_upgradeが必要？

通常は不要です。

PostgreSQL Projectは同一メジャー内のマイナー更新について、dump/restoreやpg_upgradeを要求していません。

ただしRelease Notesに記載された個別対応は必要です。

まとめ

2026年8月13日のPostgreSQLセキュリティアップデートでは、28件の脆弱性が修正されました。

PostgreSQL 16系の修正版は、

16.15

です。

今回特に重要なのは、単なるDoSや情報漏えいだけではなく、

DBユーザー
   ↓
PostgreSQL脆弱性
   ↓
メモリ破壊
   ↓
PostgreSQL OSユーザーとしてコード実行

につながる脆弱性が複数含まれている点です。

さらに、

psql
pg_dump
pg_restore

などクライアント側も確認する必要があります。

Docker本番環境では、

16-alpine

のような可変タグだけに依存せず、

修正版Tag
+
Digest
+
最低バージョン検査
+
Runtime確認

まで組み合わせると、更新漏れや意図しないロールバックを防ぎやすくなります。

そして最後に重要なのは、

アップデートした

ではなく、

修正版が動いていることを確認した

までをセキュリティ更新として扱うことです。

FAQ

Q. PostgreSQL 16.14は今回の脆弱性に対して安全ですか？

いいえ。

今回の主要CVEでは16.15より前の16系が影響対象です。16.14は修正前です。

Q. PostgreSQL 16系の修正版は？

16.15です。

Q. `postgres:16.15-alpine`は存在しますか？

2026年8月15日時点でDocker Official Imagesのsource of truthに登録されていることを確認できます。

Q. 16.14から16.15でdump/restoreは必要ですか？

通常不要です。

ただしGIN、btree_gist、ltreeなどについて追加確認が必要になる場合があります。

Q. WAFを導入していれば更新しなくても安全ですか？

いいえ。

WAFはWeb経由の攻撃を減らす補助防御です。

PostgreSQL内部のメモリ安全性問題そのものは修正できません。

Q. CVE-2026-14680は認証不要RCEですか？

公式CVSS VectorはPR:Lです。

したがって一般的には低権限DBユーザー相当の権限が必要です。

Q. `pg_dump`も更新する必要がありますか？

はい。

CVE-2026-19385はpg_dumpを対象とした任意コード実行脆弱性です。

参考情報

PostgreSQL 18.6 / 17.11 / 16.15 / 15.19 / 14.24 Release Announcement

https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/

PostgreSQL 16.15 Release Notes

https://www.postgresql.org/docs/release/16.15/

PostgreSQL CVE-2026-14680

https://www.postgresql.org/support/security/CVE-2026-14680/

PostgreSQL CVE-2026-14664

https://www.postgresql.org/support/security/CVE-2026-14664/

PostgreSQL CVE-2026-16239

https://www.postgresql.org/support/security/CVE-2026-16239/

PostgreSQL CVE-2026-6471

https://www.postgresql.org/support/security/CVE-2026-6471/

PostgreSQL CVE-2026-18408

https://www.postgresql.org/support/security/CVE-2026-18408/

PostgreSQL CVE-2026-19385

https://www.postgresql.org/support/security/CVE-2026-19385/

PostgreSQL Versioning Policy

https://www.postgresql.org/support/versioning/

PostgreSQL pg_dump Documentation

https://www.postgresql.org/docs/16/app-pgdump.html

Docker Official Images PostgreSQL source of truth

https://raw.githubusercontent.com/docker-library/official-images/master/library/postgres

Docker Official PostgreSQL Image repository

https://github.com/docker-library/postgres

Docker Build Best Practices

https://docs.docker.com/build/building/best-practices/