2026年2Q KEVカタログに見る攻撃トレンド ― 実際に悪用された脆弱性から読み解く攻撃者の狙い

Share
2026年2Q KEVカタログに見る攻撃トレンドアイキャッチ画像

前回記事では、2026年第2四半期(2Q)のKEVカタログを統計データから分析しました。本記事では、同期間にKEVへ追加された脆弱性のうち、実際の攻撃事例に着目。攻撃者が狙う製品の共通点や脆弱性の悪用方法を分析し、2026年2Qに見られた攻撃トレンドを読み解きます。

実際の攻撃事例から見える2026年2Qの特徴

2026年第2QにKEVへ追加された脆弱性のうち、具体的な攻撃事例が確認されているものを見ると、VPNやRMM(Remote Monitoring and Management)、メールサーバ、業務システム、開発ツールなど、さまざまな製品が攻撃対象となっています。一見すると異なる製品ですが、事例を横断すると共通点も見えてきます。特に注目したいのが、インターネットからアクセス可能なシステムや、侵害後に組織内部へのアクセスに利用できる管理系製品が狙われていることです。

攻撃者にとっては、こうした製品を侵害できれば、その先にある社内ネットワークへ侵入する足掛かりを得られます。つまり、狙われているのは単に「脆弱な製品」ではなく、侵害後の展開に利用価値の高い製品だと考えることができます。

さらに、開発環境やソフトウェアサプライチェーンを起点として、別の製品や利用者へ被害が連鎖する事例も見られました。以下では、代表的な事例から、こうした攻撃の特徴を詳しく見ていきます。

VPNや管理システムは「入口」として狙われる

象徴的な事例の一つが、Check Point Security GatewayのCVE-2026-50751です。この脆弱性は、非推奨となっているIKEv1を利用したRemote Access VPNなどに存在する認証回避の脆弱性で、攻撃者が有効なユーザーパスワードを持たなくてもVPNセッションを確立できる可能性があります。Check Pointは実際の悪用を確認しており、事例の一つには侵害後の活動にランサムウェア「Qilin」との関連性も確認されています*1

VPNは本来、社外から安全に組織内部へ接続するための仕組みです。しかし、その認証機構自体が突破されれば、攻撃者にとっては社内ネットワークへの正規の入口に近い役割を果たしてしまいます。

同様の特徴は、Oracle PeopleSoft Enterprise PeopleToolsのCVE-2026-35273にも見られます。Google Threat Intelligence GroupとMandiantは、ShinyHuntersとして知られるUNC6240による攻撃でこの脆弱性と整合する悪用を確認しています*2。活動はOracleによるアドバイザリ公開前から観測されており、ゼロデイとして悪用されていたと分析しています。

狙われるRMM・リモート管理製品の脆弱性

同様に注意したいのがRMM製品です。2026年第2Qには、ConnectWise ScreenConnectのCVE-2024-1708や、SimpleHelpの複数の脆弱性もKEVへ追加されています。

SimpleHelpでは、CVE-2024-57726CVE-2024-57728など、複数の脆弱性が確認されています。CVE-2024-57726では低権限の技術者アカウントから過剰な権限を持つAPIキーを作成して管理者権限へ昇格でき、CVE-2024-57728では管理者権限を得た攻撃者が細工したZIPファイルを利用して任意の場所へファイルを書き込み、コード実行につなげられる可能性があります。SimpleHelp自身も、これらの脆弱性を組み合わせることで、情報取得から権限昇格、最終的なコード実行までの攻撃チェーンが成立し得ると説明しています。

RMM製品は、管理者が複数の端末へ遠隔接続し、操作やソフトウェア配布などを行うための正規ツールです。そのため、攻撃者に侵害された場合、単にRMMサーバ自体が被害を受けるだけではありません。正規の管理機能が、侵入後のアクセス維持や別端末への展開に悪用される可能性があります。

