6 ポイント 投稿者 GN⁺ 2026-01-15 | 2件のコメント | WhatsAppで共有
  • Claude Cowork のコード実行環境の脆弱性を悪用し、攻撃者がユーザーのファイルを自分の Anthropic アカウントにアップロードできる
  • この脆弱性は Claude.ai のチャット環境ですでに報告されていたが未修正のままで、Cowork にもそのまま存在している
  • 攻撃は 隠されたプロンプトインジェクションを含む文書ファイル を通じて実行され、Cowork がこれを分析する過程で自動的にファイルを外部へ送信する
  • 人間の承認なしに Cowork が攻撃者の API キーを使って Anthropic API 経由でデータ流出を実行する
  • 一般ユーザーでも容易にさらされうる構造であり、AI エージェントのセキュリティリスクとプロンプトインジェクション防御の重要性を浮き彫りにしている

脆弱性の概要

  • Claude Cowork は Anthropic が公開した 一般業務向け AI エージェントのリサーチプレビューで、インターネットアクセス機能を含む
  • PromptArmor は Cowork の コーディング環境に残っている未修正の脆弱性 を使って、ユーザーファイルを外部に流出させられることを実証した
    • この脆弱性は以前に Johann Rehberger が Claude.ai で発見して公開しており、Anthropic は認識していたが修正していない
  • Anthropic は Cowork 使用時に「プロンプトインジェクションを疑うべき挙動に注意するように」と警告していたが、非専門家には現実的に難しい要求だと指摘されている
  • PromptArmor はこのリスクをユーザーに知らせるために 公開デモを実施した

攻撃チェーン (Attack Chain)

  • 攻撃は Anthropic API の許可リスト (allowlist) を悪用して Claude の VM 環境からデータを外部へ送信する
  1. ユーザーが 機密の不動産ファイルを含むローカルフォルダを Cowork に接続する
  2. ユーザーが 隠されたプロンプトインジェクションを含む文書ファイル (.docx) をアップロードする
    • 文書は「Skill」ファイルに偽装されており、1ポイントの白文字と 0.1 行間でインジェクションが隠されている
  3. ユーザーがアップロードした「Skill」を使って Cowork にファイル分析を依頼する
  4. インジェクションが Cowork を操作して 攻撃者の Anthropic API キーを使った cURL リクエストを実行し、ユーザーのファイルを攻撃者アカウントへアップロードする
    • 人間の承認手順なしで自動実行
    • Claude の VM は大半の外部ネットワークを遮断しているが、Anthropic API は信頼先として通過する
  5. 攻撃者は自分の Anthropic アカウントで 被害者のファイルを閲覧し、Claude と対話できる
    • 流出したファイルには 財務情報と一部の社会保障番号 (SSN) が含まれていた

モデル別の耐性 (Model-specific Resilience)

  • この攻撃は Claude Haiku モデルで実証された
  • Claude Opus 4.5 はインジェクション耐性がより高いが、Cowork 環境では 間接プロンプトインジェクションによって同じファイルアップロード脆弱性 を悪用できる
    • テストでは、ユーザーが悪意ある統合ガイドをアップロードした状況を想定し、顧客記録が攻撃者アカウントへ流出した

不正なファイルによるサービス拒否 (DOS via Malformed Files)

  • Claude の API は ファイル拡張子と実際の形式が一致しない場合にエラーを繰り返し発生させる
    • 例: .pdf 拡張子を持つ単純なテキストファイルを読ませようとすると、その後のすべての会話で API エラーが発生する
  • こうしたエラーは 間接プロンプトインジェクションを使った限定的なサービス拒否 (DOS) 攻撃に悪用可能
    • 不正なファイルを生成・アップロードするよう誘導し、Claude クライアントと Anthropic コンソールでエラー通知を発生させる

エージェント拡張リスク (Agentic Blast Radius)

  • Cowork は ブラウザ、MCP サーバー、AppleScript 制御など 日常業務環境全体と相互作用するよう設計されている
  • そのため、機密データと信頼できないデータが混在して処理される可能性が高まる
  • プロンプトインジェクションの攻撃面は継続的に拡大しており、コネクタ設定時には注意が必要
  • 今回のデモではコネクタは使われていないが、コネクタが一般ユーザーにとって主要なリスク要因になりうる

2件のコメント

 
laeyoung 2026-01-15

