MaxKBは、ツールが有効なすべてのアシスタントにシェルツールを付与し、それに一切の制限をかけなかった

GitHub組織1Panel-devの下で公開されているオープンソースのエンタープライズアシスタントプラットフォームMaxKBは、シェル実行可能なバックエンドが渡されるたびにシェルツールを黙って追加するフレームワーク上にチャットエージェントを構築しており、MaxKBはそのツールを削除することも、その使用について誰の承認を求めることもなかった。この脆弱性はCVE-2026-77521で、GitHubアドバイザリGHSA-f36j-f34j-h3rxとして2026年9月2日に公開され、公開型または埋め込み型のアシスタントの場合についてCVSS 3.1で10.0/10と評価された。Lasso Securityは、これを発見して報告した企業で、チャットメッセージ、またはアシスタントが検索やアップロードされた文書を通じて単に取り込むテキストによって、モデルにコマンドを実行させられる可能性があることを実証した。ベアメタル展開ではホスト上で直接、公式コンテナでは研究者らがセミコロンでバイパス可能だと述べるラッパーを介して実行できる。引用された情報源の中に、この脆弱性が実際の攻撃で悪用されたことを記録したものはない。この記録自体の重大度評価、信頼度評価、情報源リストはAIインシデントアーカイブにあり、同じ開示バッチの隣接するMaxKBおよびエージェントツール関連の項目と並んでいる。

MaxKBは、検索拡張アシスタントを構築するためのセルフホスト型製品である。運用者はアシスタントを作成し、そこに機能——ツール、Model Context Protocolサーバー、スキル、サブアプリケーション——を紐づけ、アップロードした文書やクロールしたウェブサイトから構築したナレッジベースを接続し、その後、認証済みコンソール経由または公開・埋め込み可能なチャットウィジェットとしてアシスタントを公開する。その多用途性こそが攻撃面となる。勧告のトリガー条件は特殊な構成ではなく、通常の構成である。少なくとも1つの機能が紐づいたアシスタントは、そのチャットを影響を受けるエージェント経路経由でルーティングするが、機能が何も紐づいていないチャットはそうしない。Lassoの記事は、このプロジェクトを同カテゴリーでより広く採用されているものの1つと評し、MaxKBは通常マルチテナントサービスとしてデプロイされると指摘している。これは、アプリケーションユーザーとして実行されるコマンドを、テナントモデルの内側ではなく、その下に位置づけることになる。

シェルツールは製品ではなく、フレームワークとともに提供された

MaxKB はこれらのエージェントを LangChain の deepagents ライブラリで構築しており、プロジェクトの pyproject.toml では脆弱なタグと現在のタグの両方でバージョン 0.6.11 に固定されています。v2.10.3-lts タグの 467 行目の apps/application/flow/tools.py で、プロジェクトは backend を SandboxShellBackend に設定して create_deep_agent を呼び出しています。これはホスト上でコマンドを実行する MaxKB のサブクラスです。アドバイザリによると、deepagents はこの方法でシェルバックエンドが渡されるたびに、execute、ls、read_file、write_file、edit_file、glob、grep という一連のツールを自動注入します。これらは tools=list 引数の一部ではなく、この引数には運用者自身のツール、MCP ツール、スキルツールのみが含まれます。これらはインターフェースからも設定を通じても削除できません。

MaxKBもまた、除外されたツールを取り除くライブラリ引数であるexcluded_toolsを渡していない。この勧告は、対策となる場合でもなぜそれが重要かについて注意深く説明している。excluded_toolsは「モデルに伝えられる内容からツールを削除するのであって、エグゼキュータから削除するのではない」。モデルが認識していないツールと実行できないツールの区別こそが、このバグ全体を縮図にしたものである。

4つのツールを列挙しながら、4つ目を省略したゲート

同じ呼び出しにおけるヒューマン・イン・ザ・ループ制御は1行で、3つの操作を列挙しています: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}。ファイルの書き込み、ファイルの読み取り、ファイルの編集は名指しされています。コマンド実行は辞書のキーにまったく含まれていません。勧告の解釈では、これは execute に対する承認が求められていないことを意味します。3つのファイルシステム操作は名指しされ、割り込みしないよう明示的に設定されており、シェルツールはまったく名指しされていません。

