脆弱性 / VULNERABILITIES / DATABASE
PostgreSQLに12年間潜んだ重大欠陥「PostGREShell」 — 低権限の複製アカウントからRCE・管理者昇格・持続的バックドアへ
Cyeraは9月1日、PostgreSQLの論理デコードに欠陥CVE-2026-6471(CVSS 7.2)を報告した。2014年のバージョン9.4以降の全世代に存在し、REPLICATION権限を持つ低権限アカウントが細工したプラグイン名を送るだけでサーバ上で任意のコードを実行できる。WindowsではSMB経由で完全に遠隔から悪用でき、奪った足場からスーパーユーザーへ昇格して再起動後も残るバックドアを仕掛けられる。修正版は2026年8月のセキュリティリリースで公開済みだ。
データセキュリティ企業のCyeraは2026年9月1日、オープンソースデータベースのPostgreSQLに重大な脆弱性**CVE-2026-6471(通称PostGREShell、CVSS 7.2)**が存在したと報告した。欠陥は2014年公開のバージョン9.4以降、すべての世代に12年間残っていた。バックアップ用途で広く配られる低権限の複製アカウントが、細工した1つのコマンドを送るだけでデータベースサーバを乗っ取れる。修正版は2026年8月のPostgreSQLセキュリティリリースで公開済みだ。
何が起きるのか:複製アカウントがサーバ全体の支配権に変わる
PostgreSQLを本番運用する組織は、書き込みを受けるプライマリと同期するレプリカを複数台走らせるのが一般的だ。同期には専用の複製プロトコルを使い、その利用にはREPLICATION属性を持つアカウントが必要になる。このアカウントはバックアップツールや監視基盤など至る所に配られており、PostgreSQL自身の文書もコード実行権限とは結び付けていない「事務方」の権限として扱われてきた。
問題は論理レプリケーションの経路にある。変更を外部ツールが読める形に整える「出力プラグイン」を、利用者がCREATE_REPLICATION_SLOTコマンドで指名する仕組みだ。Cyeraの解析によると、PostgreSQLはこのプラグイン名を検証も無害化もせず、そのまま読み込み処理に渡していた。通常のSQLのLOAD命令には管理者管理ディレクトリ外の読み込みを拒む検査関数が付いているが、複製経路にはその検査が一切呼ばれていなかった。しかも複製プロトコルの構文解析は、二重引用符で囲んだプラグイン名の中にスラッシュやバックスラッシュ、../による親ディレクトリ参照、WindowsのUNCパスまでほぼそのまま通してしまう。結果として、攻撃者が渡したファイルシステム上のパスが、動的ライブラリ読み込み関数(Linux/macOSのdlopen()、WindowsのLoadLibrary())にそのまま届き、サーバプロセスの権限で任意のコードが実行される。修正はC言語わずか2行だったとCyeraは伝えている。
Windowsでは完全遠隔、Linux/macOSにも経路がある
悪用条件はOSごとに異なるが、Cyeraはすべてのプラットフォームで成立すると確認している。
- Windows:攻撃者の用意したSMB共有へのUNCパスを渡すと、PostgreSQLが攻撃者側サーバからDLLを自動取得して読み込む。標的のファイルシステムに一切触れず、ネットワーク越しにそのまま遠隔でコードが実行される。必要なのはREPLICATION権限のアカウントと、サーバ側で論理複製(
wal_level = logical)が有効なこと、サーバから攻撃者へのSMB(445番ポート)到達だけだ。 - NFS自動マウントが有効なLinux/macOS:
/net/<ホスト>/...形式のパス参照で攻撃者側のNFS共有(2049番ポート)が自動マウントされ、同様に外部からライブラリを読み込ませられる。 - 通常のLinuxやDocker/Kubernetes環境:別経路でファイルを置けることが前提になるが、
../参照で配置済みの悪性.soを読み込ませられる。
スーパーユーザー化と三重のバックドア
コード実行の足場を取った時点で、攻撃者はデータベースサーバ上でpostgresシステムユーザとして動くコードを手に入れる。PostgreSQLのSQL層の権限検査は堅牢だが、読み込まれたコードが内部APIを直接呼ぶC言語層には検査が存在しない。サーバは読み込んだコードを無条件に信頼するため、プラグインは内部関数を呼んでセッション上のブートストラップスーパーユーザーになり、利用者を定義するカタログ表pg_authidに直接書き込んで全権限フラグを立てる。この書き込みはSQL実行器を通らないため権限検査が発火せず、変更は正規のALTER ROLEと見分けがつかない形で残り、再起動後も消えない。さらに全権限検査を「許可」で返すフックも仕掛けるという。
スーパーユーザーを奪われると、全データベースの全表の読み取りに加え、OSコマンド実行(COPY ... TO PROGRAM)、任意ファイル読み取り(pg_read_file())、ファイル書き込み(lo_export())が可能になり、サーバ自体が攻撃者の手に落ちる。Cyeraによると、プラグインは再侵入用に3つの永続化を相互補完的に施す。接続認証設定pg_hba.confを「誰でも誰としてでもパスワードなしで接続可」に書き換えて即時再読み込みし、自身を安定した場所に複写してshared_preload_librariesに登録して再起動後の再読み込みを確保し、管理者がスーパーユーザー化を取り消しても再適用する。1つ見つけて直しても残り2つが残る構成だ。
なおCyeraは脅威ハンティングの一環でVirusTotalを調査し、すでに野良で出回っている悪性PostgreSQLプラグイン114件(トロイの木馬、暗号資産マイナー、リバースシェルなど)を確認したという。今回の欠陥の悪用事例として断定されたものではないが、同種の経路を狙う攻撃者が実在することの裏付けになる。
開示の経緯と、Cyeraが推奨する対応
Cyeraの開示タイムラインによると、同社は2026年2月21日に原因分析・影響範囲・Windowsでの概念実証・修正案を添えてPostgreSQLセキュリティチームに報告し、同月27日に脆弱性として確認された。修正は定例のマイナーリリースに載る形で進み、2026年8月のセキュリティリリースで公開された。CyeraはPostgreSQLセキュリティチームの対応に謝意を示している。
Cyeraは利用組織に向けて、次の対応を推奨している(同社報告の「How to protect yourself」による)。
- 公開済みのPostgreSQLセキュリティ更新を適用する
- 全インスタンスのREPLICATIONアカウントを棚卸しし、不要なアカウントからREPLICATION属性を外す
- 残すアカウントは
pg_hba.confで接続元を信頼できるIPに絞り、複製用途に0.0.0.0/0を使わない - データベースサーバからの外向きSMB(445番)・NFS(2049番)をファイアウォールで遮断し、不要なautofsを無効化する
- 想定外のIPからの
CREATE_REPLICATION_SLOTや、プラグイン名に/・\・..を含む要求、奇妙なスロット名といった異常な複製活動を監視する
PostgreSQLはAWS RDSやAzure Database、Google Cloud SQLなどのマネージド基盤や国産SaaSにも広く採用されており、日本の組織にも影響が及び得る。クラウドのマネージドDBは提供事業者側でパッチが当たる場合が多いが、自前運用のインスタンスは管理者自身の更新が必要になる。バックアップ用アカウントは「低権限だから安全」と見なされがちだが、今回の事例はその前提が崩れることを示した。まず更新の適用と複製アカウントの棚卸しから着手したい。
出典
この記事は、公開情報と編集部の調査・知見をもとに構成しています。内容は公開時点の情報に基づく解説であり、個別の環境への診断・対応を保証するものではありません。重要な判断では、記事内の出典や各提供元の最新情報もご確認ください。