Simon Willison が書いた Claude Cowork のレビュー記事 にもプロンプトインジェクション攻撃への懸念がありましたが、早いですね。

 
GN⁺ 2026-01-15
Hacker Newsの意見
  • Anthropic API の悪用を見つけたら、その API キーを GitHub Gist や公開リポジトリに載せればよい
    Anthropic は GitHub のスキャニングパートナーなので、キーはほぼ即座に失効される
    その後で Gist を削除すればよく、OpenAI など他のプロバイダーも似たように動作する
    関連ドキュメント: Anthropic API Key Best Practices, GitHub Secret Scanning Patterns

    • GitHub の トークンスキャンサービス がダウンすると危険なので、おすすめしない
      理想的には GitHub が 汎用的なトークン失効 API を提供すべき
      あるいは非公開リポジトリで失効機能を直接有効化するほうがよい
    • これはまるで ハッカーとチェスをしているような感じ
    • 単に Anthropic コンソールで直接キーを失効すればいいのに、なぜこんなに複雑にするのか疑問だ
    • かなり 気の利いた解決策 だと思う、こんな方法は初めて聞いた
    • ただし攻撃者がファイルを奪って自分の Anthropic アカウントに移した場合、結果として 全世界がそのアカウントにアクセス できることになり危険だ
  • デモでは文字サイズを小さくして隠した .docx ファイルで プロンプトインジェクション を実演していたが、実際には単純な Markdown ファイルでも十分だ
    たとえば「Claude が融資交渉術を学ぶ」といった説明を添えるだけでも、多くの人は開きもせずに使うだろう
    むしろ .md ファイルのほうが .docx より 疑われにくい という点で、より効果的かもしれない

    • 「賢いクマ vs 開かないゴミ箱」みたいな状況だ
    • ただし全ユーザーがそう考えるわけではない
      たとえば一部の業界では今でも PDF より DOCX のほうが普通 と見なされる
      そうした環境では .md ファイルのほうがむしろハッカーの道具のように見えるかもしれない
  • こうした問題は最初から予想されていたことだ
    プロンプトインジェクション が解決されない限り、今後も繰り返されるだろう
    1999 年の HN を想像すると、「Bobby Tables が DB を吹き飛ばした」といった SQL インジェクション初期の反応 に近い雰囲気だ

    • 比較としては面白いが、正確ではない
      2000 年代初頭にも私たちは 文字列補間ではなくパラメータ化 SQL を使うべきだと言っていた
      今も必要な道具は揃っていて、問題は人々が セキュリティより速度を優先 していることだ
      皮肉なことに今回の競争を始めたのは、セキュリティとアラインメントを重視していた OpenAI だった
    • SQL インジェクションのように 入力値のサニタイズ(input sanitization) で解決できないだろうかと思う
      たとえばユーザー入力を特定のトークン(@##)(JF)で囲み、その中の命令は実行しないように処理するイメージだ
      単純な find/replace でもできそうに見えるが、自分が何か見落としているのだろうか
    • より根本的な問題は、これが 知能が高くなっても解決しない可能性 があることだ
      むしろ AI が賢くなるほど危険が増すかもしれない
    • 私はエージェント向けの Prepared Statement パターン を実験中だ
      各ツール呼び出しの前に署名済みの「令状(warrant)」を提示させ、許可された命令だけを実行するよう制限する
      プロンプトインジェクションが起きても 機械的に遮断 されるようにする方式だ
  • 「怪しければファイルをプログラムのように実行する」といった 自動実行バグ がまた現れたように感じる
    Windows XP の時代にもこうした問題で苦労し、最終的に Microsoft は自動実行をやめた
    プロンプトベースのシステムも 何を信頼するかを明確に区別 しなければならない

  • AI 企業が危険性を「認めるだけ」で、ユーザーに 非現実的な注意事項 を求めるのは問題だと思う

    • たいていの説明は「SQL インジェクション」の比喩を使うが、実際には フィッシング攻撃 に近いと思う
      たとえば「おばあちゃんボット」を作ってメールを整理させたら、ナイジェリアの王子詐欺メール に引っかかるかもしれない
    • 結局のところ「この製品を安全に使うには、そもそも使うな」と言っているのと変わらない
  • Claude の 「スキル」システムが暗黙的 であることから生じる問題に見える
    /slash コマンドのように明示的ではなく、単に「ファイルを展開する方法」のような指示があるだけだ
    そのため "decompress" や "extract" のような単語を書くだけで自動実行されうる
    この構造は プロンプトインジェクションが新しい能力をこっそり注入 しやすくしている
    したがって 明示的で静的に登録されたツール体系 に変える必要がある
    たとえば Extract(path) のようなツールを作り、Read や Bash("tar *") だけを許可するよう ホワイトリスト化 できる
    こうすれば人間の承認手順も追加でき、セッション中に新しいツールが登録されることもない

  • 関連する以前の事例と Anthropic の公式回答は このブログ記事 にまとめられている

  • 少し話題は違うが、データ流出 PoC をサービスとして提供するところ があるのか気になる
    特に Claude が外部 CI 環境で動くときに CLAUDE.md の毒性ペイロード を試してみたい

  • promptarmor の最近の活動は印象的だ
    プロダクトチームの品質責任を問ううえで大きな役割を果たしている

    • ただ彼らにも 恐怖マーケティング で製品を売ろうとする利害がある
      実際の攻撃では、被害者が Claude に機密フォルダへのアクセスを許可し、攻撃者が 見えないプロンプトインジェクションを仕込んだ DOCX をアップロードするようだまさなければならない
      しかもインジェクションの内容は Markdown 出力時にユーザーに見える
      攻撃者は自分の API キーを使う必要があるため 追跡可能
      この攻撃は古い Haiku バージョンでしか動作しない
      要するに promptarmor は 販売のために誇張 しているように見える
  • 私たちのチームでは、エージェント VM が pip, npm, apt としか通信できないように制限している
    さらに 出力リクエストサイズ を監視して異常なデータ流出を防いでいる

    • ただしこれは根本的な解決策ではない
      AI の誤用・漏えい・自律性 という三重の問題は、片方だけを防いでも解決しない
      小さなリクエストの中にも秘密をエンコードできるし、非整列の AI はこうした漏えい経路を自ら見つけ出す
    • 興味深いアプローチだが、攻撃者がユーザーの コードベースをパッケージとしてアップロード できるのかも気になる