まとめると、経路はこうだ。信頼できないテキストがモデルに到達し、モデルが execute を呼び出し、コマンドが実行される。勧告では、信頼できないテキストが到達する2つの方法が挙げられている。直接的な方法はチャットだ — 公開または埋め込みのウィジェット、あるいは別テナントの会話。間接的な方法は、アシスタントが取り込むコンテンツである。RAG ドキュメント、アップロードされたファイル、またはプラットフォームがナレッジベースにクロールする Web ページ。Lasso の投稿は2番目の経路を具体的に示し、「モデルの前にテキストを置ける人の集合は、モデルとチャットできる人の集合よりも大きい」と指摘している。

ベアメタルインストールでは、コマンドはただのコマンドです

MaxKB がコンテインメントに関して何を行うにせよ、それは apps/application/flow/backend/sandbox_shell.py で行われ、v2.10.3-lts ではデフォルトから始まります。9 行目は _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0))) と読み取れ、SANDBOX は apps/maxkb/conf.py の Config.defaults に現れません。明示的な MAXKB_SANDBOX 設定がなければ値はゼロで、65 行目のラッパー分岐はスキップされ、execute はホスト上で、サービスを実行しているユーザーとして、shell=True を指定した subprocess.run に直接到達します。アドバイザリの表現では、サービスが root として実行されている場合は root です。

研究者がホスト上での概念実証に用いたのは、その設定だ。彼らは MAXKB_SANDBOX を未設定のまま MaxKB の実際のコードをソースから実行し、ツールを1つアタッチしたアシスタントを作成し、1つのチャットメッセージでシステム情報コマンドの実行を依頼した。execute ツールが起動し、ホスト自身の uname、id、sw_vers の出力を内容とするファイルを書き込んだ。アドバイザリは、その出力がどのコンテナ内にも存在しないことを確認したと記している。Lasso はまた、何がそれを阻止したかの限界も記録している。露骨な名前の証明ファイルはモデルに拒否されたが、無害な運用上の言い回しは拒否されなかった。彼らの言葉を借りれば、モデルのアラインメントは「部分的なスピードバンプであり、制御ではない」。

公式イメージ上ではサンドボックスは動作したが、それでもリークが発生した

公式コンテナはベースイメージ内の installer/Dockerfile-base の48行目で MAXKB_SANDBOX=1 を設定しているため、そこではラッパーが有効です。そして、そのラッパーこそが2つ目の欠陥です。ラッパーは1つの文字列、すなわち env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so の後に gosu sandbox、さらにモデルが指定したコマンドを続けた文字列を構築し、それを root で実行されるシェルに渡していました。コマンドがテキストとして補間されていたため、その最初のトークンだけが gosu の下に置かれました。モデルの出力に含まれるセミコロン、パイプ、リダイレクト、コマンド置換はすべて、サンドボックスがそれを目にする前に、外側の root シェルによって評価されていました。

Lasso の記事は、その動作する形を示している。つまり、`env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id` というペイロードで、`ls` は閉じ込められ、`whoami` はそうではなく、その後にあるものはすべて自由に実行される。テストでは、研究者たちは、サンドボックス化された内側のコマンドがブロックされている間に、リダイレクトを使って root 所有のファイルを書き込んだ。さらに悪いことに、installer/Dockerfile にも installer/Dockerfile-base にも USER ディレクティブが含まれていないため、アプリケーションイメージは UID 0 で実行される。アドバイザリは、実行時に root であることを確認したと報告している。したがって、コンテナはそれでもコマンドを実行し、サンドボックスは、どのコマンドを低権限ユーザーに表面上帰属させるかだけを決めていた。

Lassoが説明する攻撃フロー全体は、標的へのアクセスを一切必要としない。攻撃者はWebページにコマンドを仕込み、被害者のエージェントがそれをナレッジベースにクロールして取り込むのを待ち、その後、被害者が通常の質問をする。回答は正しく正当なものとして返ってくるが、注入されたcurlはすでに攻撃者のサーバーに対して発火済みだ。このアドバイザリは、研究者らがテストしたのは自分たちのデプロイのみであり、サードパーティ製やホスト型のMaxKBインスタンスではないと注記している。

情報源が明らかにしていることと、単に測定されていないこと

メカニズム、2つのデプロイモード、クレジット、および修正版リリースは、4つの文書間で一致している。すなわち、GitHubアドバイザリ、2026年9月21日に公開されたNVDレコード、2026年9月10日のLasso自身による技術解説、および2026年9月22日のGBHackersの報道であり、これはこのCVEについて見つかった唯一の独立系メディアによる報道である。どの情報源も調査結果のいずれの部分にも異議を唱えておらず、アーカイブではこの項目は最高信頼度グレードで異議なしとして記録されている。

