AIアプリケーション向けのオープンソースベクターデータベース「ChromaDB」の Python FastAPI 実装に、CVSS スコア 10.0（最高深刻度）の脆弱性（CVE-2026-45829）が発見された。セキュリティ企業 HiddenLayer が2月に報告したこの欠陥は、インターネットに公開されたサーバーに対して、認証なしで任意コードを実行できるという深刻なものだ。

ChromaDB とはどんなミドルウェアか

ChromaDB は、LLM（大規模言語モデル）推論の際に意味的に関連するドキュメントを高速に取得するための「ベクターデータベース」だ。RAG（Retrieval-Augmented Generation）アーキテクチャを採用するエージェント型AIアプリケーションで広く使われており、PyPI からの月間ダウンロード数は約1,400万件に達する。近年の生成AIブームを背景に、スタートアップから大企業まで多数のプロジェクトで採用が進んでいる。

脆弱性の仕組み——「認証は存在するが、場所が間違っている」

HiddenLayer の分析によれば、問題の本質は認証機能の欠如ではなく、認証チェックの実行順序が誤っている点にある。

攻撃者が細工したリクエストを送ると、ChromaDB は Hugging Face から悪意ある機械学習モデルを取得してローカルで実行する。認証チェックが走るのはその後であり、時点では手遅れだ。サーバーはリクエストを拒否して HTTP 500 を返すが、攻撃者のペイロードはすでに動いている。

HiddenLayer はこれを次のように端的に表現している。「認証は実装されているが、実行される順番が間違っている。認証が発火する頃には、モデルはすでにフェッチされ実行済みだ」

こうした「チェックより先に処理が走ってしまう」設計上の欠陥は、ミドルウェアレイヤーで発生すると被害範囲が広くなりやすく厄介だ。

影響範囲と現状

  • 対象バージョン: ChromaDB 1.0.0〜1.5.8（Python FastAPI サーバー）
  • 非対象: ローカル限定デプロイ / Rust フロントエンド使用環境
  • **インターネット公開インスタンスの約73%**が脆弱なバージョンを稼働中（Shodan 調査より）
  • バージョン 1.5.9 がリリース済みだが、本脆弱性が修正済みかどうかは執筆時点で未確認
  • HiddenLayer はメール・SNS 経由で複数回連絡を試みたが、開発者から返答なし

実務での対応ポイント

この脆弱性への対処は「ChromaDB を使っているかどうか」の確認から始まる。

即時確認すべき事項

  • 公開 API の棚卸し: ChromaDB の Python API サーバーポートがインターネットや社内 LAN に無防備に開放されていないか確認する
  • バージョン確認: pip show chromadb でバージョンを確認し、1.0.0〜1.5.8 なら対応が必要
  • Rust フロントエンドへの切り替え: 公開が必要な環境では、影響を受けない Rust 版フロントエンドへの移行を検討する
  • ネットワークレベルの遮断: ファイアウォールや NSG で ChromaDB API ポートへのアクセスを信頼できるホストのみに絞る
  • ML モデルアーティファクトの事前スキャン: trust_remote_code=True でモデルをロードすることは、未検査コードをそのまま実行するに等しい。ランタイム前のスキャンを運用フローに組み込む

クラウド上でRAGシステムを構築・運用しているチームは今すぐデプロイ構成を見直したい。開発環境でローカルにのみ起動しているケースは対象外だが、Kubernetes や Docker で外部公開している場合は要注意だ。

筆者の見解

今回の脆弱性は、AIアプリ開発の現場で見落とされがちな「インフラ層のセキュリティ」を改めて問い直すものだと感じる。

RAG 構成を組む際、エンジニアはプロンプト設計やモデル選定には細心の注意を払う。一方で、バックエンドのベクターDBが「インターネットに出てしまっている」という初歩的な構成ミスが意外と多い。ChromaDB に限らず、Qdrant や Milvus など類似ツールでも同様のリスクは存在しうる。

問題の核心が「認証の有無」ではなく「処理順序」という点は技術的に興味深い。ゼロトラスト的な考え方では「まず認証・認可を完了させてから処理する」が鉄則であり、今回の実装はその逆だった。ML モデルのロードという「取り返しのつかない副作用を持つ処理」が認証より前に走る設計は、通常の Web API では考えにくい特有の危険性だ。

開発者への連絡が数ヶ月間無視されているという状況も看過できない。月間1,400万ダウンロードを誇るパッケージで、脆弱性報告への応答体制がこの状態であることは、組織としての成熟度を問われる。OSSの採用を判断する際には、コードの品質だけでなく、メンテナのレスポンスも評価軸に加えるべきだろう。

AIアプリ開発のスピードが上がる一方で、依存するミドルウェアのセキュリティ管理が追いついていないケースが増えている。「動いているから安全」は通用しない。今回の件を機に、AI システムのサプライチェーン全体を見直す好機としたい。

出典: この記事は Max-severity flaw in ChromaDB for AI apps allows server hijacking の内容をもとに、筆者の見解を加えて独自に執筆したものです。