PraktorのTelegram添付で持続的な命令注入｜0.9.1更新とワークスペース点検

Praktor 0.9.0以前をTelegramボット経由で運用している場合は、0.9.1へ更新し、telegram.allow_fromを信頼できる利用者IDに限定してください。CVE-2026-62331は、添付文書のファイル名を細工することで、本来のuploads/ディレクトリを越え、AIエージェントが後から読む永続ワークスペース内へファイルを書き込める脆弱性です。既定例の空リストは全利用者を許可するため、ボットへメッセージを送れる外部利用者が攻撃者になり得ます。

これは単なるファイル保存先の誤りではありません。書き込み先には、Claude Codeが継続実行で参照する指示、スキル、フック、設定ファイルを置けます。攻撃者がそれらを作成または上書きすると、添付を受け取った時点ではなく、後続のエージェント実行時に不正な指示が効く「持続的な命令注入」になります。更新だけでは過去に置かれたファイルは消えないため、影響期間中に公開状態だった環境はワークスペースの点検まで必要です。

公表日と修正日は分けて確認する

日付	確認できる事実	運用上の意味
2026年6月26日	修正PRと0.9.1が公開	この版から二段階のパス検証が入った
2026年10月30日	CVE-2026-62331の公式レコードが公開	脆弱性番号、影響版、CVSSを追跡できるようになった
2026年10月31日	本記事で一次資料を再確認	0.9.1が修正版であることと設定例を確認した

GitHub Security Advisoryは深刻度High、CVSS 3.1を8.2と評価しています。ベクトルはAV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:Nです。報告者は実際のDockerデーモンを使った構成で修正前後を検証していますが、これは再現試験であり、実環境で攻撃が観測されたという意味ではありません。公開資料には現実の侵害を確認したとの記載がないため、構造化メタデータの悪用状況は「不明」とします。

影響が成立する構成

• Praktor 0.9.0以前を利用している
• Telegram連携を有効にし、外部からボットへ文書を送信できる
• telegram.allow_from: []のまま、または攻撃者のTelegram IDを許可している
• 受信した添付をエージェントの永続ワークスペースへ保存する経路を使う

公式の設定例ではallow_from: []に「空なら全員を許可」という説明があります。ボットのURLやホストのポートを直接インターネットへ公開しているかだけで判断してはいけません。Telegramからのメッセージを受け取れる時点で攻撃面が成立します。反対に、Telegram連携を使っていない環境、信頼できるIDだけを許可し攻撃者がそのアカウントを利用できない環境では、この経路の到達性は下がります。

影響範囲は「ホスト上の任意の場所へ直接書き込める」とまでは確認されていません。公式説明が示す実証範囲は、エージェントごとの永続ボリューム内、/workspace/agent以下です。ただし、その中にはCLAUDE.md、エージェント指示、スキル、フック、構成など、後続処理の判断やツール実行へ影響するファイルを置けます。コンテナ分離が残っていても、エージェントに与えたWeb、ブラウザー、MCP、リポジトリ、秘密情報の権限まで安全になるわけではありません。

添付が命令へ変わる流れ

1. 外部利用者が、パス要素を含むファイル名の文書をTelegramへ送る
2. 0.9.0以前の処理が利用者制御の名前を保存先へ連結する
3. Goのpath.Joinが親ディレクトリ要素を正規化し、保存先がuploads/の外へ移る
4. 後続のClaude Code実行が配置された指示や構成を読み、許可されたツールの範囲で行動を変える

重要なのは、外部データと実行制御の境界がファイルシステムを介して接続される点です。チャット本文に不審な指示が見えなくても、添付名が保存位置を変え、永続ファイルが将来のコンテキストになります。受信時のマルウェア検査、拡張子制限、モデル出力の監視だけでは、この保存先制御を代替できません。

0.9.1の修正は二段階

修正コミットは、Telegramの単一添付とメディアグループという二つの保存箇所で、利用者制御の名前へpath.Base()を適用します。これによりディレクトリ部分を落とし、添付名をベース名として扱います。さらにコンテナ管理側のWriteVolumeBytesでも、正規化後の保存先が/vol自身または/vol/配下に収まるかを検査し、外へ出るパスを拒否します。

入口だけの無害化と、共通書き込み関数での境界検証を組み合わせているため、将来別の呼び出し元が追加された場合にも後段の検査が働きます。0.9.1はこの修正を含む最初のリリースです。0.9.1より新しい版を選ぶ場合も、独自フォークや固定コミットでは修正コミットが含まれるかを確認してください。

更新と送信者制限を実施する

公式READMEの更新手順は、リポジトリを更新してアップグレードスクリプトを実行し、Compose構成を再起動する流れです。実行前に独自変更とバックアップ方法を確認し、保守時間内に行います。