情報源に含まれていないのは、露出に関するいかなる指標である。MaxKBのデプロイ件数の集計も、インターネットに公開されたアシスタントや組み込みアシスタントの件数の集計も、スキャン結果も、テレメトリも、被害者として名指しされた事例もない。記録上、この欠陥が誰かに対して悪用されたことを示すものは何もなく、CISA自身の悪用評価も同じ見解である。2026年9月22日にNVDのレコードに付加されたSSVCブロックでは、悪用状況は「poc」、自動化可能は「yes」、技術的影響は「total」と評価されている。FIRSTのEPSSモデルは、2026年10月27日時点で、今後30日以内の悪用確率を1.05パーセント（64パーセンタイル）と算出しており、このCVEは2026年10月27日付のCISA Known Exploited Vulnerabilitiesカタログには掲載されていない。アーカイブ自体の評価も同じ証拠を反映しており、severity high、real harm falseである。

10.0については、その適用範囲を明記しておくべきだ。文脈から切り離して引用される可能性が最も高い数値だからである。これは公開版または組み込みアシスタントのケースに対するスコアであり、CVSSベクターはAV:N/AC:L/PR:N/UI:N/S:C、つまりネットワーク到達可能、権限不要、ユーザー操作不要で、アシスタント内のコマンドがホストオペレーティングシステムに越境するためにスコープ変更を伴う。このスコアはCNAによるものであり、ここでのCNAはGitHubのアドバイザリプログラムで、CVEレコードのソース識別子もそこを指している。NVDは同じベクターを二次指標として掲載しており、2026年10月28日時点ではこの項目を「Deferred」ステータスに分類している。これは、NVDが独自の分析ではなく、割り当て者の分析を公開したことを意味する。

パッチはアドバイザリより1か月早くリリースされていた。

時系列は公開時点から遡る形になっており、記録の中でも最も直感に反する部分である。Lassoは2026年7月8日、GitHubのアドバイザリチャネルを通じて脆弱性を非公開で報告した。MaxKBは翌日返信し、報告の対象を公式イメージに限定したうえで、コンテナでの実証コード（PoC）を求めた。研究者らは7月10日にそれとサンドボックス回避を提供した。修正コミット594f50f2は7月9日、つまり報告の翌日に取り込まれ、sandbox_shell.pyを書き換えた。これにより、モデルのコマンド文字列がまず解析され、gosuプレフィックスは最初の単純コマンドだけでなくすべての単純コマンドに適用され、各引数リストが再クォートされて置換が親シェルに抜け出せないようになった。Lassoの解説では、この変更はgosuプレフィックスを「最初のコマンドだけでなく、すべての単純コマンド」に適用するものだと説明されている。

これを含むリリース v2.10.5-lts は、2026年8月6日に公開された。GitHub のアドバイザリは9月2日に掲載され、NVD は9月21日に CVE を公開し、CISA の SSVC ブロックが追加されて GBHackers が報じたのは9月22日、そして Lasso 自身の記事は9月10日に登場した——その一連の流れの途中であり、最初ではなかった。アドバイザリのフィードではなくリリースタグを追っていた運用者なら、警告が出るおよそ4週間前にパッチを入手していたことになる。

バージョン境界は、アドバイザリが示している以上に注意を払う価値がある。主要な情報源である2つが食い違っており、リポジトリがその問題に決着をつけるからだ。アドバイザリのフォーム欄には影響を受けるバージョンが「<= 2.10.3-lts」と記録され、これは2.10.3-ltsで確認済みであり、脆弱な経路はこの方法でエージェントをビルドするすべてのバージョンに「おそらく」影響するとの注記が付いている。Lasso自身の解説では、影響範囲は「<= 2.10.4-lts」とされている。タグはより広い範囲を裏付けている。2026年7月16日にリリースされたv2.10.4-ltsは、v2.10.3-ltsと同じ75行のsandbox_shell.pyを搭載しており、書き換えられた311行のファイルはv2.10.5-ltsで初めて登場する。2.10.4-ltsを使う運用担当者がアドバイザリの範囲だけを読めば、自分たちは範囲外だと結論づけたはずだ。しかし実際には範囲内だった。

その修正が行わなかったこと

