Claude Code流出は、単なる「話題のAIニュース」では終わりません。今回、ターミナルやIDE(統合開発環境)からコード編集、コマンド実行、検索、Git操作まで担う実運用の開発基盤の中核にあたる実装の一部が、npm配布物に含まれたソースマップ(source map)を起点に外部から参照可能な状態になっていたことがわかりました。本事件はAIエージェント時代のソフトウェアサプライチェーン問題として捉える必要があります。
流出の発端と技術的な経路(source map問題)
本事件で最初に押さえるべきなのは、「Claude本体のモデル重みが漏れた」のではなく、「Claude Codeという周辺プロダクトのソースコードが到達可能になった」という点です。事件の発端となったのは、Chaofan Shou氏(@Fried_rice)によるXの投稿です。2026年3月31日、Chaofan Shou氏は「Claude code source code has been leaked via a map file in their npm registry」(訳:Claude Codeのソースコードが、npmレジストリ内のmapファイルを通じて流出した)と投稿しており、少なくとも現時点で公開されている初動情報の起点は、この発見報告にあると考えられます。
Anthropicの公式GitHubリポジトリに2026年3月31日付で立てられたIssueでは、「source code isn’t publicly available, so this analysis is based on the leaked/decompiled Claude Code source」(訳:ソースコードは公開されていないため、本分析は流出またはデコンパイルされたClaude Codeのソースコードに基づく)と投稿され、Xでの発見報告とGitHub上の流出スナップショットを参照していたということがわかります。つまり、少なくともコミュニティ側では流出コードを参照した解析が現実に行われ、それがAnthropicの管理下のIssue空間にも持ち込まれていたということです。
Claude Codeソースコード流出事件はAI本体が破られた事件ではありませんが、AI製品はモデルだけ守ればよい、という幻想は崩されました。AIコーディング支援、AIエージェント、開発者向けCLI、IDE統合、MCP、プラグイン基盤といった要素が一体化した時代において、情報漏洩リスクはモデル重みだけでなく、配布物、周辺コード、実行制御、設定、公開ストレージにもまたがります。Claude Code流出事件を単なる興味本位の話題で終わらせるのではなく、現代のソフトウェアサプライチェーンの課題とAIプロダクト運用の脆さを示す事例として読むべきでしょう。
Google Cloud Blogで公開された「North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack」によると、2026年3月31日00:21 世界標準時(UTC)から03:20 UTCの間に、axiosのnpm公開版のうち1.14.1と0.30.4へ悪意ある依存関係が混入しました。問題の依存関係はplain-crypto-jsで、これは通常のAxios機能に必要なものではなく、postinstallフックを通じてインストール時に自動実行されるよう細工されていました。つまり、影響を受けた環境では、アプリケーションがAxiosを使ったかどうかではなく、その版をnpm installした時点で不正コード実行の可能性が生じる構造でした。
本事案を理解するうえで重要なのは、Axios本体のコード品質に起因する一般的な脆弱性とは性質が違う点です。StepSecurityの公式Blog「axios Compromised on npm – Malicious Versions Drop Remote Access Trojan」によると、攻撃者はAxiosメンテナーのnpmアカウントを侵害し、通常のGitHub Actions経由のTrusted Publisherではなく、盗まれた認証情報を使って悪性版を公開したとのことです。正規リリースではGitHub Actions由来の公開痕跡が見える一方、問題の1.14.1ではそのパターンが崩れており、さらにGitHub側に対応するコミットやタグも確認できませんでした。これは、開発者が「公式パッケージだから安全」と判断しやすい場所そのものが改ざんされたことを意味します。ソフトウェアサプライチェーン攻撃が危険視される理由はここにあります。アプリケーション開発者は通常、依存パッケージを全面的に目視監査しません。しかもAxiosは週あたり1億回規模で利用される人気ライブラリであり、上流の1パッケージが汚染されるだけで、その影響は大量の開発環境、ビルドサーバー、CIランナー、社内アプリケーションへ連鎖する可能性があります。Google Cloud Blog(前段参照)では今回の事案による影響は広範にわたる、と警告しており、単発のnpm事故では済まない可能性を示しています。
悪性版Axiosはどのように動いたのか
Google Cloud Blogによると、混入されたplain-crypto-jsは難読化されたドロッパーであり、Windows、macOS、Linuxを対象にWaveShaper.V2のバックドアを展開したとのことです。package.jsonのpostinstallによってバックグラウンドでsetup.jsが実行されるため、開発者の体感としては、ただ依存関係を導入しただけに見えます。Socket公式ブログ「Supply Chain Attack on Axios Pulls Malicious Dependency from npm」やStepSecurityブログ(前段参照)でも、plain-crypto-jsは本来のAxios機能では参照されておらず、マルウェア配布のためだけに差し込まれた依存関係だった、と整理しています。さらにStepSecuritは、当該ドロッパーがC2へ接続し、OSごとの第2段階ペイロードを取得した後、自己削除やpackage.jsonの正常化で痕跡隠蔽を試みると説明しています。ここが企業実務では特に重要です。単に「悪い版を消して入れ直せば終わり」ではなく、インストールを実行した開発端末やCI環境そのものを侵害前提で確認すべき、という判断につながるからです。
脆弱性への対策だけでなく、悪用された際に速やかに検知・対応する能力も不可欠です。IPS/IDSやエンドポイント検知(EDR)のシグネチャを最新化し、KEVに掲載された脆弱性の既知の攻撃パターンやIoC(Indicators of Compromise)を監視します。CISAやセキュリティベンダーから提供される検知ルールやYARAルールを活用し、ログ分析やトラフィック監視に組み込みましょう。また万一侵入を許した場合でも、早期にそれを発見し被害を最小化できるようインシデント対応訓練を積んでおくことも有効です。
「CWE Top 25:2025」では、もう一つ見逃せない特徴があります。それが、メモリ領域の安全性に関わる弱点が複数上位に含まれている点です。本記事では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。
はじめに:前編の振り返り(Web/API 12項目)
前編では、CWE Top 25 2025年版のうち、WebアプリケーションやAPIで特に問題になりやすい弱点をピックアップし、リスクと診断観点を整理しました。具体的には、XSSやCSRFといった入力・リクエスト起点の脆弱性に加え、「認可の欠如不備」のようにログインしていても不正操作が成立するタイプの脆弱性が、実被害につながりやすいポイントとして挙げられます。Web/APIは機能追加や仕様変更が多いため、対策しているつもりでも抜けが生まれやすく、定期的な点検が重要です。
そこで後編では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。
メモリ領域の安全に関する脆弱性が上位に増えている理由
CWE Top 25 2025年版ではメモリ安全性に関わる脆弱性が複数ランクインしている傾向もみてとれます。一見すると「これはC言語など低レベル言語の話で、Webアプリ開発とは関係が薄いのでは?」と思われるかもしれません。しかし実際には、Webサービスを提供する側にとっても無視できないテーマになっています。ここでは、2025年版で目立つメモリ系の脆弱性と、上位に増えている背景を整理します。
2025年に目立つメモリ系6項目
CWE Top 25 2025年版の中で、特にメモリ領域の安全性に関連する項目としては以下が挙げられます。
CWE Top 25 2025年版から読み取れるのは、Webアプリ・APIで頻出する脆弱性が依然として事故につながりやすい一方で、メモリ安全性のように“アプリの外側”に潜むリスクも無視できない存在になっているという点です。この2つを両立できるかどうかが、2025年のセキュリティ対策の分かれ道になると言えます。
“定期的な診断+改善”でリスクを下げる
脆弱性対策は、一度対応して終わりではなく、仕様変更・機能追加・依存資産の更新によって状況が変化します。だからこそ、CWE Top 25のような指標を参考にしながら、第三者視点の脆弱性診断で現状を確認し、優先度を付けて改善していくことが有効です。Webアプリケーション診断・API診断・ソースコード診断を組み合わせることで、「攻撃が成立するポイント」と「根本原因」を整理しやすくなり、修正の手戻りを減らしながら安全性を高められます。継続的な診断と改善を通じて、インシデントの予防と品質向上につなげていきましょう。
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.