./scripts/upgrade.sh
docker compose up -d
praktor version

次に、Telegramの許可リストへ運用担当者の数値IDだけを明示します。複数人で使う場合は個人単位で登録し、退職・異動・端末紛失時に削除できる台帳と結び付けます。

telegram:
  allow_from:
    - 123456789
    - 987654321

IDは例示値です。実際の値を確認せず転記してはいけません。空リストを「誰も許可しない」と解釈するのは逆効果です。また、許可リストは更新までの到達性を下げる回避策であり、許可済みアカウントの乗っ取りや内部利用者による細工には効きません。0.9.1への更新を省略しないでください。

既存ワークスペースを点検する

更新後は、影響版を稼働させていた期間とTelegramボットの公開範囲を整理します。公開範囲が広かった場合は、各エージェントの永続ワークスペースについて、少なくとも次を確認します。

• uploads/外で、受信時刻と近い更新日時を持つファイル
• CLAUDE.md、AGENT.md、スキル、フック、MCP設定、シェル初期化ファイルの差分
• Telegramの受信履歴と添付名、対象エージェント、保存成否
• 後続セッションで実行されたコマンド、Webアクセス、リポジトリ変更、秘密情報の利用
• ベースイメージや既知の正本から説明できない新規ファイルと権限変更

正本があるファイルはハッシュやGit差分で比較します。正本がない場合、単に内容を開いて「自然な文章だから安全」と判断せず、作成元、更新時刻、所有者、参照されたセッションを関連付けます。不審な指示ファイルが見つかったら、削除して運用を続けるだけでは不十分です。該当ワークスペースを隔離し、その後のエージェント実行を止め、許可されたツールが触れた外部サービスまで調査します。

秘密情報の漏えいは公式資料で確認されていません。一律の鍵交換を事実上の被害確認として扱うべきではありません。ただし、不審ファイルの参照後にトークン、Vault、MCP、Git、クラウドAPIへアクセスした証跡がある場合は、影響する資格情報を失効・再発行し、変更履歴を確認します。証跡が不足する環境では、鍵の利用範囲と有効期間を基準に保守的に判断します。

更新後の拒否試験

本番のボットへ危険な添付を送って検証するのではなく、テスト用ボット、テスト用Telegramアカウント、使い捨てワークスペースで確認します。未許可IDからの文書が保存処理へ進まないこと、許可IDから通常の文書を送るとuploads/配下にだけ保存されること、パス要素を含む名前がベース名へ変換されるか拒否されることを観察します。テスト後はワークスペースを破棄し、実行ログに秘密を残していないことも確認します。

さらに、複数添付と単一添付の両方を試します。修正は二つのTelegram保存箇所へ入っているためです。コンテナ管理側については、/vol外へ正規化される入力を共通関数が拒否する単体・統合テストをCIへ残すと、入口側の改修で検証が抜けても退行を検出できます。

対応の優先順位を決める

最優先は、0.9.0以前かつ空の許可リストで稼働している環境です。ボット名が公開されている、問い合わせ窓口として案内している、想定外の利用者からメッセージを受けた履歴がある場合は、Telegram連携を一時停止してから更新します。次に、許可リストは設定済みでも、登録者が多い環境や共有アカウントを含む環境を扱います。最後に、Telegram連携が無効、または信頼済みIDだけで運用し、不審な受信履歴がない環境を確認します。ただし、優先度が低いことは更新不要という意味ではありません。

資産台帳には、Praktorの版だけでなく、各エージェントのワークスペース名、Telegramボット、許可ID、利用できるMCPやブラウザー、秘密情報の注入方法を紐付けます。命令注入後の到達範囲は、脆弱性そのものより各エージェントへ与えた権限で変わるためです。読み取り専用の調査エージェントと、Gitへの書き込みやクラウド操作ができるエージェントを同じ優先度で扱うと、調査資源の配分を誤ります。

AIエージェント運用で残す三つの境界

1. 送信者境界：誰がボットへ入力できるかをIDで限定する
2. 保存境界：正規化後の実パスが許可ディレクトリ内かを共通関数で検証する
3. 実行境界：ワークスペース内の文書を読んでも、MCPやシェルの高権限操作を自動承認しない

今回の脆弱性は、外部入力をテキストとして検査するだけでは、保存先と永続性の問題を見落とすことを示します。関連する考え方は、メールを読むAIの間接プロンプトインジェクション対策で扱った外部データと命令の分離、Claudeのスキル検査で残る確認事項で扱ったスキル・MCP境界にもつながります。Praktorでは、Telegramの許可、ファイル保存、後続ツール実行を別々に制御することが実務上の要点です。