PostgreSQL拡張pglogical、受け側が最高権限 CVE-2026-50736は2.4.8へ

データベースソフト PostgreSQL に後から追加して使う部品（拡張）の pglogical に、脆弱性が4件まとめて公表されました。CVE-2026-50736、CVE-2026-50737、CVE-2026-50735、CVE-2026-50738 の4本で、米国の脆弱性データベース NVD への登録は2026年7月28日19時17分（協定世界時）です。

最初に、混同しやすい点を切り分けます。これは PostgreSQL 本体の脆弱性ではありません。PostgreSQL は本体だけで動きますが、機能を足したいときに「拡張」と呼ばれる部品をインストールできる仕組みを持っています。pglogical はその拡張のひとつで、あるデータベースの更新内容を別のデータベースへ流し込む「レプリケーション（複製）」を担当します。今回の4件はすべて、この拡張の中で起きています。PostgreSQL 本体を最新に保っていても、pglogical を入れていれば別途対応が必要です。

そして、この4件の芯はひとつです。データを受け取る側のプロセスが、データベースの最高権限で動いているという設計そのものです。開発元の pglogical 2.4.8 が同日18時10分（協定世界時）に公開され、4件すべてがここで修正されています。ただし後述するとおり、2.4.8 に上げるだけでは「最高権限で動く」という既定の挙動は変わりません。

公表された4件の一覧

CVE番号を割り当てたのは、pglogical を配布している EnterpriseDB（EDB）です。CVSS（脆弱性の深刻度を0〜10で表す共通指標）の値は、この EDB が CVE の記録に添えたもので、NVD 自身の評価はまだ入っていません。

影響範囲は4件とも同じです。EDB の記録では pglogical 2系のうち 2.4.8 より前のすべてのバージョンが該当します。報告者も4件とも同じで、脅威インテリジェンス企業 PRODAFT の共同創業者・CTO である Mehmet Ince（@mdisec）です。本人のサイトによれば、2008年から300件以上の脆弱性を公表しており、直近は PostgreSQL 周辺の拡張やツールを続けて調べています。

入口を持てるのは「送り出す側に立てる人」だけ

この4件を使えるのは、インターネットの向こう側にいる無関係な誰かではありません。狙えるのは 「データを送り出す側のサーバーになれる人」、あるいは「送り出す側のサーバーを先に乗っ取った人」です。複製は送り手と受け手が事前に約束を交わして始まる仕組みなので、その約束の片側に立てる人だけが入口を持ちます。具体的には、レプリケーションの相手先を自分で指定できる社内の担当者、複製を提供している事業者の利用者、そして送り手側のサーバーに侵入済みの攻撃者です。

論理レプリケーションの送り手側に回れた相手は、複製データに見せかけた命令を受け手のデータベースに流し込み、受け手側で最高権限のまま実行させます。データを1件ずつ書き換えるといった細かい話ではなく、受け手のデータベース全体を自由にできる権限が手に入ります。同じサーバーの中にある別の顧客のテーブル、パスワードのハッシュを含む管理情報、暗号化していない個人情報まで、その権限の届く範囲はすべてです。

受け手の最高権限が誰の手に落ちるかは、単独環境か共有環境かでまるで意味が変わります。自社だけで送り手も受け手も運用しているなら、そもそも両方の管理権限を持っているので新たに失うものは少ないです。困るのは、送り手と受け手の管理者が別人である構成です。部門ごとにデータベースを分けて相互に複製している会社、グループ会社間でマスターデータを配っている構成、複数の顧客に複製機能を提供している事業者では、片方の侵害がもう片方の最高権限に直結します。守る側の視点で言えば、「相手のデータベースを信用していないのに、相手からのデータを最高権限のプロセスで受け取っていた」という状態です。

受け取る側が最高権限で動くとはどういうことか

4件のうち CVE-2026-50736 と CVE-2026-50737 は、入口がまったく別です。前者は複製の通り道に用意された「命令を運ぶ仕組み」、後者は「列が欠けた行を埋めるときの既定値の計算」です。それでも危険な理由はひとつに帰着します。どちらも apply worker と呼ばれるプロセスの中で起きるからです。

