OpenMAIC 1.0.1が4件の脆弱性を修正、未認証のモデルエンドポイントからクラウドメタデータへのアクセスが可能に

OpenMAIC 1.0.1が9月6日にリリースされ、非公開で報告された4件のセキュリティ問題が修正された。最も深刻なGHSA-9m7h-vh2h-rc3wは、1.0.0以前のバージョンに影響する。デフォルトで`ACCESS_CODE`が設定されていない場合、ミドルウェアはAPIリクエストを許可していた。また、ユーザーが独自に指定したモデルまたはメディアのエンドポイントを受け付ける5つのルートでは、`NODE_ENV=production`の場合にのみSSRF検証が実行されていた。この2つの条件が重なると、外部からのリクエストによってサーバーを`169.254.169.254`などのクラウドインスタンスメタデータサービスへ接続させ、一時的なIAM認証情報をレスポンスとして返させる可能性がある。GitHubはこの脆弱性をCriticalに分類し、CVSS 4.0スコアを9.0としている。

残る3件の脆弱性は、それぞれ異なる信頼境界に関係している。教室データの書き込み時にstage idが制限されていなかったため、想定されたディレクトリの外へアクセスできる可能性があった。永続化されるスライドのHTMLが事前にサニタイズされず、格納型XSSが成立していた。さらに、モデルプロバイダーへのリクエストがリダイレクトをたどる際、各ホップで遷移先が再検証されていなかった。修正版では、データ永続化の境界でHTMLをサニタイズし、stage idに使用できる文字を制限したほか、リダイレクトのたびに遷移先を検証し、クロスオリジンの場合には認証情報を含むヘッダーを削除する。プロジェクトにはスキャンテストも追加され、保護対象の呼び出し箇所で検証が特定の環境に限って有効になる問題の再発を防いでいる。

今回の事例がエージェントアプリケーションに示す意味は、単一の教育ツールにとどまらない。OpenMAICは文書を受け取り、スライドや動画を生成できるほか、ユーザーがOpenAI互換またはローカルのモデルエンドポイントを設定できる。このような「設定可能なバックエンド」という設計は、実質的にサーバー側のネットワーク出口を提供することに等しい。さらに、アプリケーションが開発モード、プレビューデプロイ、またはパスワード未設定の環境を信頼済みとみなしている場合、モデル機能がクラウドのコントロールプレーンにまで到達する可能性がある。

セルフホスティング利用者は1.0.1へアップグレードし、漏えいした可能性のあるクラウド認証情報をローテーションするとともに、アウトバウンドファイアウォールとIMDSの保護設定を確認すべきだ。新バージョンではNode 22.19以上が必要となる。開発環境でもloopbackアドレスやプライベートアドレスはデフォルトで拒否されるため、OllamaやLemonadeなどのローカルサービスへ接続するには、`ALLOW_LOCAL_NETWORKS=true`を明示的に設定する必要がある。この互換性変更を通常のアップグレードに伴う雑多な変更として扱うべきではない。どのプロセスがサーバーを代理して内部ネットワークへリクエストを送信できるのか、そのセキュリティ境界を改めて確認する契機とすべきである。