pgvector 0.8.7で境界外書き込みを修正！索引作成権限まで点検

ベクトル検索の土台に使われるpgvectorで、IVFFlat索引を構築する際の境界外書き込みが修正されました。開発元の報告はCVE-2026-103484として、0.8.6以前が対象、0.8.7が修正版と説明しています。成立条件に「索引を作成できるデータベース利用者」が含まれる点を、インターネットからの検索要求と分けて読むことが重要です。

開発元のIssueは2026年10月1日付、PostgreSQLサイトのリリース案内は5日付です。本稿の確認日は18日です。日付が異なるのは同じ出来事を当日の速報として扱うためではありません。実際の悪用、被害数、攻撃者のAI利用は確認した資料からは判断できません。

出典：pgvector開発元：IVFFlat索引構築の脆弱性報告。

検索精度の問題ではなくデータベース内の処理の問題

開発元は、IVFFlat索引を作成する能力がある利用者によって、領域外へデータを書き込め、任意コード実行につながり得ると説明しています。これは検索結果の順位がずれるという不具合とは性質が違います。修正の優先度を、画面上の検索が正常だから低いと判断するべきではありません。

一方、RAGの利用者が質問を送るだけで、この脆弱性を直接悪用できると断定することもできません。Webの利用者、アプリケーションの接続ロール、索引を構築する管理ロールは別の主体です。外部入力がどの処理へ届くかは実装によるため、実際の接続と権限を調べる必要があります。

本稿では攻撃用のSQLや再現用データを扱いません。必要なのは、影響する拡張を使っているか、誰が索引を作れるか、修正をどこへ反映するかを整理することです。メモリの問題をアプリケーション側の文字列チェックだけで解決できるとは考えないでください。

関連する一次資料：PostgreSQL：pgvector 0.8.7の公開案内。

RAGでは文書の権限とDBの権限を別に確かめる

以下は説明用の仮想例です。社内文書を取り込むジョブが、夜間にベクトルを更新し、定期的に検索用の索引を作り直しているとします。利用者ごとの文書閲覧制限が正しくても、そのジョブが使うDB接続に広い操作権限があれば、別の管理課題が残ります。

既存のRAG権限制御とは違い、今回の焦点は索引構築を許可された実行主体です。本サイトでは、検索API、取り込み、スキーマ変更、保守作業を分けて台帳にすることを提案します。各処理で同じDBアカウントを共有しているなら、その共有が本当に必要か確認する機会になります。

ただし、権限を分けたから影響なしと即断しないでください。保守担当や自動ジョブ自身が対象の権限を持っていることがあります。更新を進めた上で、日常のアプリケーションが不要な構築操作を行えない設計へ見直す、という二つの対応として進めます。

インストールした版とデータベースの有効版を区別する

pgvectorはPostgreSQLの拡張です。運用では、ホストやコンテナーに用意した拡張のファイルと、データベースで有効になっている拡張の情報を区別して確認します。コンテナーイメージを更新したという記録だけで、接続先のすべてのDBが意図した状態になったとは判断しません。

公式READMEは、拡張のファイルを更新した後に、拡張を使うデータベースごとに更新する手順を説明しています。具体的な実行にはDBの管理者権限や環境固有の制約が関わります。マネージドサービスでは、利用可能な版と提供元の更新手順が先に確認すべき情報です。

本サイトの提案は、接続先、DB名、現在の拡張版、配布元、更新可能な版、担当者を対応付けることです。複数の顧客や用途を同じPostgreSQLへ収容している場合、代表DBだけの確認で完了にしないでください。使っていないと思っていた検証DBも、利用状況を確かめます。

読み取りだけの確認から始める

管理者が許可された接続で確認する例として、pg_extensionのextnameとextversionを参照する方法があります。対象名はvectorです。次のSQLは版の表示だけを意図したもので、修正の適用や安全性の証明は行いません。接続先を間違えないことが前提です。

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

結果がない場合は、そのDBで有効化されていない可能性がありますが、ほかのDBや別の接続先まで未使用とは言えません。また、版の文字列を確認しただけで、ロード中のライブラリや配布パッケージの状態まですべて説明できるわけではありません。保守担当の更新記録と合わせて判断します。

更新を行うSQLや再起動の必要性は、配布方法と構成に沿って検証します。本番へ接続したまま、手元の環境向けコマンドをそのまま実行することは勧めません。拡張の更新を変更管理に載せ、戻し方と停止時間を確認してから進めてください。