apply worker は、受け手のデータベースの中で常に動いている裏方です。送り手から届いた「この行が追加された」「この行が消えた」という報告を受け取り、自分のデータベースに同じ変更を書き込む役目を持ちます。pglogical の設計では、この裏方が PostgreSQL のスーパーユーザー（データベースの最高権限を持つ利用者）と同等の権限で動いていました。CVE-2026-50737 の説明にある「apply worker がスーパーユーザー相当の権限で動くため、そこで呼ばれる関数もその権限で走る」という一文が、そのまま今回の話の全部です。

日常のたとえで言い直します。宅配便の荷物を受け取る係員が、たまたま会社の全部屋のマスターキーを持って作業していた状態です。届いた荷物の中に「この箱を開けたら金庫室のドアも開けてください」という紙が入っていたら、係員はマスターキーを持っているので実際に開けられます。荷物の中身を疑う仕組みがなく、係員の権限を落とす仕組みもなかったため、送り主が悪意を持つだけで金庫まで届いてしまいます。

この構図は pglogical で初めて出たものではありません。2021年の CVE-2021-3515 では、データベース名に細工をすることで pglogical.create_subscription() 経由で OS のコマンドが postgres ユーザー権限で実行できました。修正は 2.3.4 でした。5年前と今回で、権限の落とし所が違うだけで話の型は同じです。

4件それぞれの中身

CVE-2026-50736: 複製の通り道に流した命令が最高権限で実行される

pglogical には queue と呼ばれる仕組みがあります。行の追加や削除といった普通のデータ変更とは別に、テーブルの作り替え（DDL）のような「データ以外の命令」を送り手から受け手へ運ぶための通り道です。NVD の記載によれば、この queue に載ったメッセージの中身は、受け手側で apply worker の権限、つまり既定の構成ではスーパーユーザー相当の権限で実行されます。

結果として、送り手の立場に立てる相手は queue に細工したメッセージを載せるだけで、受け手側で任意の SQL をスーパーユーザーとして走らせられます。NVD の説明はこれを「pglogical の利用を許されたロールから完全なスーパーユーザーへの昇格であり、共有環境ではテナント間の分離が壊れる」と書いています。EDB が付けた CVSS 4.0 は 9.0（CRITICAL）、ベクタは CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H です。分類は CWE-89（SQLインジェクション）が当てられていますが、実際の問題は「文字列の組み立てを間違えた」ことではなく「実行時の権限が高すぎる」ことなので、CVE-2026-50737 に当てられた CWE-250（不必要に高い権限での実行）のほうが実態に近い分類だと考えられます。

CVE-2026-50737: 列が欠けた行を書き込むとき、既定値の式が最高権限で走る

こちらは queue を経由しません。送り手から届いた行のデータに、受け手側のテーブルが持っている列の一部が含まれていない場合、pglogical は受け手側でその列の「既定値（DEFAULT）の式」を計算して埋めます。PostgreSQL の既定値には固定の値だけでなく関数呼び出しも書けるので、そこに関数が仕込まれていれば、行を1件適用するだけでその関数が動きます。

その関数を動かすのは、やはり apply worker です。NVD の記載は、この件を「CVE-2026-50736 で追跡されているのと同じスーパーユーザー昇格に至る、2つ目の独立した経路」と明記しています。CVSS 4.0 は CVE-2026-50736 と同じ 9.0（CRITICAL）で、ベクタも同一です。入口が2つあることの意味は実務上大きく、片方だけを塞いでも回避されるということです。だからこそ修正も、queue と既定値のそれぞれに手を入れるのではなく、権限そのものを落とせるようにする方向で入りました。

CVE-2026-50738: 解放済みメモリの参照でワーカーが落ちる

pglogical のワーカーに合図を送るコードに、use-after-free（すでに解放したメモリ領域を参照してしまう不具合）があります。NVD の記載によれば、これはワーカーの起動・停止・再起動というごく普通の出来事の途中で踏み得るもので、pglogical の操作を許された権限の低い利用者がタイミングを揺らすことでも到達します。

開発元の修正コミットが原因をはっきり書いています。トランザクションが中断されたとき、合図を送る対象のリスト（signal_workers）が空に戻されないまま、中身だけが先に解放されていました。通常のケースではレプリケーションのワーカーが落ちるだけで、影響は可用性、つまり「複製が止まる」ことにとどまります。ただし NVD の説明は「最悪の場合、PostgreSQL のバックエンドにおける use-after-free は、そのバックエンドの権限での任意コード実行の足場として使い得る」とも書いています。EDB の CVSS 4.0 は 7.7（HIGH）で、この数値は最悪の場合を見た評価です。実際に踏んだときにまず現れるのは、原因のわからないレプリケーション停止です。

CVE-2026-50735: 受け取ったデータの長さを検証せず、隣のメモリまで読む

4件のうち唯一、権限昇格ではないものです。apply worker が複製プロトコルのメッセージを読むとき、一部のフィールドの長さを十分に検証せずにコピーしていました。その結果、確保したメモリ領域の外まで読み進めてしまい、隣接するプロセスメモリの内容が漏れる、あるいはワーカーが落ちます。

開発元の修正コミットは、2つの問題を並べて説明しています。1つは、メッセージを読む関数がバッファ内のポインタを返すだけでコピーをしないため、テキスト表現が終端のゼロバイトなしで型入力関数に渡され、属性の終わりを越えて隣のヒープメモリまで読み進めていた点です。もう1つは、内部表現の前に付いている長さが受け手側の列定義と突き合わされていなかった点で、実際に送られた量より大きな値を書いた可変長ヘッダを渡せば、タプルを扱うコードが属性の外まで読みます。2.4.8 の変更点ではこれを「上流ノードから受け取ったタプルデータの無害化」として、コピーを伴う読み込みへの変更、固定長・可変長それぞれの長さ検証、外部データの拒否で塞いでいます。

NVD の説明が挙げている前提が示唆的です。「pglogical の複製プロトコルを話す PostgreSQL 以外のエンドポイント」でも送り手になれる、という書き方をしています。つまり本物の PostgreSQL を用意する必要すらなく、プロトコルを喋るだけの偽の送り手を立てれば入口になります。CVSS 4.0 は 6.1（MEDIUM）です。

自分のバージョンはどうか、早見表

まず入っているかどうかと版を確認します。データベースに接続して次を実行すれば分かります。何も返ってこなければ、そのデータベースに pglogical は入っていません。

問題は、確認して該当していたとしても、多くの入手経路ではまだ 2.4.8 が降ってきていないことです。2026年7月29日04時30分（協定世界時）に各配布元を確認した結果が下の表です。

実務上いちばん重いのは最後の2行です。pglogical を入れる人の多くは PostgreSQL コミュニティの公式リポジトリ（PGDG）から postgresql-17-pglogical のような形で導入します。そのリポジトリの最新がまだ 2.4.7 なので、apt upgrade や dnf update を回しても修正版は入りません。Debian の セキュリティトラッカーにも、この4件の CVE はまだ登録されていません（同じページに 2021年の CVE-2021-3515 は載っています）。当面の選択肢は、ソースから 2.4.8 をビルドするか、パッケージが更新されるまで後述の緩和策で持たせるかの2つです。

2.4.8 に上げても既定の権限は下がらない

2.4.8 の中身で最も読み違えられやすいのがここです。2.4.8 の変更点を読むと、CVE-2026-50736 と CVE-2026-50737 に対する修正は「サブスクリプションに subscription_owner パラメータを追加」と書かれています。つまり穴を塞いだのではなく、権限を落とすためのつまみを新設したという形です。

開発元の 修正コミットのメッセージが、そのまま結論を書いています。「このパラメータが指定されると、サブスクリプションはこのロールの権限で動く。指定しなければスーパーユーザーとして動く」。同じコミットで書き足された 公式ドキュメントも「既定は空で、その場合 pglogical はスーパーユーザーとして動く」と明記しています。2.4.8 を入れただけの状態は、権限の面では 2.4.7 と同じです。

権限を落とすには pglogical.subscription_owner に専用のロールを指定し、そのロールへ必要な権限を手で与えます。ドキュメントが挙げている手順は素直ではありません。対象テーブルへの SELECT / INSERT / UPDATE / DELETE は synchronize_structure では付与されないため、初期同期は成功するのにその後の最初の変更が権限エラーで止まります。pglogical 自身のカタログ（pglogical スキーマ）への権限も別途必要で、これが無いと管理ワーカーが起動直後に落ちてサブスクリプションが1つも立ち上がりません。ALL TABLES は実行時点のテーブルにしか効かないので、拡張のアップグレードでカタログが増えたら付け直しが必要です。

さらに、複製される DDL と TRUNCATE は直接適用されずに queue へ回され、送り手側で実行したロールに SET ROLE してから再生されます。そのため指定したロールは、送り手側で DDL を実行するすべてのロールのメンバーである必要があります。ドキュメントはここに率直な注意を添えています。「スーパーユーザーが実行した DDL を複製する場合、このパラメータで得られる分離はほとんど残らない」。運用でよくある「移行作業は管理者アカウントでやる」というやり方をそのまま続けるなら、つまみを回しても効果は限定的だという意味です。

同じコミットで、ドキュメントの制限事項の見出しも「スーパーユーザーが必要」から「管理にはスーパーユーザーが必要」へ書き換えられました。管理操作（ノードやサブスクリプションを作る関数）にはスーパーユーザーが要るが、受け手側で変更を適用すること自体にはスーパーユーザーは要らない、という整理です。設計の前提が公式に修正されたことを示す変更で、5年前の CVE-2021-3515 のときにはここまで踏み込みませんでした。

成立条件はどこまで厳しいのか

過大評価を避けるために、条件を正確に切ります。これはインターネットに面した攻撃ではありません。4件すべてに共通する前提は「攻撃者が、自分の支配下にあるエンドポイントへサブスクリプション（受け取りの設定）を向けられること」です。NVD の説明は続けて「既定のインストールでは、これは通常スーパーユーザーに限られる権限を必要とする。したがってこの問題は、サブスクリプションを作る権限がスーパーユーザー以外のロールへ委譲されているマネージド環境で最も関係が深い」と書いています。

ここに数値と説明文の食い違いがあります。EDB が付けた CVSS 4.0 のベクタは PR:L、つまり「必要な権限は低い」となっています。一方で説明文は「既定の構成ではスーパーユーザー相当の権限が必要」と書いています。この2つは矛盾しているように見えますが、想定している環境が違います。自社で完結した既定構成なら、そこに手が届く人はすでに最高権限を持っているので昇格するものがなく、CVSS 9.0 という数値は現実の脅威度とずれます。反対に、サブスクリプション作成権限を一般ロールに委譲したマネージド環境やマルチテナント環境では PR:L が正しく、9.0 がそのまま降ってきます。同じ CVE が、構成によって「実質無害」と「テナント分離の全壊」に分かれます。

この非対称性は、自社構成を棚卸しする軸になります。以下のいずれかに当てはまるなら、優先度を上げる価値があります。組織や部門をまたいでレプリケーションしている。グループ会社や取引先のデータベースから受け取っている。複数の顧客に複製機能を提供している。サブスクリプションを作る権限をスーパーユーザー以外に渡している。当てはまらず、送り手も受け手も自分たちだけで閉じているなら、パッケージが更新されるのを待って通常のメンテナンスで上げる判断も成立します。

PostgreSQL 本体の論理レプリケーションに移れば済むのか

pglogical が担う機能は、PostgreSQL 10 以降に組み込まれた論理レプリケーションと重なります。そこで「本体の機能に寄せれば解決するのでは」という発想が出ますが、一次情報を読むと単純な置き換えにはなりません。

権限設計については、本体のほうが後から整えられています。PostgreSQL の公式ドキュメントによれば、適用プロセスはセッション単位ではサブスクリプションの所有者の権限で動き、個々のテーブルへ書き込むときはそのテーブルの所有者へロールを切り替えます。サブスクリプションを作るには pg_create_subscription ロールの権限とデータベースへの CREATE 権限が必要で、スーパーユーザーである必要はありません。既定でスーパーユーザーとして動く pglogical とは出発点が違います。

ただし本体側にも似た落とし穴があります。同じドキュメントは run_as_owner = true を設定した場合について、「複製先のテーブルを所有する利用者は、サブスクリプション所有者の権限で任意のコードを実行できる。たとえば自分が所有するテーブルにトリガーを付けるだけでよい」と書き、「データベース内の利用者間のセキュリティが問題にならない場合を除き、このオプションは避けるべきである」と警告しています。設定ひとつで pglogical と同じ構図に戻ります。

加えて、本体の論理レプリケーション自身も2026年に脆弱性が出ています。CVE-2026-6476（pg_createsubscriber でサブスクリプション名経由の SQL インジェクション、CVSS 7.2、18.4 / 17.10 で修正）と CVE-2026-6638（REFRESH PUBLICATION でテーブル名経由の SQL インジェクション、CVSS 3.7、18.4 / 17.10 / 16.14 で修正）です。移行先が無傷というわけではありません。

機能面でも差があります。EDB の公式ドキュメントは pglogical の用途として、メジャーバージョン間のアップグレード、データベース全体の複製、レプリケーションセットによるテーブル単位の選択的な複製、送り手または受け手での行単位の絞り込み、複数の上流サーバーからのデータの集約を挙げています。特に最後の集約や細かい行フィルタは、本体の機能と一対一で置き換えられません。現時点で言えるのは「本体へ寄せれば権限設計の出発点は良くなるが、同じ機能が揃うかは構成次第で、移行そのものが小さい作業ではない」までです。移行を検討するなら、先に PostgreSQL 18 へのアップグレードで実測した挙動のような形で、自分の環境での再現を取ってから判断するのが安全です。

アップグレードのために入れて、そのまま残っていないか

pglogical を狙って導入した記憶がなくても、入っている可能性はあります。GitHub のリポジトリ説明は、この拡張の売りを「Slony や Bucardo、Londiste よりはるかに速いレプリケーション、そしてメジャーバージョンを跨いだアップグレード」と書いています。PostgreSQL のメジャーバージョンを上げるとき、停止時間を短くするために新旧の2台を並べて pglogical で追いつかせ、切り替える、という手順が広く使われてきました。

この使い方では pglogical は移行の道具であって、切り替えが終われば役目が終わります。ところが DROP EXTENSION pglogical と shared_preload_libraries からの削除は、切り替え当日の作業リストの末尾に置かれがちで、「動いているから触らない」でそのまま残ります。数年前のアップグレードで入れた拡張が、今もスーパーユーザー相当の権限を持つワーカーを抱えたまま常駐している構成はあり得ます。今回の4件は、まさにその常駐部分に当たっています。

確認は簡単です。前掲の pg_extension を見る SQL に加えて、psql で \dx を実行すれば拡張の一覧が出ます。使っていないなら、上げるのではなく外すのが最も確実な対策です。この機会に、他の拡張についても「入れた理由が今も残っているか」を見直す価値があります。データベースの拡張は OS のパッケージ管理から外れた場所に置かれることが多く、通常の脆弱性スキャンで見落とされやすい層です。依存関係の棚卸しの考え方は OSS サプライチェーン スキャナーにまとめてあります。設定を見直すついでに性能面も触るなら、PostgreSQL のチューニングを15パターンで実測した検証が参考になります。

数値の扱いと、公開時点で確定していないこと

この記事を書いている2026年7月29日時点で、指標類の状況は次のとおりです。数値が出ていないことを「安全」と読み替えないための整理です。

CVSS について補足します。NVD のページには CVSS 4.0 の値が表示されますが、これは「Secondary」、つまり CVE番号を割り当てた EDB が申告した値です。NVD 自身の評価（Primary）はまだ入っておらず、CVE の状態は Received のままです。NVD の分析が入った段階で値が動く可能性があります。CISA の KEV カタログには4件とも載っていません（当サイトでは KEV の掲載状況を日本語で追えるダッシュボードを公開しています）。ただし CISA の Vulnrichment による SSVC 判定は、CVE-2026-50736 / 50737 / 50738 の技術的影響を「total」（全面的）としています。「悪用は確認されていないが、踏まれたときの影響は全面的」という評価です。

EPSS（今後30日以内に悪用される確率の推定値）は、FIRST の API に4件とも記録がありませんでした。公開から24時間経っていないので、まだ計算対象に入っていません。

JVNにも日本語記事にも見当たらない

IPA と JPCERT/CC が運営する脆弱性対策情報データベース JVNDB を「pglogical」で検索すると「該当する脆弱性対策情報はありません」が返ります。CVE番号での照会でも4件の登録はありません。JPCERT/CC の注意喚起、IPA の重要なセキュリティ情報にも、この4件を扱ったものは出ていません。日本語のブログ記事や技術記事も、はてなブックマークの全文検索で該当が0件でした。

つまりこの4件について日本語でまとまった情報は、公開から半日以上経った時点でまだ存在しません。国内で pglogical を使っている組織は多くありませんが、使っている側にとっては CVSS 9.0 が2件そのまま降ってきます。JVN への登録を待つと、その間の判断材料が英語の一次情報だけになります。

影響を受ける母数が小さいことは、正直に書いておきます。pglogical は PostgreSQL を使う組織の全員が入れる部品ではなく、GitHub のスター数も1,231件（確認時点）です。日本国内で pglogical を本番運用している事例の公開情報は限られています。ただし「該当する組織は少ないが、該当する組織では受け手のデータベースの最高権限がそのまま危険にさらされる」という構図は変わりません。

2.4.8へ上げ、そのあと権限を落とす

まず棚卸しです。運用している PostgreSQL のすべてのデータベースに対して pg_extension を確認し、pglogical が入っているかと版を把握します。バージョンが 2.4.8 より前なら該当です。入っていて使っていないなら、拡張を削除して shared_preload_libraries からも外すのが最短で最も確実です。

使っている場合、優先度は構成で決めます。送り手と受け手の管理者が違う、組織や顧客をまたいでいる、サブスクリプションを作る権限をスーパーユーザー以外に渡している、のどれかに当てはまるなら、パッケージの更新を待たずにソースから 2.4.8 をビルドする判断が妥当です。あわせて pglogical.subscription_owner を設定して権限を落とします。設定には前述の権限付与が必要なので、本番投入の前に検証環境で初期同期と最初の変更まで通しておきます。

2.4.8 にすぐ上げられない場合の緩和は、成立条件を潰す方向で考えます。サブスクリプションを作れるロールをスーパーユーザーだけに戻す、レプリケーション接続を受ける先を pg_hba.conf とネットワーク側で信頼できる送り手だけに限る、複製の相手先ホストが想定どおりかを pglogical.subscription の接続文字列で確認する。この3つはいずれも「攻撃者が自分の支配下のエンドポイントへサブスクリプションを向ける」という前提を崩します。加えて CVE-2026-50738 は原因不明のワーカー停止として現れるので、レプリケーションの遅延やワーカーの再起動を監視していない環境では、この機会に監視項目へ入れておくと後から効きます。

最後に、今回の4件が示した一般化できる点をひとつだけ書きます。データを受け取る側は、送られてきた内容を疑う仕組みだけでなく、受け取る側のプロセスの権限を落とす仕組みを持っていないと守れません。pglogical は前者（受け取ったデータの検証）を CVE-2026-50735 で直し、後者（権限の分離）を CVE-2026-50736 / 50737 への対応としてようやく用意しました。同じ問いは、レプリケーション以外の「外から来たものを処理する常駐プロセス」すべてに向けられます。自分の環境で、外部入力を扱っているプロセスがどの権限で動いているかは、一度書き出してみる価値があります。

参照元

• ▸ NVD - CVE-2026-50735（2026年7月28日）
• ▸ NVD - CVE-2026-50736（2026年7月28日）
• ▸ NVD - CVE-2026-50737（2026年7月28日）
• ▸ NVD - CVE-2026-50738（2026年7月28日）
• ▸ pglogical 2.4.8 リリース（GitHub）（2026年7月28日）
• ▸ Add a subscription_owner parameter to subscriptions（修正コミット）
• ▸ pglogical 公式ドキュメント（docs/README.md）
• ▸ EDB Docs - pglogical 2
• ▸ EDB - Security Advisories 一覧
• ▸ PostgreSQL 公式ドキュメント - 論理レプリケーションのセキュリティ
• ▸ PostgreSQL - CVE-2026-6476
• ▸ Debian Security Tracker - pglogical
• ▸ NVD - CVE-2021-3515（2021年の pglogical の脆弱性）
• ▸ Mehmet Ince - Disclosed CVEs
• ▸ CISA - Known Exploited Vulnerabilities Catalog
• ▸ FIRST - EPSS