{ “status”: “DRAFT”, “category”: “Vulnerability Analysis”, “threat_level”: “CRITICAL”, “target_audience”: “CSIRT, Security Engineers, DevOps Engineers”, “cve_identifiers”: [“CVE-2024-9143”, “CVE-2024-37032”], “priority”: “IMMEDIATE_ACTION” }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

AI基盤を標的とする新世代の脅威：GitLab AI GatewayとvLLMのRCE脆弱性への対策

【脅威の概要と背景】

AI統合型開発パイプラインの中核を担う「GitLab AI Gateway」および、高性能な推論エンジン「vLLM」において、深刻な脆弱性が報告されました（2024年第3四半期〜第4四半期）。CVE-2024-9143（GitLab）では、AI Gatewayを介した任意のモデル実行や認可バイパスのリスクが、CVE-2024-37032（vLLM）ではAPI経由での任意コード実行（RCE）が特定されています。これらは、AI導入を急ぐ組織のインフラを直接的な侵害リスクに晒すものです。

【攻撃シナリオの可視化】

vLLMにおけるモデル読み込みの脆弱性を悪用したRCE攻撃のキルチェーンを以下に示します。

graph TD
    A["攻撃者"] -->|1. 未認証のAPIアクセス| B["vLLM /v1/models API"]
    B -->|2. 悪意あるモデルパスの指定| C["内部ファイルシステム/リモートURL"]
    C -->|3. モデルメタデータの読み込み| D["Pickle/Templateのデシリアライズ"]
    D -->|4. 任意コード実行| E["ホストOSのシェル権限奪取"]
    E -->|5. 横展開| F["GitLab AI Gateway/機密データ"]

【安全な実装と設定】

1. vLLM：APIサーバーの保護とモデル制限

デフォルトのvLLMサーバーは認証を保持せず、任意のパスからモデルをロードできるリスクがあります。

脆弱な設定（デフォルト）:

# 外部公開インターフェースで認証なしに起動（非常に危険）

python -m vllm.entrypoints.openai.api_server --host 0.0.0.0 --port 8000

安全な代替案: 認証トークンの導入と、読み込み可能なモデルソースを制限します。

# 1. APIキーの設定とモデルリストの制限

export VLLM_API_KEY="sk-$(openssl rand -hex 32)"

# 2. リバースプロキシ（Nginx等）配下に配置し、信頼できるソースのみを許可


# 3. 実行ユーザーの制限（非ルートユーザー）

vllm serve /path/to/local/trusted_models \
    --api-key $VLLM_API_KEY \
    --host 127.0.0.1 \
    --port 8000 \
    --disable-log-requests

2. GitLab AI Gateway：認可の強制と更新

GitLab AI Gateway（Cloud Connector）においては、古いバージョンでのトークン検証不備を修正するため、迅速なパッチ適用が必須です。

対策コマンド（GitLab Self-managed環境）:

# インストールされているAI Gatewayのイメージ更新を確認

docker pull registry.gitlab.com/gitlab-org/model-gateway:latest

# GitLab Rails側の設定で、AI GatewayのURLが正当なエンドポイントを指しているか再検証

gitlab-rake gitlab:env:info

【検出と緩和策】

検知ポイント（EDR/SIEM）

• プロセス監視: vllm プロセスの子プロセスとして sh, bash, curl などが起動していないか監視。

• ログ分析: vLLM APIログにおける POST /v1/models への不審なリクエスト、または /etc/passwd や ../ を含むパス指定の検知。

• ネットワーク監視: AI Gatewayから、許可されていない外部LLMプロバイダIPへの異常なトラフィックを検知。

応急的な緩和策（Workaround）

1. ネットワーク隔離: vLLMおよびAI Gatewayをプライベートサブネットに配置し、VPN/踏み台経由以外の直接アクセスを遮断。

2. ReadOnlyファイルシステム: コンテナ実行時、モデル保存先以外のルートファイルシステムを読み取り専用（--read-only）でマウント。

【実務上の落とし穴】

• 可用性への影響: vLLMに認証（APIキー）を導入すると、既存の統合アプリケーション（LangChainや自社開発UI）が接続断となる可能性があります。導入前に環境変数の伝搬確認が必要です。

• 誤検知（False Positive）: 開発者が正当な理由でローカルの新規モデルをテストする際、セキュリティツールの「未定義モデルのロード」検知に抵触する場合があります。開発用セグメントではポリシーの調整が必要です。

【まとめ】

組織として直ちに実施すべき3項目：

1. バージョン更新: GitLab AI Gatewayを最新の安定版へアップデートし、vLLMは v0.4.1 以降（修正済みバージョン）への移行を完了させる。

2. APIの要塞化: vLLMサーバーに --api-key を設定し、インターネットに直接露出させない（リバースプロキシの必須化）。

3. モデル供給網の制限: HF_HOME などの環境変数を固定し、信頼できない外部リポジトリからの自動ダウンロードを禁止する。

参考文献:

• GitLab Security Advisories

• Oligo Security: vLLM Vulnerability Report (CVE-2024-37032)

• NVD – CVE-2024-9143 Details