何が起きたか
Flowise（ローコードLLMアプリケーションプラットフォーム）バージョン3.1.3までを含む、POST /api/v1/node-load-method/:nameエンドポイントをマウントしており、ルートレベルの権限チェックなしです。エンドポイントは攻撃者が制御するnodeName、loadMethod、inputs、およびcredential値を持つコンポーネント loadMethodsを呼び出します。選択されたcredentialは生のCredential.idで解決され、他の認証情報読み取りパス（ワークスペーススコープ）とは異なり、Credential.workspaceIdを呼び出し元のアクティブワークスペースに対して検証することなく復号化されます。1つのワークスペース内の認証された低権限ユーザーは別のワークスペースに属する認証情報IDを供給でき、Flowiseが混同された副官として機能し、サードパーティプロバイダーAPI呼び出し（例：Google Drive listFiles、Google Sheets listSpreadsheets、AWS DynamoDB listTables）を実行させ、被害者ワークスペースの認証情報を使用し、攻撃者にプロバイダーメタデータを返します。生の認証情報シークレット自体は返されません。
なぜ重要か
Flowiseは、マルチテナントワークスペース分離によるLLM/RAGアプリケーション構築用の広く採用されているプラットフォームです。この欠陥はその分離の境界を破り、1つのテナント内の認証されたユーザーが別のテナントの保存されたLLM/クラウドプロバイダー認証情報を使用して特権のあるサードパーティAPI呼び出しを暗黙的に呼び出すことができます — 一般的に自己ホストされているAIオーケストレーションツールでのダイレクトなクロステナント機密性侵害です。
攻撃経路
認証された低権限ユーザー（またはワークスペースAPIキー）は、別のワークスペースの認証情報IDを供給する/api/v1/node-load-method/:nameへの細工されたPOSTを送信し、サーバーがワークスペース所有権検証なしでサードパーティプロバイダー呼び出しのためにその認証情報を復号化および使用する原因となります。
影響を受けるシステム
Flowise <= 3.1.3
緩和策
Flowise 3.1.4以降にアップグレードしてください。これはノードロードメソッド認証情報解決パスにワークスペーススコープ検証を追加します。