これらの事例に共通するのは、侵害後に組織内部へアクセスしやすい製品が攻撃対象になっていることです。攻撃者にとって重要なのは、脆弱性そのものの深刻度だけではありません。その製品を侵害した後に「どこまでアクセスできるか」「次の攻撃へつなげられるか」という点も、標的を選ぶうえで重要な要素になっていると考えられます。Microsoftが報告したStorm-1175の活動でも、この特徴が明確に表れています。

既知の脆弱性を使い分けるランサムウェア攻撃

Storm-1175は、ランサムウェア「Medusa」を展開する金銭目的の攻撃者です。Microsoftによると、同グループはインターネット上に公開された脆弱なシステムを探索し、主に公開済みのNデイ脆弱性を悪用して初期侵入した、といいます*3。侵入後は情報窃取などを行い、数日以内、場合によっては24時間以内にランサムウェア展開まで進むことが確認されています。Storm-1175の特徴は、特定の製品や一つの脆弱性だけを狙っているわけではない点です。

Nデイ脆弱性についてはこちらの記事でも解説しています。あわせてぜひご覧ください。
定期的な脆弱性診断でシステムを守ろう!-放置された脆弱性のリスクと対処方法-

Microsoftの調査では、PaperCut、Microsoft Exchange Server、ConnectWise ScreenConnect、JetBrains TeamCity、SimpleHelp、BeyondTrustなど、複数の製品の脆弱性が初期侵入に利用されていました。2026年第2四半期にKEVへ追加された脆弱性にも、これらの活動で利用されたものが複数含まれています。侵入後には、新しい管理者アカウントを作成してアクセスを維持し、PowerShellやPsExecなどのツールを使用してネットワーク内部へ展開します。さらに、RMMツールを永続化やペイロード配布、横展開などに利用し、認証情報の窃取やセキュリティ機能の妨害を経て、最終的にMedusaランサムウェアを展開するという攻撃の流れが確認されています。

この事例から見えてくるのは、攻撃者が特定のCVEだけに固執するのではなく、外部から侵入可能な複数の脆弱性を使い分け、その時点で利用できるものを入口としているという実態です。つまり、一つの注目度の高い脆弱性だけに対応しても、別のインターネット公開システムに悪用可能な脆弱性が残っていれば、そこが新たな侵入口になる可能性があります。

開発環境も攻撃対象に ― サプライチェーン経由の侵害

もう一つ、2026年第2Qで注目したいのが、一般的なWebサーバやVPNへの脆弱性攻撃とは異なるソフトウェアサプライチェーン経由の攻撃です。CVE-2026-45321として登録されたTanStackのサプライチェーン侵害では、正規のnpmパッケージとして悪意あるバージョンが公開されました。悪意あるコードは、AWSやGCPなどのクラウド認証情報、GitHubトークン、npmトークン、SSH秘密鍵など、開発環境に保存されているさまざまな認証情報を窃取する機能を持っていました。さらに、この侵害は別の製品にも波及しました。

Nx ConsoleのCVE-2026-48027では、悪意あるバージョンのVS Code拡張機能が公開され、ディスクやメモリ上の認証情報を収集するペイロードが実行されました。Nxの調査によると、開発者の一人がTanStackに関連するサプライチェーン攻撃の影響を受け、流出したGitHub認証情報がNx Consoleの不正公開につながったとされています*4

つまり、ある開発ツールの侵害 → 認証情報の窃取 → 別プロジェクトの侵害 → 正規ソフトウェアを通じた被害拡大、という連鎖が生じたことになります。

Nx Consoleの悪意のあるバージョンは、Visual Studio Marketplaceでは約18分間公開されていました。短時間で削除されたとしても、ソフトウェアの自動更新や正規マーケットプレイスへの信頼を利用した攻撃では、その間に利用者へ影響が及ぶ可能性があります。 これは、境界機器の脆弱性を突いて社内へ侵入する攻撃とは異なります。正規の配布経路や信頼された開発者アカウントそのものが攻撃経路になるため、「正規のアップデートだから安全」という前提だけでは防ぎにくい点が特徴です。

