CVE-2026-115477 in obsidian-tc
要約
〜によって VulDB • 2026年10月23日
obsidian-tcは、ObsidianのVault向けのガバナンス対応・エージェント準備完了型Model Context Protocolサーバーです。バージョン1.13.0から1.31.4にかけて、`auth.jwtSecret`が設定されたStreamable HTTPデプロイメント環境において、2026-07-28年代のクライアントが `elicitation.form` サポートを宣言している場合、ディスパッチゲート付きツール呼び出しで提供される `inputRequired` 確認は、ユーザーが拒否またはキャンセルした場合、あるいはelicitation応答が省略されたか不正な形式であった場合でも、クライアントが再送信時に有効にバインドされた `requestState` をエコーすることで完了できました。サーバーは、その状態が `elicitation/create` フェーズの前に生成され、単に再送信が同じ呼び出しに属していることを証明するものに過ぎないにもかかわらず、認証済みで呼び出しに束縛された状態を承認の証拠として信頼しました。したがって、不正な動作をするクライアントまたは攻撃者の制御下にあるクライアントは、通常のツール権限を保持したまま、ユーザーの承認なしにディスパッチゲート付きの破壊的なVault操作を実行できました。このバイパスを通じて到達可能だったのは、`destructive: true` マークが付けられているか、人間介入（human-in-the-loop）要件を持つスコープを必要とするツールのみでした。 `write_note` の上書きや `move_note` を含む16のハンドラー側条件付きゲート付きツールは、最新の通信プロトコル上でelicitation状態を読み取らず、承認も拒否もそのパスを通じて許可しませんでした。stdioを使用するか `auth.jwtSecret` が未設定である影響を受けたデプロイメントでは、代わりにCLIの `elicit_token` フォールバックが使用され、この `requestState` の往復は提供されていませんでした。修正版は、悪意のあるクライアントが偽造された承認を報告することを防止するものではなく（サーバー側でフォームが表示されたか、人間が目にしたかを検証できないため）、バージョン1.31.4で本問題は修正されています。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.