MuseBot 2.0.0 未満、固定のセッション鍵で管理者セッションを偽造できる（CVE-2026-119660）: 2.0.0 で既定鍵を廃止、ユーザー再確認は 2.0.1

MuseBot（yincongcyincong/MuseBot、Go 製のチャットボット基盤）の 2.0.0 未満では、管理画面のセッション鍵の既定値が muse_bot_session_key に固定されており、この鍵で署名した Cookie を作ると認証なしで管理者になれる不具合（CVE-2026-119660、CWE-1394）が 10/30 に NVD へ公開されました。CVSS は v3.1 が 9.8、v4.0 が 9.3 の Critical です（どちらも CNA の値）。既定鍵の廃止は 2.0.0（10/20）に入り、Cookie のユーザーを DB で再確認する処理は 2.0.1（10/25）で入っています。

何が起きるか

• NVD の説明によると、攻撃者は固定の鍵で MuseBot-session Cookie に user_id を入れて署名し、管理者として管理画面に入れます。パスワードハッシュ、チャット記録、ボットの設定を読み取り、ボットを停止できるとされています。
• 当サイトでは、v1.0.42 の admin/conf/conf.go で session_key の既定値が muse_bot_session_key であること、admin/controller/login.go が sessions.NewCookieStore にその鍵を渡す実装であることを確認しました。Cookie の署名が正しければ、user_id の中身は検証されません。
• そのため、session_key（環境変数 SESSION_KEY）を設定せずに管理画面（既定ポート 18080）を公開している環境では、誰でも同じ鍵で Cookie を作れる状態でした。鍵を自分で設定している環境が影響を受けるかは、本記事の確認範囲では分かりません。
• 実際の悪用の報告は確認できていません。CISA の KEV には載っていません（2026.10.30 版・1766 件で確認）。当サイトでは、Cookie の偽造や管理画面へのアクセスを再現していません。

影響を受ける条件

項目	内容
対象	MuseBot 2.0.0 未満（NVD・CNA の記載。下限は未確認。確認したのは v1.0.42）
前提	セッション鍵が既定のまま。管理画面に到達できること
評価	CVSS v3.1 は 9.8（Critical、AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）、v4.0 は 9.3。値は CNA の VulnCheck が付けたもので、NVD 自身の評価ではない。NVD の状態は「Deferred」（10/30 時点）。GitHub の勧告（GHSA-77p8-2qmx-794p）も Critical・9.8 で同値
弱点の分類	CWE-1394（既定の暗号鍵の使用）
EPSS	0.52%（パーセンタイル 44.2%、10/31 時点、FIRST）
修正	2.0.0（10/20 公開、コミット 3e64518）／追加の強化は 2.0.1（10/25 公開、コミット 139f615）

修正の内容と対応

修正コミットの差分を読みました。

• 3e64518（10/19 UTC）は、session_key の既定値を空にし、空または旧既定値の場合は乱数の鍵を生成して data/admin_session_key に保存します（権限 0600）。ログには鍵を出さなくなりました。Cookie には HttpOnly と SameSite=Lax を付けています。パスワードの MD5 から bcrypt への移行も同じコミットに含まれます。compare で、この変更は v2.0.0 と v2.0.1 に含まれることを確認しました。
• 139f615（10/24 UTC）は、鍵が漏れても任意のユーザーを名乗れないよう、RequireLogin が Cookie の user_id を DB で再確認します。存在しないユーザーや削除済みユーザーは拒否します。session_secure の設定（HTTPS のみの Cookie）も追加しました。この変更は v2.0.1 に含まれ、v2.0.0 には含まれません。

対応として考えられるのは次のとおりです。

1. 2.0.1 以降に更新します。2.0.0 でも既定鍵は廃止されていますが、鍵の漏えい時の被害を抑える再確認は 2.0.1 からです。
2. 旧版で既定鍵のまま運用していた場合、同じ鍵で作られた Cookie は更新で無効になるかを含め、管理画面の操作履歴とボットの設定を確認します（本記事の推定）。パスワードハッシュが読まれた可能性があるなら、パスワードの変更も検討します。
3. 更新までの間は、管理画面の公開を止める、アクセス元を絞る、SESSION_KEY に十分に長いランダム値を設定する、といった対策が考えられます（推定で、効果は検証していません）。

未確認の点

• 悪用の報告は確認できていません。KEV にも載っていません。
• NVD の評価は未実施（状態は Deferred）で、CVSS は CNA（VulnCheck）の値です。
• 当サイトでは、Cookie の偽造と管理画面へのアクセスを再現していません。コードの確認のみです。
• 1.0.42 より前の版が対象かは確認できていません。NVD の記載は「2.0.0 未満」です。
• 実際に更新後の版で旧鍵の Cookie が拒否されることは、当サイトでは試していません。
• 日付は、NVD の公開（2026-10-30 15:16 UTC）と GitHub のコミット・リリースの記録に基づきます。