PostgreSQL、12年前から存在した脆弱性を修正　レプリケーション権限を悪用したコード実行が可能に

要点

• PostgreSQLにおいて、レプリケーション権限を持つアカウントが悪意のあるライブラリを読み込ませ、OSの実行権限で任意のコードを実行できる脆弱性（CVE-2026-6471）が修正された。

• 2014年のPostgreSQL 9.4で論理デコーディング機能が導入されて以来、約12年間にわたって潜在していた問題であることが判明した。

• セキュリティ企業Cyeraの研究者によって「PostGREShell」と名付けられ、Windows環境では外部のファイル共有からライブラリを直接読み込ませる攻撃が可能とされている。

• 修正パッチでは許可するプラグインを制限するホワイトリスト設定が導入され、標準外のプラグインを使用している環境では更新後の追加設定が必要となる。

• オープンソースのデータベース管理システム「PostgreSQL」において、レプリケーション権限を持つユーザーがデータベースサーバー上で任意のコードを実行可能になる脆弱性が修正された。開発プロジェクトおよびセキュリティ企業の報告によって明らかになった。この問題は2014年に導入された論理デコーディング機能に起因し、約12年間にわたり存在していたという。

12年間潜在していた脆弱性「PostGREShell」

修正された脆弱性は「CVE-2026-6471」（CVSSスコア7.2）として管理されている。影響を受けるのは、PostgreSQL 18.6、17.11、16.15、15.19、14.24よりも前のバージョンだ。

本脆弱性は、2014年リリースのPostgreSQL 9.4で「論理デコーディング」（データベースの更新ログを外部から読み取り可能な形式へ変換する機能）が追加された当初から存在していた。脆弱性の悪用には、「REPLICATION」属性を持つデータベースアカウントと、サーバーの設定パラメータ wal_level が logical に設定されている環境が必要となる。このREPLICATION属性は、バックアップツールや待機系サーバー、CDC（データベースの変更データを抽出する仕組み）のパイプライン、監視システムなどで日常的に付与されている権限だという。

この問題はVladimir Tokarev氏とYu Kunpeng氏によって報告された。Tokarev氏が所属するデータセキュリティ企業Cyera Researchは9月1日に詳細な調査レポートを公開し、本脆弱性を「PostGREShell」と命名している。

パス制限の不備によるライブラリ読み込みと攻撃手法

Cyeraの解説によると、脆弱性の根本的な原因は、レプリケーションスロットを作成する CREATE_REPLICATION_SLOT コマンドで渡されたプラグイン名が、ライブラリをロードする内部関数へ直接引き渡されていた点にある。

通常、PostgreSQLにはスーパーユーザー以外のユーザーによるプラグインのロードを管理者が制御する単一ディレクトリに制限する保護機能が備わっている。しかし、レプリケーションの処理経路ではこのチェック機能が呼び出されていなかった。さらに、レプリケーションプロトコルの構文解析処理では、ダブルクォートで囲まれたプラグイン名の中にパス区切り文字や親ディレクトリを示す「../」を含む文字列がそのまま許容されていたため、指定されたファイルシステムのフルパスがそのままローダーへ到達していたという。

攻撃の手法は実行環境によって異なる。Windows環境では、サーバーがSMB（ネットワークファイル共有プロトコル）を介してネットワークパスを解決するため、攻撃者が用意した外部マシンから直接ライブラリを取得させることが可能であり、標的サーバーにファイルを書き込む必要すらないとCyeraは指摘している。一方、LinuxやmacOS環境で同様の遠隔ロードを行うにはNFS（Network File System）の自動マウントが有効である必要があり、そうでない場合は事前にサーバーのディスク上へファイルを配置する手段が求められる。

読み込まれたコードは、データベースのバックエンドプロセス内部において、データベースを動かしているOSの postgres ユーザー権限で実行される。Cyeraの検証用プラグインでは、ロール管理テーブルを直接書き換えてレプリケーションアカウントを最高権限であるスーパーユーザーへ昇格させたり、サーバー再起動後も維持される3つの永続化処理を組み込んだりすることが確認された。

なお、権限評価についてCyeraはREPLICATION属性を低権限のバックアップ用認証情報と位置付けているが、PostgreSQLプロジェクトおよびLinuxディストリビューション大手のSUSEは、本脆弱性の悪用に必要な権限（Privileges Required）を「High（高）」と判定している。

ホワイトリスト導入による修正と管理者への影響

PostgreSQLの開発チームは8月13日に本脆弱性の修正パッチを公開した。修正にあたっては、論理デコーディングの出力プラグインとして読み込みを許可するライブラリを管理者が指定する新しいサーバーパラメータ output_plugin_libraries が追加された。デフォルト設定では 'pgoutput, test_decoding' のみが許可される。

パッチを作成したJacob Champion氏はコミットメッセージの中で、従来の標準的な読み込み制限をレプリケーション経路にそのまま適用すると、すべてのサードパーティ製プラグインを $libdir/plugins ディレクトリに再配置する必要が生じてしまうため、既存環境への影響を考慮してホワイトリスト方式を選択したと説明している。

また、PostgreSQL Global Development Groupは18.6のリリースノートにおいて、「従来はレプリケーションユーザーが論理デコーディング用にロード可能な任意のライブラリを選択できたため、様々な悪用が可能だった。これまで動作していた環境を損なうことなく制限をかけるため、許可された出力プラグインのホワイトリストを導入した」と述べている。

この変更に伴い、wal2json や decoderbufs などの標準外プラグインを使用している環境では、アップデート後に管理者が設定パラメータに該当ライブラリを追加して設定を再読み込み（リロード）するまで、論理デコーディングの実行が拒否される。ロードに失敗した場合、サーバーログには ERROR: library "..." may not be used as an output plugin というエラーメッセージと設定に関するヒントが出力される。

管理者はアップデートの事前準備として、SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; というSQLクエリを実行し、現在使用されている出力プラグインをあらかじめ確認しておくことが推奨されている。