2026年2Qの事例から見えた3つの攻撃トレンド

今回の事例を横断すると、三つの特徴が見えてきます。

第一は、攻撃者が侵害後の展開に利用しやすいシステムを入口としていることです。VPNやRMMなどは外部からアクセス可能であるだけでなく、組織内部への接続や複数端末の管理といった機能を持っています。そのため、侵害されると、その正規機能自体が次の攻撃段階へ進むための足掛かりになり得ます。第二は、攻撃者が複数の既知脆弱性を使い分けていることです。Storm-1175の事例では、PaperCut、Microsoft Exchange Server、ConnectWise ScreenConnect、JetBrains TeamCity、SimpleHelp、BeyondTrustなど、複数製品のNデイ脆弱性が初期侵入に利用されていました。重要なのは、個々の脆弱性の新旧だけではなく、攻撃者が外部から侵入可能なシステムを探し、その時点で利用可能な脆弱性を入口としている点です。第三は、攻撃対象が組織の境界から開発環境やソフトウェアサプライチェーンへも広がっていることです。TanStackとNx Consoleの事例では、一つの認証情報の侵害が別のソフトウェアへ連鎖し、正規の配布経路を通じて被害が広がるリスクが示されました。

これらに共通するのは、攻撃者にとっての「侵害後の価値」です。外部から到達できるか、高い権限や重要な認証情報を得られるか、さらに別のシステムへアクセスできるかといった条件が、攻撃対象を考えるうえで重要になっていると考えられます。

まとめ

2026年第2四半期にKEVへ追加された脆弱性の実際の悪用事例を見ると、統計データだけでは見えにくい攻撃者の行動が浮かび上がってきます。VPNやRMMなどの管理系システムを足掛かりとした侵入、既知の脆弱性を使い分けて短期間でランサムウェア展開まで進む攻撃、そして開発環境から別のソフトウェアへ被害が連鎖するサプライチェーン攻撃など、攻撃経路は多様化しています。こうした事例を見るうえで重要なのは、「どのCVEが危険なのか」だけでなく、その製品やシステムが侵害された場合、攻撃者が次に何をできるのかという視点です。実際の悪用事例と自組織のIT資産を照らし合わせ、インターネットへの公開状況や権限、他システムとの接続関係まで含めてリスクを捉えることが、攻撃の早期発見や被害拡大の防止につながります。

【参考情報】

編集責任:木下


BBSecでは

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。


サイバーインシデント緊急対応

セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    SBOMとは?ソフトウェア部品表の基本と企業が導入すべき理由

    Share
    「SBOMとは?ソフトウェア部品表の基本と企業が導入すべき理由」アイキャッチ画像

    SBOM(Software Bill of Materials)は、ソフトウェアを構成するOSSやライブラリ、依存関係を可視化する「ソフトウェア部品表」です。本記事では、SBOMの基本から注目される背景、OSS脆弱性管理やソフトウェアサプライチェーン対策との関係、企業が導入すべき理由まで分かりやすく解説します。

    はじめに

    ソフトウェアの安全性を考えるうえで、近年急速に重要性が高まっているのがSBOM(Software Bill of Materials)です。日本語では「ソフトウェア部品表」とも呼ばれ、ソフトウェアを構成するライブラリ、モジュール、依存関係、供給元などを整理して把握するための考え方として広がっています。背景にあるのは、企業システムの多くが自社開発のコードだけで成り立っているわけではなく、OSS、外部コンポーネント、パッケージ、クラウドネイティブな部品を組み合わせて構築されている現実です。そのため、どのソフトウェアに何が含まれているのか分からない状態では、脆弱性対応もソフトウェアサプライチェーン対策も後手に回りやすくなります。NIST(米国立標準技術研究所)ではSBOMについて、「ソフトウェアを構築するために使われた各種コンポーネントとサプライチェーン上の関係を記録した正式な記録」と説明しています*5

    SBOMは単なる開発者向けの技術資料ではありません。新しい脆弱性が公開されたときに、自社のどのシステムが影響を受けるのかを素早く把握するための基盤であり、調達先のソフトウェアを評価するための材料でもあり、継続的な脆弱性管理を支える台帳にもなります。NTIA(米国商務省電気通信情報局:National Telecommunications and Information Administration)は、「SBOMの最低要件が脆弱性管理、ソフトウェア在庫管理、ライセンス管理といった基本的なユースケースを可能にする」と整理しています*2。つまりSBOMは、単に「何が入っているか」を眺めるための一覧ではなく、ソフトウェアの透明性を高め、セキュリティ運用を速く正確にするための実務ツールです。

    SBOMとは

    SBOMとは、ソフトウェアを構成する部品の一覧とその部品同士の関係を示す情報のことです。食品に原材料表示があるようにソフトウェアにも、何でできているかを示す考え方が必要だという発想で語られることが多く、NISTもその比喩を用いて説明しています。SBOMに含まれる情報としては、コンポーネント名、供給元、バージョン、識別子、依存関係などが代表的です。

    ここで重要なのは、SBOMがソースコード一覧そのものではない、という点です。SBOMは完成したソフトウェアや提供される製品・サービスの中に、どのような構成要素が含まれているかを把握するためのものです。特にオープンソースソフトウェア(OSSを多用する現代の開発では、直接利用しているライブラリだけでなく、その先の依存関係まで含めて把握することが欠かせません。自社が書いていないコードであっても、最終的に自社サービスの一部として動作している以上、その脆弱性やライセンス、供給元リスクに無関心ではいられません。SBOMは、その見えにくい構成を可視化する手段です。

    なぜ今SBOMが注目されているのか

    SBOMが注目されている最大の理由は、ソフトウェアサプライチェーンの複雑化です。現在の企業システムは、内製コードだけで完結することが少なく、OSSライブラリ、サードパーティ製コンポーネント、外部サービス、コンテナイメージなどの積み重ねで成り立っています。その結果、脆弱性が発見されたときに自社に関係あるのかがすぐに分からないケースが増えています。SBOMがあれば、影響を受けるコンポーネントの有無を確認しやすくなり、初動のスピードを上げやすくなります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)もSBOMを、「ソフトウェア透明性とサプライチェーンセキュリティを支える重要な要素」として扱っています*3

    また、脆弱性対応の現実もSBOMが注目される理由の一つです。脆弱性情報は日々公開されますが、公開情報だけを見ても、自社のどのシステムにその部品が含まれているか分からなければ、対応判断が遅れます。NTIAはSBOMのユースケースとして脆弱性管理を明示しており、CISAもSBOMの実務活用をサプライチェーン防御の一部として位置付けています*4。つまりSBOMは、脆弱性情報を受け取ったあとに本当に役立つ資産側の台帳として価値を持ちます。

    SBOMで分かること

    SBOMを整備すると、まずソフトウェアに含まれるコンポーネントの全体像が見えるようになります。どのOSSライブラリが使われているか、どのバージョンか、どの供給元に由来するか、どう依存しているかが分かれば、新しい脆弱性が公表されたときの影響調査が大幅にしやすくなります。また、ライセンス確認や調達先評価、保守対象の整理にも役立ちます。NTIAは、SBOMが脆弱性、在庫、ライセンスの管理に資することを明確に示しています。

    さらにSBOMは開発部門だけでなく、運用部門、調達部門、セキュリティ部門にとっても意味があります。開発部門にとっては依存関係の可視化、運用部門にとっては影響調査の迅速化、調達部門にとってはベンダー製品の透明性確認、セキュリティ部門にとっては脆弱性管理の効率化につながります。NISTがSBOMを「サプライチェーン上の関係を含む正式な記録」として位置付けているのは、こうした部門横断の活用が前提にあるからです。

    SBOMとOSS脆弱性管理の関係

    SBOMが特に力を発揮するのは、OSS脆弱性管理の場面です。近年のソフトウェアは、多数のOSSコンポーネントに依存していますが、問題はその依存関係が深くなりやすいことです。開発者が直接追加したライブラリだけでなく、その先にぶら下がる間接依存まで含めると、構成は想像以上に複雑になります。そのためSBOMがない状態では、ある脆弱性が自社に影響するのか、どのアプリケーションに含まれているのか、を迅速に判断しにくくなります。SBOMはその複雑さを整理し、脆弱性対応の起点を作る役割を果たします。

    この点で、SBOMはSCA(Software Composition Analysis)と相性が良い考え方です。SCAはソフトウェアの依存関係を解析し、既知脆弱性やライセンス情報を確認するための仕組みですが、その結果を継続的に管理しやすくするうえでSBOMが有効です。つまりSCAが見つけるための仕組みだとすれば、SBOMは構成を記録し、影響を追いやすくするための仕組みと捉えると分かりやすいです。SBOMそのものが脆弱性を自動で直すわけではありませんが、どこに何が入っているかを把握できるだけでも、対応の速度と精度は大きく変わります。

    SBOMの代表的な形式と標準

    SBOMを実務で扱うには、機械可読な形式が重要です。NTIAの minimum elements でも、自動化を支える仕組みが重要な要件のひとつとして示されています。手書きの一覧表では更新に追いつかず、脆弱性情報との突合も難しいためです。実務で広く知られている代表的な形式としては、OWASP CycloneDX (ECMA-424)やSPDXが挙げられます。少なくともCycloneDXは、サイバーリスク低減のためのフルスタックのBill of Materials (BOM)標準として位置付けられており、現在はECMA-424として標準化されています。

    形式選定で重要なのはどちらが絶対に優れているかではなく、自社の利用目的に合っているかです。開発パイプラインに組み込みやすいか、既存ツールと連携しやすいか、脆弱性管理やライセンス管理に使いやすいか、といった観点で選ぶのが現実的です。標準形式を使うことで、ツール間連携や取引先との情報共有もしやすくなります。

    企業がSBOMを導入すべき理由

    企業がSBOMを導入すべき理由は明快です。第一に、脆弱性対応が速くなるからです。新しいCVEが出たときに、対象部品が自社のどこに入っているかを確認しやすくなれば、影響調査の時間を短縮できます。第二に、ソフトウェアサプライチェーンの透明性が高まるからです。外部から調達したソフトウェアについても、何が含まれているかが分かれば、評価や説明責任を果たしやすくなります。第三に、継続的なソフトウェア資産管理に役立つからです。NTIAもこうしたユースケースをSBOMの基本的価値として整理しています。

    加えて、SBOMはこれからの脆弱性管理の前提になりつつあります。クラウドネイティブ化や DevSecOpsが進むほど、ソフトウェア構成は動的になり、人手だけで追うのは困難になります。NISTもソフトウェアサプライチェーン対策の中でSBOMを含む各種能力の実装を推奨しており、CISAもSBOM消費の実践をサプライチェーン強化の一部として扱っています。SBOMは流行語ではなく、複雑化したソフトウェア環境を管理するための土台になりつつあると考えたほうがよいでしょう。

    SBOM導入時の課題

    もっともSBOMは作れば終わりではありません。実際の課題はどう作るかよりも、どう更新し、どう使うかにあります。ソフトウェアは日々更新されるため、一度作成したSBOMを放置するとすぐに実態とずれます。またSBOMがあっても、脆弱性情報や資産台帳、SCA、CI/CDと連携していなければ、実務で十分に生きません。CISAの近年のガイダンスもSBOMの生成だけでなく消費、つまり実際の運用への組み込みを重視しています。

    そのため導入では、まず重要システムや外部公開サービスなど、影響の大きい範囲から始めるのが現実的です。CI/CDでSBOMを自動生成する仕組みを作り、SCAや脆弱性管理フローと結び付けて、脆弱性情報公開時にすぐ影響確認できるようにする。この流れができて初めて、SBOMは単なる提出資料ではなく、日常運用で役立つ仕組みになります。

    まとめ

    SBOMとは、ソフトウェアを構成する部品とその関係を記録する「ソフトウェア部品表」です。OSS利用の拡大やソフトウェアサプライチェーンの複雑化により、どのシステムに何が含まれているのかを把握する重要性はこれまで以上に高まっています。SBOMを整備することで、脆弱性対応の初動を速め、影響調査を効率化し、ソフトウェアの透明性を高めやすくなります。NTIA、NIST、CISAがいずれもSBOMを重要視しているのは、その実務的な価値が明確だからです。特にSBOMは、SBOMとは何かを理解するだけでは不十分で、脆弱性管理、SCA、CI/CD、調達管理とどう結び付けるかが重要です。企業が導入を考える際は、形式やツール選定だけでなく、更新運用と活用場面まで見据えて設計する必要があります。これからのセキュリティ運用では、SBOMは一部の先進企業だけのものではなく、ソフトウェアを安全に使い続けるための基本装備に近づいています。

    SBOMは脆弱性対応やソフトウェアサプライチェーン対策を効率化するための重要な仕組みです。ただしSBOMを整備するだけでは十分ではなく、継続的な脆弱性管理が重要になります。企業が行うべき脆弱性管理の基本や実践フローについては、以下の記事で詳しく解説しています。
    脆弱性管理とは?企業が行うべき脆弱性管理の基本と実践手順【2026年版】


    【関連ウェビナーのご案内】
    本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理しました。次回、5月20日(水)14時からの開催のウェビナーでは、AssetViewFutureVulsのメーカーが登壇し、各領域の役割をどのように整理し、どのように連携させれば実効性ある脆弱性管理が実現できるのか、解説します。脆弱性管理の考え方について深くを理解されたい方は、ぜひご参加ください。

    その他のウェビナー開催情報はこちら


    BBSecでは

    BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

    SQAT®脆弱性診断サービス

    サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

    アタックサーフェス調査サービス

    インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

    編集責任:木下

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    Claude Code流出問題の全体像 ―事件からわかるAI開発リスクとサプライチェーンリスク―

    Share
    「Claude Code流出問題の全体像 ―事件からわかるAI開発リスクとサプライチェーンリスク―」アイキャッチ画像

    はじめに

    「Claude Code」で起きたソースコード流出問題の経緯、なぜnpm公開物から内部ソースへ到達できたのか、何が漏れ、何が漏れていないのかを整理します。またソースコード流出によって浮き彫りになるAI開発リスクとソフトウェア供給網のリスクについても解説します。

    Claude Codeソースコード流出の概要

    「Claude Code」はAnthropic社が提供する公式のコーディング支援ツールです。Anthropicが公開している「Claude Code Doc」の中でも、Claude Codeはコードベース理解、ファイル編集、コマンド実行、各種開発ツール連携を行う製品として説明されています。

    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ファイルを通じて流出した)と投稿しており、少なくとも現時点で公開されている初動情報の起点は、この発見報告にあると考えられます。

    その後に作成されたいくつかの公開GitHubリポジトリでは、漏洩経路について「npmパッケージに含まれたソースマップが、難読化前のTypeScriptソースを指しており、その参照先からsrc一式を取得できた」と説明しています。GitHubリポジトリ自体はAnthropicの公開情報ではないため、そこに書かれた全内容を鵜呑みにするべきではありませんが、少なくとも複数の公開Claude Artifacts(アーティファクト)が同じ経路を示していること、そして後述するAnthropic公式のGitHub上のIssueでも「流出またはデコンパイルされたClaude Codeのソースコード」を前提に議論が進んでいることから、ソースマップ起点として内部実装が可視化されたという大筋は相当に確度の高い情報だと言えます。さらに公開リポジトリのREADMEでは、「約1,900ファイル、51万行超のTypeScriptコードが露出した」と説明しています。

    流出した内容と影響範囲

    本事件が注目を集めた理由は、Claude Codeが単なるCLIラッパーではなく、幅広い機能群を内包したAI開発支援基盤であるためです。Anthropicの公開リポジトリと公式リリースノートを見るだけでも、Claude CodeにはIDE連携、MCP、プラグイン、履歴再開、権限管理、Web検索、各種設定や運用補助機能が継続的に追加されていることがわかります。また公開GitHubスナップショットREADMEでも、ツールシステム、コマンド群、IDEブリッジ、マルチエージェント協調、スキル、プラグイン、メモリやタスク管理など、多層的な構造が記述されています。

    つまり今回のClaude Code流出問題は、AIコーディング支援の表面だけでなく、その実装思想や運用機能の一端まで外から読める状態になったという意味を持ちます。

    何が漏れ、何が漏れていないのか

    Anthropic公式情報でも、Claude Codeの内部実装に関するソースコード断片や構成が公開状態になったことは裏づけられています。Anthropic公式GitHubのIssueでも、流出コードを前提とした解析が行われていました。

    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空間にも持ち込まれていたということです。

    一方で、複数の報道機関によれば、「Anthropicが今回の件を「人為的ミス」によるものと認め、顧客データや認証情報、Claudeモデルそのものの重みは流出していない」と説明したとしていますが、この点は一次ソースではなく報道ベースの情報として慎重に扱う必要があります。

    なぜ深刻なのか:AIエージェント時代のリスク

    それでも、このClaude Codeソースコード流出が深刻なのは、顧客データ漏洩の有無だけでは影響範囲が測れないからです。AIエージェント製品では、モデル重みそのものに価値があるのはもちろんですが、実際の使い勝手や競争力は、その周囲にあるハーネス、権限管理、ツール呼び出し、コンテキスト処理、UI、IDE統合、再開機能、運用設計によって大きく左右されます。公開スナップショットにあるディレクトリ構成やコマンド一覧、サービス層の説明を見ると、Claude Codeがかなり成熟した「製品化されたAIエージェント」であることが読み取れます。競合や研究者にとって、こうした実装知見が外から見える状態になることの意味は小さくありません。

    特に重要なのは、Claude Codeが単にコードを生成するAIだけではなく、ローカル環境や周辺ツールに触れながら作業を進めるAIエージェントとして設計されている点です。漏洩したとされる公開スナップショットにも、Bash実行、ファイル読み書き、Web取得、Web検索、MCP、LSP、タスク作成、スケジュール実行などの機能が列挙されています。これは、今後のAIセキュリティを考える際に、モデル単体の安全性だけでは足りず、エージェントの実行基盤や配布パッケージの安全性まで視野に入れなければならないことを示しています。

    AIエージェント時代の新課題、Non Human Identity(NHI)のセキュリティ課題と今後のAIコーディングに求められる実践的な視点を解説した記事はこちら。ぜひあわせてご覧ください。
    AIコーディング入門 第5回:NHI(Non‑Human Identity)とAIエージェントのセキュリティ課題

    ビルド・配布プロセスにおける問題の本質

    さらに今回の一件は、ソースコード流出そのものだけでなく、公開物のビルド管理や配布管理の問題としても重要です。ソースマップ(source map)は本来、デバッグや解析のためには有用ですが、公開パッケージに不用意に含めれば、難読化やバンドルの前提を崩し、実装内部への入口になります。もしREADME記載どおり、ソースマップが外部ストレージ上の元ソース一式を指していたのであれば、問題は単なる「mapファイル混入」で終わりません。公開パッケージ、参照先URL、ストレージ公開設定、リリース工程のチェック体制まで含めた、供給網全体の設計ミスになります。ここにClaude Codeソースコード流出問題の本質があります。

    「影響は限定的」という見方の限界

    本事件をめぐる議論では、「どうせAIのコードはすぐ変わるから被害は限定的だ」という見方もあります。これは半分正しいです。たしかにプロダクトコードは日々更新されます。それでも、ある時点の設計方針、抽象化の仕方、権限制御、内部機能のつながり、未公開機能の痕跡は、競争戦略や攻撃面の理解に十分な価値を持ちます。現に公開スナップショットには、マルチエージェント協調、チーム作成、スキル実行、メモリ同期、リモートトリガーといった、単純なCLI以上の発想が読み取れる記述が含まれています。AI開発企業にとって、こうしたプロダクト実装の漏えいは、顧客情報漏えいとは別種の経営リスクです。

    企業が取るべき対応と実務上の教訓

    企業の情報セキュリティ担当者や開発責任者にとって、本事件から学ぶべき教訓は明確です。第一に、公開パッケージの中身を「本番ビルド成果物」だけでなく、「付随ファイル」まで含めて検査する必要があります。第二に、ソースマップやデバッグアーティファクトの扱いを、開発者の善意や慣習に任せてはいけません。第三に、クラウドストレージの参照先や署名URL、生成物の格納ルールを、CI/CDと一体で見直すべきです。第四に、AIエージェント製品では、モデルAPIの保護だけでなく、CLI、IDE拡張、SDK、プラグイン、MCP連携のような周辺面を含めてセキュリティレビューをかける必要があります。Claude Codeの公式リリースノートを見るだけでも、製品は短い周期で多機能化しており、変化の速さ自体がリスク管理を難しくしています。

    もう一つ重要なのは、事故後の透明性です。現時点で確認できるAnthropic公式情報は、Claude Codeの製品説明やリリースノートが中心で、今回のソースコード流出事件についての障害報告書は見当たりません。そのため、実務的には「発生原因」「影響範囲」「再発防止策」を公式にどこまで明文化するかが、今後の信頼回復を左右します。AI安全性を強く掲げる企業であればなおさら、モデル安全だけではなく、配布と運用の安全性でも説明責任が問われます。今回のClaude Codeのソースコード流出は、その現実を突きつけた出来事となります。

    まとめ

    Claude Codeソースコード流出事件はAI本体が破られた事件ではありませんが、AI製品はモデルだけ守ればよい、という幻想は崩されました。AIコーディング支援、AIエージェント、開発者向けCLI、IDE統合、MCP、プラグイン基盤といった要素が一体化した時代において、情報漏洩リスクはモデル重みだけでなく、配布物、周辺コード、実行制御、設定、公開ストレージにもまたがります。Claude Code流出事件を単なる興味本位の話題で終わらせるのではなく、現代のソフトウェアサプライチェーンの課題とAIプロダクト運用の脆さを示す事例として読むべきでしょう。

    参考文献


    サイバーインシデント緊急対応

    セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2026年4月10日(水)14:00~15:00
    ランサムウェア時代のIT-BCP入門~サイバー攻撃によるシステム停止に備える実践的な策定ステップ~
  • 2026年4月15日(水)14:00~15:00
    AI時代のサイバー脅威最前線 ― IPA『情報セキュリティ10大脅威2026』から学ぶ防御戦略 ―
  • 2026年4月22日(水)14:00~15:00
    Swift CSCF v2026変更点解説セミナー ― Control 2.4 (Back Office Data Flow Security)の必須化とCustomer client connectorへの要件適用拡大 ―
  • 最新情報はこちら

    編集責任:木下

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像