pgvector脆弱性2件、社内RAG基盤の点検ポイント

PostgreSQL のベクトル検索拡張「pgvector」に、2件の脆弱性が公表されました。1件目は並列 HNSW インデックス構築時のバッファオーバーフロー（CVE-2026-3172、CVSS 8.1）で、影響は 0.6.0〜0.8.1。2件目は IVFFlat インデックス構築時の整数ラップアラウンド（CVE-2026-18022、CVSS 8.8）で、0.8.6 より前が対象ですが32ビットシステムに限られます。

どちらも「一般のデータベースユーザー権限」で悪用しうる点が実務上の勘所です。そして厄介なのは、pgvector が社内の生成AI／RAG 基盤の裏側でひっそり動いていることが多く、資産管理台帳には「PostgreSQL」としか載っていないことです。

この記事でわかること：

  • pgvector とは何者で、自社のどこで動いている可能性があるか
  • 2件の脆弱性の中身と、どちらを優先して見るべきか
  • 3分で終わる「自社は該当するか」の確認手順（SQL付き）
  • AWS／Azure／Supabase などマネージドDBを使っている場合の考え方

pgvector とは何か──「うちは使っていない」は本当か

pgvector とは、PostgreSQL に「ベクトル型」と類似度検索（ベクトル検索）を追加する拡張機能です。拡張の名前は vector です。

どんな場面で使われるか：生成AI の RAG（検索拡張生成）で、社内文書を数値ベクトル（埋め込み）に変換して保存し、「質問に近い文書」を高速に取り出す用途です。社内文書検索チャットボット、FAQ 応答、問い合わせ支援などが典型で、導入するのは情シスではなく事業部門やAI推進チーム、開発ベンダーであることが少なくありません。

どこに組み込まれているか（ここが最重要）：専用のベクトルデータベース製品を新規調達せず「すでにある PostgreSQL で済ませる」のが定番の選択肢のため、次のような形で入り込んでいます。

  • Amazon Bedrock のナレッジベース（Aurora PostgreSQL）：AWS の公式手順書が、対象データベースで CREATE EXTENSION IF NOT EXISTS vector; を実行して pgvector を有効化するよう明記しています。つまり Bedrock でRAGを組んだ時点で pgvector が入ります。
  • Azure Database for PostgreSQL フレキシブルサーバー：vector 拡張が提供され、ivfflat と hnsw のアクセスメソッドが使えます。
  • Supabase：新規プロジェクトは pgvector を標準的に同梱しています。
  • 自前構築の PostgreSQL：OSS パッケージやコンテナイメージに追加インストールされている。

「ベクトルDBなんて買っていない」と即断せず、まず社内の PostgreSQL に vector 拡張が入っていないかを確認してください。確認方法は後述します。

何が起きたのか──2件の脆弱性の中身

公表されているのは次の2件です。

CVE-2026-3172 CVE-2026-18022
内容 並列 HNSW インデックス構築時のバッファオーバーフロー（整数アンダーフロー／境界外書き込み） IVFFlat インデックス構築時の整数ラップアラウンド（境界外書き込み）
影響バージョン 0.6.0 〜 0.8.1 0.8.6 より前
修正バージョン 0.8.2 以降 0.8.6（2026年7月29日リリース）
CVSS v3.1 8.1（CNA: PostgreSQL）
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H		 8.8
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
想定される影響 他のリレーション（他テーブル）の機密データ漏えい、DBサーバーのクラッシュ 境界外書き込みによる任意コード実行の可能性
前提条件 HNSW インデックスを作成／再作成できるDBユーザー 32ビットシステムのみ。IVFFlat インデックスを作成できるDBユーザー
公表 2026年2月25日（NVD） 2026年7月29日（NVD）／2026年8月21日（JVNDB）

どちらを優先して見るべきか？

実務上の優先度が高いのは CVE-2026-3172 です。CVSS スコアは 8.1 と 8.8 で 18022 のほうが高いのですが、18022 は32ビットシステム限定です。業務用のデータベースサーバーやクラウドのマネージドDBは、現在ほぼ 64 ビットで動いています。一方 CVE-2026-3172 にはビット数の限定がなく、影響バージョン帯（0.6.0〜0.8.1）が各社のマネージドDBで実際に提供されてきた版と重なります。

スコアの大小だけで優先度を決めると判断を誤る典型例です。深刻度の読み方はCVSSとは？脆弱性の深刻度を評価する仕組みと使い方も参照してください。

攻撃に必要な権限は「一般DBユーザー」──ここが勘所

両CVEとも CVSS ベクターの権限要件は PR:L、つまり管理者権限は不要です。必要なのは「ベクトルインデックスを作成できるデータベースユーザー」であること。これは RAG アプリケーションが日常的に持っている権限そのものです。

実際、AWS の Bedrock ナレッジベース構築手順では、アプリ用ロールに対象スキーマの権限をまとめて付与し（GRANT ALL ON SCHEMA ... TO ...）、そのロールで HNSW インデックスを作成する流れになっています。設計上、RAG アプリのDBアカウントは「インデックスを作れる」のが普通なのです。

したがって想定すべき脅威は、外部からの飛び込み攻撃というより次の2つです。

  • アプリのDB接続情報が漏れた／盗まれたときの被害拡大（同じDB内の他テーブルの内容が読み出される）
  • 内部者や委託先の開発者が、権限の範囲内でインデックスを作るだけで他業務のデータに手が届いてしまう

RAG 基盤は「社内文書をまとめて放り込む」性質があるため、同居しているデータの機微度が高くなりがちです。そこで他リレーションのデータが読めるという影響は、単なるクラッシュより重く受け止めるべきでしょう。

自社は影響を受けるか？──3分でできる確認手順

PostgreSQL に接続して、次の SQL を実行するだけです。

SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';

この SELECT extversion FROM pg_extension WHERE extname='vector'; は AWS の公式ドキュメントでも案内されている確認方法です。行が返らなければ pgvector は入っていません。返った場合は extversion の値を確認します。

  • 0.6.0 〜 0.8.1 → CVE-2026-3172 の影響バージョン帯。最優先で確認・更新の検討を。
  • 0.8.5 以下 → 32ビット環境で動かしているなら CVE-2026-18022 も対象。
  • 0.8.6 以降 → 両方とも修正済みのバージョンです。

psql が使えるなら \dx でも拡張の一覧とバージョンを確認できます。

ひとつ注意：extversion が実体とズレることがある

extversion はデータベースに登録されている拡張のバージョンです。OSやコンテナ側でpgvectorのバイナリを新しくしても、データベース内で ALTER EXTENSION vector UPDATE; を実行するまでは古い値のままになることがあります。逆に言えば、「サーバーは更新したから大丈夫」と思い込んでいる環境ほど、実際のデータベースでは古い定義が残っている可能性があります。現物のDBで実行して確かめてください。

マネージドDBを使っている場合はどう考えるか

クラウドのマネージド PostgreSQL では、pgvector のバージョンはクラウド側が用意した版に縛られます。公開情報から確認できる範囲では、Azure Database for PostgreSQL フレキシブルサーバーでは vector 拡張の 0.6.0／0.7.0 が一般提供されてきており、Supabase は新規プロジェクトに 0.7.0 以降を同梱しています。AWS の RDS／Aurora でも PostgreSQL のエンジンバージョンごとに同梱される pgvector の版が異なります。

これらはバージョン番号の帯としては CVE-2026-3172 の影響範囲（0.6.0〜0.8.1）と重なります。ただし、クラウド事業者が自社ビルドに修正を個別に取り込んでいる（バックポート）ことは珍しくないため、「番号が範囲内だから脆弱」と即断はできません。次の順で確認するのが確実です。

  1. 実際のDBで extversion を確認する（上記SQL）
  2. 利用しているクラウドの拡張バージョン一覧／リリースノートで、対応状況とアップグレード可能な版を確認する
  3. 更新できるなら、エンジンのマイナーバージョンアップ等で新しい pgvector に上げ、ALTER EXTENSION vector UPDATE; を実行する

すぐに上げられない場合の緩和策としては、RAG アプリ用DBユーザーのインデックス作成権限を絞る、RAG 用のデータベース／インスタンスを他業務データと分離するといった設計面の見直しが有効です。特に後者は、「他リレーションのデータが読める」という本脆弱性の影響そのものを小さくします。PostgreSQL 本体側の脆弱性対応と合わせて計画するとよいでしょう（参考：PostgreSQLに脆弱性28件、18.6などで修正）。

現場目線の課題──AI基盤は台帳に載らない

正直なところ、この手の脆弱性でいちばん苦しいのは「直せない」ことではなく、そもそも自社に存在することに気づけないことです。

生成AI の PoC は、事業部門が主導し、クラウドのマネージドサービスで数日のうちに立ち上がります。資産管理台帳に登録されるのは、良くて「Aurora PostgreSQL」まで。その中で vector 拡張が有効になっていることまでは、誰も台帳に書きません。脆弱性情報を受け取る情シス側からは、製品名で検索しても引っかからないのです。

しかも RAG 基盤は性質上、社内規程・議事録・契約書・問い合わせ履歴といった「まとめて食わせた社内文書」の集積地になります。守るべき情報の密度は高いのに、管理の網からは漏れやすい。この非対称さが、今のAI活用フェーズの一番危ういところだと感じています。

限られた人員で全PoCを追いかけるのは現実的ではありません。せめて「AI関連の案件を立ち上げるときは情シスに一報を入れる」という運用ルールと、DB拡張レベルまで見る棚卸しを、今回の件をきっかけに整えたいところです（参考：脆弱性管理とは？プロセスと情シスの進め方を解説）。

情シスはどうすべきか（公的指針の活用）

自前で長大なチェックリストを作る前に、まずは公的機関の指針を土台にするのが早道です。

  • IPA「中小企業の情報セキュリティ対策ガイドライン」：https://www.ipa.go.jp/security/guide/sme/index.html
    資産の把握とアクセス権限の整理という、今回の件の土台になる考え方がまとまっています。「何を持っているか分からない」状態を崩す出発点として使えます。
  • JVN iPedia／JVNDB：https://jvndb.jvn.jp/
    今回の pgvector のように、海外の OSS でも日本語で脆弱性情報が流れてきます。使っている OSS 名で定期的に検索する習慣をつけると、気づきの遅れを減らせます。
  • IPA「セキュリティインシデント対応 机上演習教材」：https://www.ipa.go.jp/security/sec-tools/ttx.html
    「AI基盤のDB認証情報が漏れた」というシナリオは、机上演習の題材として現実味があります。

加えて、地道ではありますが事業部門への啓発が効きます。「AIのPoCを始めるときは情シスに声をかけてほしい」と伝えるだけでも、把握できる範囲は確実に広がります。生成AI 特有のリスク全体像はOWASP LLM Top 10やRAGポイズニングとは？AIエージェントを乗っ取る攻撃も合わせてご覧ください。

まとめ

  1. pgvector に2件の脆弱性。実務上の優先は CVE-2026-3172（0.6.0〜0.8.1、修正は0.8.2以降）。CVE-2026-18022 はスコアこそ高いが32ビット環境限定で、多くの企業では優先度は下がります。
  2. 必要な権限は一般DBユーザーレベル。RAGアプリのDBアカウントが持っている権限で悪用でき、同じDB内の他テーブルのデータ漏えいにつながりえます。RAG基盤と他業務データの分離を見直す好機です。
  3. まず SELECT extversion FROM pg_extension WHERE extname='vector'; を実行する。「ベクトルDBは導入していない」と思っていても、Bedrock ナレッジベースやマネージドPostgreSQL経由で入っていることがあります。

出典

タイトルとURLをコピーしました