2.10.5-lts が修正するのはラッパーである。ラッパーはもはや root の下で単一のシェル文字列を構築しない。一方で、ツールについては何も行っていない。2026年10月22日に公開されたタグ v2.10.8-lts のリポジトリを直接読むと、エージェントは依然として backend=SandboxShellBackend で構築されており、interrupt_on は依然として正確に3つのキー — write_file、read_file、edit_file — を持ち、execute はない。勧告の最初の2つの修復提案、すなわちデフォルトで非実行バックエンド上に構築することと、承認マップに "execute": True を追加することは、そのリリースには存在しない。

フェイルクローズドの推奨は、後の v2.10.7-lts で反映され、最も不利な状況にあったデプロイメントモードにとって重要です。2026年10月15日に公開され、sandbox_shell.py の行を CONFIG.get("SANDBOX", 0) から CONFIG.get("SANDBOX", 1) に変更します。変数を設定したことのないソースインストールまたはベアメタルインストールでは、ラッパーがデフォルトでオフではなくオンになる。これが狭義の「非コンテナデプロイではフェイルクローズドする」推奨です。この勧告は同じ見出しの下でそれ以上のことを求めていました。すなわち、サンドボックスランタイムが利用できない場合に実行機能を持つフローが起動を拒否することであり、別途、ラッパーが root シェル向けのコマンド文字列を一切構築しないことも求めていました。コンテナ側については、推奨ではなく事実です。v2.10.8-lts タグでは installer/Dockerfile も installer/Dockerfile-base も USER ディレクティブを含んでいないため、アプリケーションイメージは依然として root で起動します。

併せて読むと、2026年10月28日時点の記録上の状況は次のとおりです。脆弱性の後半部分——セミコロンが抜け出したサンドボックス——は塞がれ、ホスト展開におけるフェイルオープンのデフォルトも塞がれています。前半部分、すなわちバックエンドオブジェクトとともに渡され、承認マップのキーになっていない実行ツールが、依然としてMaxKBのツール対応アシスタント構築方法です。研究者自身の修復アドバイスは限定的なものでした。2.10.5-lts以降にアップグレードし、Docker版をサンドボックスを有効にして実行することです。GBHackersは同じ指示に加え、管理者向けのより広範なリストを伝えました——コード実行が明示的に必要でない限りシェル対応のエージェントバックエンドを無効化する、あらゆる実行アクションの前に人間の承認を必須にする、コンテナを非rootで実行する、クロールしたページ、RAGドキュメント、アップロードを信頼できない入力として扱う、ということです。

同じ9月バッチのもう1件のMaxKBレコード

このバッチにおけるアーカイブの2件目のMaxKBエントリは、結末がより悪い別のバグです。CVE-2026-77516も2026年9月21日にNVDへ公開されており、これはコマンドインジェクションではなく権限バイパスです。バージョン2.0.0から2.9.2まで、最低ロールのワークスペースメンバーが、WorkspaceUserResourcePermissionを通じて明示的にツールへのアクセスを拒否されていても、tool_ids、skill_tool_ids、またはmcp_tool_idsを通じてそのツールの識別子をバインドし、エージェントまたはワークフローのディスパッチ経路を通じて実行できました。ディスパッチ経路は、専用のツールルートが強制するツール単位の許可を再適用せず、ツール実行時にはサーバー側のinit_paramsが復号されるため、呼び出し元は拒否されたツールが保持する認証情報を受け取ります。そのスコアは5.4で、NVDの説明は、CVE-2026-77521には必要のない一文で締めくくられています。「このレビュー時点で修正版はありません。」

この対比は、この2件をトリアージする誰にとっても役立つ部分だ。10.0のスコアだった脆弱性は、1日以内に修正がコミットされ、公開の1か月前にリリースされていた。5.4のスコアだった脆弱性は、CVEの時点で修正版が公開されていなかった。

真に未解決のままなのは、スコアが示唆するよりも小さく、パッチノートが含意するよりも大きい。この指摘に異論はなく、その仕組みは発見したチームによって両方のデプロイメントモードでエンドツーエンドに検証された。露出は完全に未測定である——MaxKBアシスタントのうち何件がツールを搭載しているか、そのうち何件が信頼できない当事者から到達可能か、何件がサンドボックスなしのホストで動作しているかを公表した者は誰もいない——したがってこの欠陥の実世界での影響は、引用されたどの情報源も数えていないデプロイ習慣の関数である。そして、スコアを最大値に押し上げた設計上の部分は現在のリリースにも依然として存在する。すなわち、コマンドを実行する機能がデフォルトで付属しているにもかかわらず、まず人間に確認を求める一覧には載っていない。