この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
PostgreSQL 18.4 / 17.10 / 16.14 / 15.18 / 14.23の5系列同時セキュリティリリースが2026年5月14日に公開され、JPCERT/CCも5月20日の週次レポートで取り上げました。同梱CVEは11件、うちCVSS 8.8の高危険度が4件含まれ、libpqクライアントのスタックを上書きできるCVE-2026-6477やrefintモジュールのスタックバッファオーバーフロー CVE-2026-6637など、攻撃成立時のインパクトが大きい構造です。本記事ではLinuxサーバー管理者向けに、CVE群の整理、ディストリ別パッケージ提供タイミング、pg_upgrade不要のマイナー更新手順、systemdでのローリング再起動、PgBouncer/Patroni併用での接続停止最小化を実務目線でまとめます。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
2026年5月のPostgreSQLセキュリティリリースで何が直ったか
PostgreSQL公式アナウンスに掲載されているCVEは11件。攻撃成立時のインパクトが大きい4件（CVSS 8.8）を先に押さえます。
CVSS 8.8の4件
- CVE-2026-6473: サーバー機能の整数オーバーフローによる範囲外書き込みとセグメンテーション違反。攻撃者は低権限で実行可能、ユーザー操作不要。影響範囲はPostgreSQL 14-18全系列。
- CVE-2026-6475: pg_basebackup と pg_rewind がシンボリックリンクを追従し、関連のないファイル（例: /var/lib/postgres/.bashrc）を上書き可能。シンボリックリンク経由でOSアカウントハイジャックに発展。
- CVE-2026-6477: libpq の lo_export() / lo_read() / lo_lseek64() / lo_tell64() が危険な PQfn(..., result_is_int=0, ...) を使用しており、スーパーユーザーが任意長レスポンスでクライアントスタックバッファを上書き可能。psql の \lo_export と pg_dump が lo_read() を呼ぶため、psql・pg_dump 経由でスタックメモリを書き換えられます。
- CVE-2026-6637: refint モジュールのスタックバッファオーバーフロー。非特権ユーザーがDBMSを実行するOSユーザー権限で任意コード実行可能。さらに refint カスケード主キー列をユーザーが更新できる設計だと、SQLインジェクションも別経路で発動。
libpq側に効くCVE-2026-6477が運用上厄介です。「サーバー側だけパッチを当てれば良い」と判断しがちですが、pg_dump や psql といったクライアントツール側のバイナリも同じpostgresqlパッケージ群から来ているため、踏み台になるバックアップサーバー・管理用ジャンプホスト・運用端末すべてが対象です。
その他のCVE抜粋
| CVE | CVSS | 影響範囲 | 概要 |
|---|---|---|---|
| CVE-2026-6472 | 5.4 | 14-18 | CREATE TYPEがmultirangeスキーマのCREATE権限を未チェック、search_path経由クエリハイジャック |
| CVE-2026-6474 | 4.3 | 14-18 | timeofday()のフォーマット文字列脆弱性、細工タイムゾーンでサーバーメモリ漏洩 |
| CVE-2026-6476 | 7.2 | 17-18のみ | pg_createsubscriberのサブスクリプション名SQLインジェクション |
| CVE-2026-6478 | 6.5 | 14-18 | MD5パスワード比較のタイミングチャネル（scram-sha-256は対象外） |
| CVE-2026-6479 | 7.5 | 14-18 | SSL/GSS初期化の無制限再帰によるDoS |
| CVE-2026-6575 | 4.3 | 18のみ | pg_restore_attribute_stats()が配列末尾を超えて読み取り |
| CVE-2026-6638 | 3.7 | 16-18 | ALTER SUBSCRIPTION ... REFRESH PUBLICATIONのSQLインジェクション |
影響範囲列の読み方は「14-18」なら14系・15系・16系・17系・18系すべてに影響、「17-18のみ」なら17系と18系だけということです。PostgreSQL 14は2026年11月12日でサポート終了予定のため、いま14系で運用しているなら今回のパッチ適用と並行して15以降への移行計画も走らせる必要があります。
ディストリ別パッケージ提供タイミングの読み方
PostgreSQL本体のリリース日と、自分の使っているLinuxディストリビューションでyum/apt経由で取れるようになるタイミングは別です。「PGDGリポジトリを使っているか」「OS標準リポジトリだけを使っているか」で大きく分かれます。
提供経路別の反映時間目安
| ディストリ | 経路 | 反映時間の目安 | 備考 |
|---|---|---|---|
| Ubuntu 24.04 / 26.04 | PGDG APT (apt.postgresql.org) | 公式リリースから24-72時間 | postgresql-{14,15,16,17,18}パッケージごとに更新 |
| Debian 12 / 13 | PGDG APT | Ubuntuと同タイミング | 同一リポジトリから提供 |
| RHEL 9 / 10 | PGDG RPM | 公式リリースから24-72時間 | RHELマイナー版ごとに別ビルド、OpenSSL互換性対応 |
| Rocky / AlmaLinux 9 / 10 | PGDG RPM | RHELと同タイミング | RHEL互換のため同一RPM適用可 |
| 各ディストリ標準リポジトリ | OSベンダー判断 | 1週間-1ヶ月 | OSのマイナーアップデート扱い、バックポートに時間を要する |
本番運用機で「すぐパッチを当てたい」「公式リリース当日に対応したい」場合は、PGDGリポジトリを使う構成が現実解です。OS標準リポジトリだけだと、ベンダー側のバックポート作業を待たねばならず、特にCVSS 8.8の4件のような緊急性が高い更新で1週間以上タイムラグが出ます。
反映確認はUbuntu/Debian系で apt-cache policy postgresql-17、RHEL/Rocky系で dnf info postgresql17-server を打ち、末尾のマイナー番号（17.10など）がPostgreSQL本体リリースのマイナー番号と一致しているかを見ます。一致していなければまだリポジトリに反映されていないので、もう一日待つかPGDG本家リポジトリへ切り替えます。
pg_upgradeを避けて済ませる前提条件
今回のリリースはマイナーバージョンアップ（18.3→18.4、17.9→17.10 等）です。PostgreSQL公式アナウンスは明示的に次のように述べています。
「すべてのPostgreSQLアップデートリリースは累積的です。他のマイナーリリース同様、ユーザーはこのアップデートリリースを適用するためにデータベースのダンプおよび再ロード、または pg_upgrade を使用する必要はありません。PostgreSQLを停止してバイナリを更新するだけで済みます。」
つまり、今回はpg_upgrade不要・ダンプリストア不要、サーバー停止→パッケージ更新→サーバー起動の3ステップで完了します。これが成立するのは「同一メジャー内のマイナー更新」だからです。例えば 17.9→17.10 は内部ストレージ形式が同じなのでデータディレクトリをそのまま再利用できます。
pg_upgradeが必要になるケース（今回は該当しない）
- 14→15、15→16、16→17、17→18のようなメジャー跨ぎアップグレード
- 1つ以上のマイナーリリースをスキップしていて、リリースノートに追加手順が記載されているケース
後者は特に注意で、例えば17.6で止めていたインスタンスを17.10に上げる場合、17.7や17.8のリリースノートに「アップグレード後にREINDEX CONCURRENTLYが必要」といった追加手順が含まれていることがあります。スキップしたバージョン全てのリリースノートを確認してから当てます。
systemd管理下でのローリング再起動手順
パッケージマネージャ経由でPostgreSQLを動かしているなら、systemd経由で停止・更新・起動を制御するのが基本です。手順を間違えると「停止前に新バイナリが入って起動できなくなる」「再起動が走らずバイナリと動作バージョンがズレる」事故が起きます。
単独構成（マスタ1台）の場合
# 1. 現状確認とアクティブクエリ確認
sudo -u postgres psql -c "SELECT version();"
sudo -u postgres psql -c "SELECT pid, now() - query_start AS duration, query FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC LIMIT 5;"
# 2. 停止 → 更新 → 起動（RHEL系PGDG例、17.10へ）
sudo systemctl stop postgresql-17
sudo dnf update postgresql17 postgresql17-server postgresql17-contrib postgresql17-libs
sudo systemctl start postgresql-17
# 3. バージョン確認＋起動ログ確認
sudo -u postgres psql -c "SELECT version();"
sudo journalctl -u postgresql-17 -n 50 --no-pager
systemctl stop はデフォルトで pg_ctl stop -m fast 相当の挙動（既存セッションへロールバック指示後に停止）になるため、手順としてはsystemctl stopで問題ありません。-m smart は全クライアントが自発的に切断するまで待つので運用中だと詰みます。
OS標準リポジトリ版を使っているならパッケージ名は postgresql / postgresql-server / postgresql-contrib、サービス名はUbuntu/Debianなら postgresql@17-main、RHEL系なら postgresql になります。apt-get install --only-upgrade はパッケージ更新時にサービスを自動再起動することがあるので、本番ではメンテナンスウィンドウ内で実行します。
接続ダウンタイム最小化（PgBouncer/Patroni併用パターン）
単独構成だと再起動中の30秒-2分はアプリケーションから「接続できない」状態になります。これを最小化する2つのパターンを整理します。
PgBouncerでアプリ側エラーを吸収
PostgreSQLの手前にコネクションプーラPgBouncerを挟むと、PostgreSQL再起動中はPgBouncerが新規接続をキューに溜め、PostgreSQL復帰後に流し直してくれます。アプリ側からは「ちょっと遅いクエリ」に見え、エラーにはなりません。設定の要点は次の3つです。
- pool_mode = transaction: トランザクション単位の接続再利用。再起動時に既存トランザクションを保護できる
- server_lifetime = 600: バックエンド接続の最大生存時間。再起動後に古い接続を持ち越さないため短めに設定
- reserve_pool_timeout = 5: 再起動中のキュー待機時間（秒）。アプリ側のタイムアウトより短く
PgBouncer単体では完全無停止にはなりませんが、PostgreSQL本体の再起動を「アプリから見て1-2秒のレイテンシ増」程度に圧縮できます。
Patroni + 同期スタンバイで完全ローリング
マスタ＋同期スタンバイ＋Patroniの3点セットなら無停止でローリングアップグレードできます。流れは「スタンバイ側でパッケージ更新→systemctl restart patroni→patronictl list で 17.10 復帰確認→patronictl switchover→旧マスタ側でも同じ手順を繰り返す」です。switchover時に数秒のクエリエラーが出るのでPgBouncerと組み合わせて完全に隠します。Patroni運用に慣れていないなら今回のマイナー更新で初投入するのはおすすめしません。本番外で1回予行演習してから入れます。
適用前後のチェックリストとFAQ
適用前は、pg_dump または pg_basebackup でバックアップ取得（CVE-2026-6475を踏まえバックアップ用アカウントの権限も再確認）、SELECT version(); で現バージョン記録、スキップしたマイナーリリースのリリースノート確認、PgBouncer/Patroniのヘルスチェック動作確認。適用後は、SELECT version(); で新バージョン反映確認、journalctl -u postgresql-XX -n 200 で起動エラー有無確認、pg_stat_activity で接続復帰確認、レプリケーション構成なら pg_stat_replication で同期復帰確認、psql / pg_dump / pg_basebackup のクライアント側もバージョンが揃ったか（CVE-2026-6477対策）。
Q1. 今回のCVEで最優先で当てるべきはどれか
CVSS 8.8の4件（CVE-2026-6473 / 6475 / 6477 / 6637）です。特にCVE-2026-6477はlibpq経由でクライアント側スタックを書き換えられる珍しい型で、サーバーだけでなく psql / pg_dump が動く全ホスト（運用端末・バックアップサーバー・管理用ジャンプホスト）でパッケージ更新が必要です。
Q2. pg_upgradeは本当に不要か
同一メジャー内のマイナー更新（例: 17.9→17.10）なら不要です。公式アナウンスが「ダンプ・リストアもpg_upgradeも不要、バイナリ更新だけで済む」と明示しています。メジャー跨ぎ（17→18等）の場合のみpg_upgradeが必要です。
Q3. PGDGとOS標準リポジトリ、どちらを使うべきか
本番運用機ならPGDGリポジトリを推奨します。OS標準リポジトリはバックポート作業の都合で公式リリースから1週間-1ヶ月遅れることがあり、CVSS 8.8級の緊急パッチで間に合わなくなります。検証機ならOS標準でも問題ありません。
Q4. PostgreSQL 14でMD5パスワード認証を使っているが危険か
MD5パスワードを使い続けているならCVE-2026-6478の影響を受けます。今回のパッチで修正されますが、根本対策としてscram-sha-256への移行を推奨します。postgresql.conf に password_encryption = scram-sha-256 を設定後、ALTER USER で再設定するとscram形式でハッシュ化されます。
まとめ
2026年5月14日公開のPostgreSQL 18.4 / 17.10 / 16.14 / 15.18 / 14.23は11件のCVEを修正、うち4件がCVSS 8.8で攻撃成立時の被害が大きい構造です。マイナー更新なのでpg_upgradeは不要、サーバー停止→パッケージ更新→起動の3ステップで完了します。本番運用機ならPGDGリポジトリを使って公式リリース当日-数日以内に適用するのが現実解です。PgBouncerでアプリ側エラーを吸収、同期スタンバイ + Patroniならローリングで完全無停止化、という選択肢を運用要件に合わせて選んでください。クライアントツール側（psql / pg_dump / pg_basebackup）が動く管理用ホストも忘れずに更新対象に含めます。
PostgreSQLや他のミドルウェアの脆弱性対応をはじめ、systemd・パッケージ管理・ロールバック設計といった「現場で通用するLinuxサーバー運用の型」については、関連記事のLinuxサーバー構築側もあわせて読むと体系的に整理できます。
参考
・PostgreSQL公式リリースアナウンス: https://www.postgresql.org/about/news/postgresql-184-1710-1614-1518-and-1423-released-3297/・JPCERT/CC週次レポート 2026-05-20: https://www.jpcert.or.jp/wr/2026/wr260520.html
・PostgreSQL Release Notes 18.4: https://www.postgresql.org/docs/release/18.4/
・PostgreSQL Security Information: https://www.postgresql.org/support/security/
・PGDG APT (Debian/Ubuntu): https://apt.postgresql.org/
・PGDG RPM (RHEL family): https://www.postgresql.org/download/linux/redhat/
PR / あわせて読みたい本
- ［改訂3版］内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 上原 一樹／勝俣 智成 ほか / 技術評論社 / 2022年
- はじめてのLinuxサーバー構築入門2025 日経Linux編 / 日経BP / 2025年
PostgreSQLの内部構造とWALの仕組みを押さえると、再起動時に何が起きているかが直感的に理解できるようになります。脆弱性対応のたびに調べ直すのではなく、運用設計レベルで判断できるようになる補強として有効です。
「脆弱性が出るたびに走り回る運用」から卒業したい方へ
systemctl stop、PGDGリポジトリ確認、pg_dump、Patroni switchover。本記事の手順は読むだけでなく、検証機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報を集めるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます