【更新 2026-08-06】本記事を見直し、修正しました。主な修正点：公開後にNVDで確認できるようになったCVE-2026-17346・17348・17350のCVSSスコアを表に反映（あわせて表の並びを深刻度順に整えました）。CVE-2026-17350の種類・概要を、開発元のリリースノートおよびNVDの記載に合わせて「ツールごとの権限チェックの適用漏れ」を主たる欠陥とする形に補正しました。
PostgreSQL向け管理ツール「pgAdmin 4」に、7件の脆弱性（CVE-2026-17346〜17351、CVE-2026-17566）が見つかり、修正版v9.17が2026年7月30日に公開されました。最大CVSS 9.9で、条件次第でOSコマンド実行や他ユーザーのDB認証情報の窃取に至ります。注目すべきは、このうち複数が「前回の修正の不備」による再発だという点です。前バージョンv9.16に上げただけの組織も、あらためて更新が必要です。
この記事でわかること
- v9.17で修正された7件の脆弱性の中身と深刻度
- なぜ「修正したはずの穴」が再び開いたのか（3つのすり抜け方）
- 自社が影響を受けるかの確認ポイントと、情シスがとるべき対応
何が起きたのか
pgAdmin 4は、PostgreSQLをGUIで管理する代表的なオープンソースツールです。デスクトップ版のほか、ブラウザ経由で複数人が共有利用する「サーバモード」でも広く使われています。開発元は2026年7月30日にv9.17を公開し、7件の脆弱性を一括で修正しました。
当サイトでは6月のv9.16での脆弱性7件も取り上げましたが、今回はその続報にあたります。v9.15（2026年5月11日、8件）、v9.16（同6月18日、7件）、そしてv9.17（同7月30日、7件）と、3か月連続で7〜8件規模のセキュリティ修正が続いている状況です。
修正された7件の脆弱性
CVSSスコアはNVD（米国国立脆弱性データベース）に登録されている値です。本文中のスコアは2026年8月6日時点で確認したものです。
| CVE | 種類 | CVSS（v3.1／v4.0） | 概要 |
|---|---|---|---|
| CVE-2026-17566 | OSコマンドインジェクション | 9.9／9.4（Critical） | Import/Export Dataツールで、psqlの\copyに対する検証をバックスラッシュのエスケープ解釈の差で迂回し、TO PROGRAM句を注入して任意コマンドを実行できる |
| CVE-2026-17349 | 認証情報の漏えい | 9.6／9.3（Critical） | 共有サーバへのアドホック接続時、複製されたサーバ設定に元の所有者のDBパスワード（トンネル用パスワード、保存フラグ含む）がそのまま引き継がれる |
| CVE-2026-17351 | AI Assistantの読み取り専用制限の回避 | 9.0／9.4（Critical） | SQL解析ライブラリsqlparseとPostgreSQL本体の字句解析の食い違いを突き、読み取り専用トランザクションの外に複数文のSQLを通せる |
| CVE-2026-17346 | SQLインジェクション | 8.8／8.7（High） | テーブル／インデックス／パブリケーション／サブスクリプション名にアポストロフィが含まれる場合、インデックス統計ビューでSQLが差し込まれる |
| CVE-2026-17347 | OSコマンドインジェクション | 7.5／7.7（High） | MASTER_PASSWORD_HOOK使用時、OAuth/OIDCやKerberos等の外部由来のユーザー名にシェルのメタ文字が含まれると、pgAdminサービスアカウント権限でコマンドが実行される |
| CVE-2026-17348 | 認証チェックの欠落 | 6.5／6.9（Medium） | Constraints・Preferences・Debugger・Schema Diffの複数ルートが認証なしでアクセス可能だった |
| CVE-2026-17350 | ツール権限チェックの適用漏れ | 5.4／5.3（Medium） | ツールごとの権限（カスタムロール、v9.3で追加）が各ツールの「入口」ルートにしか適用されておらず、Query Tool・Grant Wizard・Schema Diffの権限を与えられていないユーザーでも、後続のルートやSocket.IOハンドラを直接呼べば機能を使えた。あわせて、他ユーザーの共有サーバへアドホック接続すると新規サーバレコードが他ユーザーのものとして保存される問題も修正された |
なぜ「修正したはずの穴」が再び開いたのか
今回の一件で実務上いちばん重いのは、個々のCVEの深刻度よりも再発のパターンです。v9.15〜v9.16で塞いだはずの箇所と同じ系統の欠陥が、別の入口から出てきています。
AI Assistantの読み取り専用制限（CVE-2026-17351）
NVDの記載では、この脆弱性はv9.16で修正されたCVE-2026-12045（AI Assistantの読み取り専用トランザクション回避）に対する修正が不十分だったことによるものと明示されています。影響範囲はv9.13以上v9.17未満です。
原因は、pgAdminがSQLの安全性チェックに使うPythonライブラリ「sqlparse」と、PostgreSQL本体とで、文字列リテラルの解釈が一致しないことにありました。standard_conforming_strings = onの条件下で、sqlparseが「まだ文字列の途中」と見なす箇所をPostgreSQLは「文字列の終わり」と解釈します。この食い違いを突くと、読み取り専用の枠の外にCOMMITを密輸できてしまう、という理屈です。入口の検査役と、実際の実行役とで、文法の読み方が違ったわけです。
アポストロフィ由来のSQLインジェクション（CVE-2026-17346）
v9.16では、16種のダイアログテンプレートでオブジェクト名にアポストロフィを埋め込まれるとSQLが実行され得る問題（CVE-2026-12044）が修正されました。今回のCVE-2026-17346は、同じ「アポストロフィがエスケープされずにテンプレートへ展開される」という欠陥が、インデックス統計ビューという別画面で残っていたものです。同種の欠陥が別の画面に散らばっており、一度の修正で拾いきれなかった構図がうかがえます。
Import/Exportからのコマンド実行（CVE-2026-17566）
Import/Export機能を経由したOSコマンド実行は、v9.15でもCVE-2026-7816として修正されています。NVDの解説はさらに前の類似案件としてCVE-2025-12762・CVE-2025-13780（リストア時のpsql経由のRCE）にも言及しており、「ユーザー入力をpsqlのコマンド文字列に組み立てる」という設計上の弱点が繰り返し問題化していることが分かります。今回の修正では、クエリ内のシングルクォート文字列にバックスラッシュが含まれていたら解釈を試みずに一律で拒否する、という踏み込んだ方針が取られました。
自社は影響を受けるか
確認すべきことは何ですか。「バージョン」「運用形態」「AI機能と外部認証の利用有無」の3点です。以下の順に確認してください。
- バージョン：v9.17より前を使っていれば対象です。pgAdminの「About」画面、またはパッケージ管理コマンドで確認できます。影響範囲はCVEごとに異なり、CVE-2026-17347はv7.2以降、CVE-2026-17349はv9.0以降と、かなり長期間さかのぼります。
- 運用形態：サーバモードで複数人が共有利用しているか。CVE-2026-17349は共有サーバへのアドホック接続、CVE-2026-17350はツールごとの権限（カスタムロール）と、いずれもサーバモード特有の機能に起因します。個人のデスクトップ利用のみなら影響は限定的です。
- AI Assistantを有効にしているか：CVE-2026-17351はAI Assistant機能が前提です。使っていなければこの1件の直接的な影響は受けません。
- 外部認証と
MASTER_PASSWORD_HOOK：OAuth/OIDCやKerberosでユーザー名を外部から受け取り、かつこのフックを設定している環境はCVE-2026-17347の条件に当たります。 - カスタムロール（ツールごとの権限）：v9.3以降でツール単位の権限を設定して利用を絞っている環境は、CVE-2026-17350によりその制限が回避され得ます。
- 公開範囲：インターネットや広い社内ネットワークから到達できる位置に置いていないか。認証欠落（CVE-2026-17348）の影響が大きく変わります。
現場目線：「対応済み」と言い切れないもどかしさ
6月にv9.16へ上げ、台帳に「対応済み」と記録した組織は少なくないはずです。それが1か月半で、同じ機能の同じ種類の穴を理由に、もう一度作業が必要になりました。脆弱性管理でいちばん厄介なのは「未対応の脆弱性」ではなく、「対応済みだと思い込んでいる脆弱性」です。前者はリストに残るので忘れませんが、後者はリストから消えているぶん、誰も見に行きません。
今回調べていて、もう一つ気になる点がありました。NVDに登録されたCVE-2026-17566の影響範囲は「9.18未満」と記載されていますが、開発元のリリースノートはv9.17で修正済みとしており、本稿執筆時点でv9.18は公開されていません。この食い違いが単なる登録上の表記の問題なのか、追加の修正が控えているのかは、公開情報からは判断できませんでした。脆弱性管理ツールがCPE（バージョン範囲の登録情報）を機械的に参照している場合、v9.17に更新済みでも警告が消えない、あるいは逆に判定がぶれる可能性があります。ツールの判定と開発元の一次情報が食い違ったときは、開発元のリリースノートを正とするのが原則です。
管理ツールは「守る側が使う道具」であるぶん、権限の強い接続情報が集まります。今回のCVE-2026-17349のように、共有サーバの機能を使っただけで他人のDBパスワードが手元に複製されるとなると、影響はSQLインジェクションのような単発の攻撃より広がりやすいものです。DBの管理端末は台数が少ないぶん後回しにされがちですが、優先度としてはむしろ上位に置くべきだと感じます。
あわせて、AI Assistantのように後から足された機能が新しい攻撃面になる流れも続いています。読み取り専用という「制限をかけたつもり」が、解析器の癖ひとつで崩れる。AIを組み込んだツールに共通する構造的な弱さとして押さえておきたいところです。
情シスはどうすべきか
まずはv9.17への更新が最優先です。そのうえで、今回のような「修正の不備」に備える運用面の見直しをおすすめします。
- 更新後に台帳を閉じきらない：同じ製品で短期間に修正が続いているときは、次のリリースまで監視対象として残す。パッチ適用だけでは終わらない事例と同様、「適用＝完了」と扱わない運用が要ります。
- 管理ツールの公開範囲を絞る：pgAdminのサーバモードを不要に広いネットワークへ露出させない。認証欠落系の脆弱性は、到達できなければ実害になりません。
- 共有サーバ機能と保存パスワードの棚卸し：CVE-2026-17349を踏まえ、共有設定でパスワードを保存している箇所を確認する。更新前に認証情報が複製された可能性がある環境では、DBパスワードの変更も検討してください。
- 使っていない機能は無効化する：AI Assistantや
MASTER_PASSWORD_HOOKなど、業務で使っていない機能を有効のままにしない。
脆弱性対応の進め方そのものを整理したい場合は、公的機関の指針が役に立ちます。IPAの中小企業の情報セキュリティ対策ガイドラインは、限られた人員での対策の優先順位づけに使えます。インシデントを想定した対応手順の確認には、IPAのセキュリティインシデント対応 机上演習教材が実践的です。ツールの更新は情シスの作業で完結しますが、DBの認証情報を扱う開発者・運用担当への周知は別途必要になります。地道な啓発の積み重ねが、こうした「作業漏れ」を減らします。
まとめ
- pgAdmin 4に7件の脆弱性（CVE-2026-17346〜17351、CVE-2026-17566）。最大CVSS 9.9で、OSコマンド実行や他ユーザーのDB認証情報の窃取に至る。修正版はv9.17（2026年7月30日公開）。
- CVE-2026-17351はv9.16の修正が不十分だったことによる再発とNVDに明記。SQLインジェクションやImport/Export経由のコマンド実行も、過去バージョンと同系統の欠陥が別の入口から再び出ている。v9.16へ更新済みの組織も対応が必要。
- 影響範囲はCVE-2026-17347がv7.2以降、CVE-2026-17349がv9.0以降と長期にわたる。サーバモードでの共有利用、AI Assistant、外部認証の利用有無で影響が変わるため、自環境の構成に照らして確認する。