索引の作成経路を業務の操作までさかのぼる

権限確認では、ロールの名前が「read」「app」だから安全だと判断しません。実際に誰がテーブルを所有し、どのロールへ切り替えられ、どのジョブが索引を作成するかを調べます。DB管理者と一緒に、接続に使う資格情報から作業までつなげて確認します。

取り込み機能が利用者の要求で索引の作り直しを実行する構成なら、その要求を誰が起動できるかも点検します。直接SQLを渡していなくても、管理画面やバッチの操作権限が強いDB処理へつながることがあります。これは環境の確認事項であって、本脆弱性がすべての取り込み機能から悪用できるという意味ではありません。

不要な権限を減らす場合は、単に削除して終わらず、検索、投入、削除、保守のどの作業が影響を受けるかを確認します。権限を戻す例外には期限を付け、恒久的に管理者ロールを共有する状況を避ける方針を提案します。

更新後は索引とアプリの両方を検証する

検証用データでは、通常の検索、データ追加、更新、削除に加え、実際に使う索引の構築が完了することを確認します。クエリが成功することと、期待する索引や実行計画を使っていることは別の確認です。性能低下を脆弱性の再発と取り違えないためにも、更新前の基準を残します。

RAGを使うサービスでは、回答文だけを確認するのではなく、検索された文書、参照先、利用者ごとの範囲も確かめます。これらは本CVEの修正内容とは別のアプリケーション検証ですが、拡張更新に伴う不具合を早く見つけるために有効です。実在の機密文書を検証用に持ち出す必要はありません。

更新直後に索引を無条件で全削除して再構築することも勧めません。必要な処理は公式手順と実際の構成から決めます。大きな索引は構築時間、空き領域、ロック、同時処理に影響するため、保守作業の順序をDB管理者と確認してください。

索引の保守を代行する構成の点検例

説明用に、検索APIと夜間の索引保守が一つのDBロールを共有する構成を考えます。Web利用者へSQL入力を開放していなくても、その接続情報が漏えいした場合や、その権限で別の処理を起動できる場合に、何が可能かを評価する必要があります。本CVEでその経路の悪用が確認されたという例ではありません。

見直しでは、検索APIに必要な読み取り、取り込みに必要な更新、索引保守に必要な所有権や構築操作を分けて記述します。付与する具体的な権限はPostgreSQLのロールとオブジェクト所有関係に依存するため、単純な「書き込み禁止」一つで設計を完了させません。DB管理者が業務操作へ対応付けます。

保守用の権限を必要な時間だけ使う方法を採るなら、その有効化、利用、失効まで確認します。資格情報を変えたのに、停止中の古いジョブが次回起動時に旧設定で接続する場合も、運用の確認対象です。修正後の設計改善と、今すぐの修正版適用を同じ期限へ押し込まず、別の作業として追跡してください。

索引構築の負荷についても、普段の検索と切り分けて記録します。処理時間と空き領域の基準があれば、更新後に遅くなった場合も、DBの版、拡張、入力件数、同時処理のどこが違うかを調べられます。性能の確認を理由に危険な旧版を長期間残さないよう、検証に使う代表データと判定期限を事前に決めます。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	見落としを防ぐ条件
ホスト側	拡張の入手元とファイルの版	元と同じ導入方式で修正を反映
DB側	接続先ごとのvectorの有効版	代表DBだけで全体を完了にしない
索引保守	実行ロールと起動する経路	Web処理と保守処理の権限を区別
検索検証	代表クエリと対象のデータ範囲	回答文だけでなく検索結果を確認
提供元	修正版の提供と必要な利用者操作	クラウドという名称だけで対象外にしない

マネージド環境では提供元への質問を具体化する

クラウドのDBを使っている場合は、「pgvectorは安全ですか」という質問より、利用中の系列で0.8.7以降の修正が提供されているか、利用者が必要な操作、稼働DBごとの確認方法を尋ねます。提供元が管理する部分と自社が設定する部分を分けると、回答を作業へつなげやすくなります。

修正版の提供を待つ必要があるなら、索引構築の権限と起動経路を限定できるか確認します。ただし、その制限が脆弱性を解消したことにはなりません。利用可能日、担当、暫定措置の解除条件を残して追跡し、未確認の状態を「対象外」に置き換えないでください。

今回の対応の終点は、修正版の反映と利用主体の説明がそろうことです。AIサービスを守る際も、モデルの回答内容だけでなく、検索を支えるネイティブ拡張やDBの保守権限まで管理対象に含める必要があります。