【ITニュース解説】Pad an HTML File Past 256KB and Claude Code Desktop's Preview Could Read Your SSH Keys
2026年10月15日に「Dev.to」が公開したITニュース「Pad an HTML File Past 256KB and Claude Code Desktop's Preview Could Read Your SSH Keys」について初心者にもわかりやすく解説しています。
ITニュース概要
Claude Code DesktopのHTMLプレビュー機能に、256KB超のHTMLファイルでSSHキーなどが流出する脆弱性が見つかった。この問題は修正済み。ファイルサイズによってセキュリティ対策が変わる設計ミスが原因で、自身の開発でも同様のバグに注意が必要。アプリのバージョン確認と認証情報の更新を推奨する。
ITニュース解説
Claude Code Desktopという開発者向けのデスクトップアプリケーションのプレビュー機能において、セキュリティ上の重大な脆弱性(通称「SneakPeek」)が発見された。この脆弱性は、特定の条件下で悪意のあるHTMLファイルを開くと、ユーザーのコンピューターに保存されているSSHキー、AWS認証情報、GitHubトークンなどの機密情報が攻撃者のサーバーに送信されてしまう可能性があったというものだ。これはAnthropic社によってCVSSv4.0で8.7という高い危険度と評価され、「ホスト上でのコード実行に匹敵する影響」があるとされた。
この問題は、アプリケーションのAIモデル自体ではなく、Claude Code DesktopのHTMLプレビュー機能に存在していた。具体的には、プレビューするHTMLファイルのサイズによって、アプリケーション内部での処理方法が異なっていたことが原因である。
まず、256KB未満の比較的小さなHTMLファイルがプレビューされる場合、そのファイルはdata:URLという形式で読み込まれていた。このdata:URLで読み込まれる際には、「Content Security Policy(CSP)」というセキュリティ機能が適用され、さらに「不透明なオリジン」として扱われた。CSPは、Webページが外部から読み込むことができるスクリプトやその他のリソースの発生元を厳しく制限する仕組みであり、ここでは「スクリプトの実行を許可しない」という設定になっていた。不透明なオリジンもまた、そのコンテンツが他のウェブサイトからアクセスされるのを防ぐ役割を持つ。そのため、小さいファイルの場合、もし悪意のあるスクリプトが埋め込まれていても、これらのセキュリティ対策によって実行がブロックされていたのだ。
しかし、256KBを超える大きなHTMLファイルの場合、アプリケーションは異なる処理パスを通っていた。この場合、HTMLファイルは一時ファイルとしてユーザーのコンピューターのディスクに書き込まれ、その後file://URLという形式で読み込まれた。このfile://URLで読み込むパスでは、前述のCSPが適用されていなかったのである。Chromiumベースのブラウザ(Claude Code Desktopのプレビュー機能もChromiumの技術を利用している)では、file://オリジンで読み込まれたページは、JavaScriptのfetch()関数などを使って他のローカルファイルシステム上のファイルを読み取れる特性がある。さらに、アプリケーションにはファイルシステムへのアクセスをブロックするためのリクエストフィルターが存在していたが、これも静的なHTMLファイルをディスクから直接レンダリングする場合にはアクティブになっていなかった。
つまり、セキュリティ対策としてのCSP、不透明なオリジン、そしてリクエストフィルターは確かに存在していたが、それらはファイルサイズによって異なる「大きなファイル」を処理するパスでは適用されていなかったということになる。小さいファイルは「ガードされたドア」を通ったが、大きいファイルは「サイドエントランス」から入り、セキュリティチェックを回避してしまっていた状況であった。研究者はこの状況を「保護は実在したが、すべてのパスをカバーしていなかった」と指摘している。
この脆弱性を悪用した攻撃は、複雑な準備を必要としない。攻撃者は、悪意のあるJavaScriptスクリプトを埋め込み、かつファイルサイズが256KBを超えるようにパディング(余分なデータを加えてファイルを大きくすること)されたHTML形式の「カバレッジレポート」(ソフトウェアのテスト範囲を示す一般的なファイル)などを含むリポジトリを公開する。ユーザーがそのリポジトリをクローンし、Claude Code Desktopでそのレポートをプレビューすると、プレビューペイン内で悪意のあるスクリプトが自動的に実行される。この際、ユーザーに許可を求めるプロンプトが表示されることはなかったという。スクリプトはユーザーのコンピューターに保存されているSSHキー、AWSキー、npmやGitHubのトークン、Kubernetes認証情報、Dockerレジストリ認証、さらにはClaude自身のOAuthトークンといった機密情報を読み取り、navigator.sendBeacon()というJavaScriptの機能を使って、それらを攻撃者の指定する外部サーバーに密かに送信してしまうのだ。さらに、WebRTCという技術を通じて、ユーザーの実際のIPアドレスも取得される可能性があった。幸いにも、この脆弱性が実際に悪用されたという報告は今のところない。
この脆弱性の修正プロセスもまた、学ぶべき点がある。脆弱性が報告された後、Anthropic社は最初の修正として、file://オリジンからのfetch()やXMLHttpRequest(Webページからデータ取得を行うJavaScriptの機能)をブロックするパッチを適用した。しかし、Noma Labsの研究者はその直後に、このブロックを回避する方法を発見した。彼らは悪意のあるコードをWeb Worker(Webページとは異なるバックグラウンドでJavaScriptを実行する仕組み)内で実行させ、Web Workerをblob:URLという形式で作成することで、当初のフィルターの対象外となる新しいコンテキストを作り出したのだ。Anthropic社はこのバイパスを確認し、その後、より包括的な修正を施した。最終的な修正は、2026年8月17日にClaude Desktopのバージョン1.30096.1以降で、自動更新によってユーザーに提供された。Anthropic社はNoma Labsの報告に迅速かつ真摯に対応したと評価されている。
システムエンジニアを目指す初心者は、この事例からいくつかの重要な教訓を得られる。 まず、現在Claude Code Desktopを使用している場合は、必ずアプリケーションのバージョンを確認し、1.30096.1以降に更新されていることを確認する必要がある。もしチーム内で自動更新が無効になっているマシンがあれば、特に注意が必要だ。もし8月17日以前に、信頼できないリポジトリのHTMLファイルをプレビューした可能性がある場合は、念のため、そのマシンに保存されていた認証情報(SSHキーやAWSキーなど)を新しいものに更新(ローテーション)することが推奨される。実際に攻撃が報告されていないとしても、これはセキュリティ衛生として行うべき対策だ。
さらに重要なのは、セキュアな開発習慣を身につけることだ。開発者マシンに長期間有効な認証情報を置くのではなく、短期間だけ有効で、必要な範囲に限定された(スコープ付きの)トークンを使用することが推奨される。これにより、もし情報が漏洩したとしても、その価値は限定的になる。
そして、見慣れないリポジトリのコードを安易に実行したり、プレビューしたりする前には、常に注意深く内容を確認する習慣をつけなければならない。特にfind . -name '*.html' -size +256k -not -path '*/node_modules/*'のようなコマンドで、256KBを超える大きなHTMLファイルがプロジェクト内にないか確認し、怪しいファイルがあれば、まずは通常のテキストエディタで内容を確認するべきだ。カバレッジレポートやドキュメントが大きくなることは珍しくないが、不審なスクリプトが埋め込まれていないかを確認することが重要である。
この脆弱性は、自身のコードを開発する際にも教訓となる。「入力サイズによって処理を分岐させる」というパターンは、パフォーマンス最適化のためによく用いられるが、セキュリティチェックが一方のパスにしか適用されていない場合、それは重大な脆弱性となる可能性がある。例えば、ファイルサイズが小さい場合はインメモリで処理し、大きい場合はディスクに書き出して処理するといった分岐がある場合、どちらのパスでも同じレベルのセキュリティチェック(入力値の検証、許可されていない操作のブロックなど)が確実に行われているかを確認する必要がある。あるセキュリティ専門家は、「セキュリティ境界をサイズベースのしきい値やクライアント側のフィルターに依存するのは本質的に脆弱だ」と述べている。コードレビューの際には、処理の分岐がある場所で、「この関数のすべてのパスが、同じセキュリティチェックを通っているか?」という問いを常に投げかけるべきだ。もしその答えが入力サイズ、ファイルタイプ、またはアプリケーションのモードに依存するのであれば、セキュリティチェックは分岐の内部ではなく、分岐した後のすべてのパスで適用されるように配置し直す必要があるだろう。
このSneakPeekの事例は、システム設計において、データが「信頼できる領域」と「信頼できない領域」の境界をどこで、どのように越えるのか、そしてその越境点でどのようなガードを設けるべきかという重要な問題が、現実の開発現場でいかに重要であるかを明確に示している。