まず全体像です。エコシステム（パッケージの配布先）別に分けると、極端に偏っています。

npmだけで93.2%。ここまで偏るのは、npmが世界最大のパッケージ登録数を持ち、誰でも即座に無審査で公開できるためです。ただし、この偏りにはもうひとつ理由があります。それは次の数字を見るとわかります。

登録された年で分けると、こうなります。

2025年だけで19万件。全体の82%です。「悪性パッケージが爆発的に増えた」という見出しは、この数字を指しています。

ところが、月単位まで分解すると、話がまったく変わります。

グラフにすれば、11月だけが天を突く棒になります。この1本を含んだまま「悪性パッケージは前年比15倍」と書けば、間違いなく読者を誤解させます。では、11月に何があったのか。

手がかりは、報告元のデータにありました。11月に登録された142,256件のうち、142,153件（99.9%）が同一の報告元——Amazon Inspector からの登録だったのです。

そしてパッケージ名を並べると、異様な光景が現れます。

調べたところ、これは「IndonesianFoods（インドネシアン・フーズ）」と呼ばれるワーム型のスパムキャンペーンでした。2024年4月にセキュリティ企業Phylumが最初に発見し、その後Sonatypeが約15,000件、SourceCodeREDが67,579件と報告を重ね、最終的にAmazon Inspectorが15万件超を特定したものです。

なぜこんなものを大量に作るのか

目的は暗号資産の報酬でした。

tea.xyz（ティー）は、オープンソースへの貢献に応じて開発者に暗号資産を配る仕組みです。パッケージに tea.yaml という設定ファイルを置いて自分のウォレットを登録しておくと、そのパッケージの「貢献度」に応じて報酬が入ります。

攻撃者はここを突きました。パッケージに仕込まれた auto.js や publishScript.js というスクリプトを実行すると、7〜10秒ごとに新しいパッケージ名を自動生成して公開し続ける無限ループが始まります。1日あたり約17,000件のペースです。互いに依存関係を張り合わせることで「たくさん使われている人気パッケージ」に見せかけ、報酬を水増ししていました。

なぜ1か月に集中したのか

ここが数字のからくりです。時系列を並べるとはっきりします。

報告元別に全体を見ると、この1回の出来事がデータベース全体を支配していることがわかります。

※ 1件が複数の報告元から登録される場合があるため、合計は100%になりません。

ここまでの話で「では脅威は誇張なのか」と思われたかもしれません。逆です。

同じデータベースを「Shai-Hulud（シャイ・フルード）」という名前で検索すると、1,185件が出てきます。全体のわずか0.50%。しかしこの0.5%こそが、npmの歴史でもっとも深刻な攻撃でした。

何をする攻撃だったのか

Shai-Huludは自己増殖する（ワーム型の）マルウェアです。動作はこうです。

4番目が決定的です。1人の開発者のトークンを盗めば、その人が管理する全パッケージが汚染される。それを入れた次の開発者からまたトークンが盗まれる。人間が操作しなくても、勝手に広がっていく設計になっていました。

実際に汚染された名前を、手元のデータから拾ってみます。

第2章で見た teagood-cuekin100 のような、誰も使わない自動生成の名前とはまったく違います。これらは実際の開発現場で使われているライブラリです。

手元のデータでも、Shai-Hulud関連の登録は2025年9月（203件）に始まり、2026年5月（498件）、2026年8月（446件）と断続的に再燃しています。終わった事件ではありません。

なお、npmを狙った攻撃は他にも起きています。週1億回ダウンロードされる axios が乗っ取られた事件については、npmサプライチェーン攻撃とは？週1億回DLのaxios乗っ取り事件を徹底解説で、攻撃の3時間を分単位で追っています。

23万件のうち、手口まで分類できたのは17,071件（全体の7.3%）にとどまります。残りは「悪意あるコードが見つかった」という記録だけで、詳細な分類がされていません。したがってこれは全体の縮図ではなく、分類できた範囲での内訳です。

件数として目立つのが依存関係混乱（Dependency Confusion）です。社内でしか使っていない company-internal-utils のような名前を、攻撃者が先回りして公開レジストリに登録しておく。すると設定によっては、社内版ではなく公開されている偽物のほうが取り込まれてしまう、という手口です。

打ち間違いで狙われているパッケージ

タイポスクワッティングの標的を集計すると、はっきりした傾向がありました。

ちなみに、第1章で見た「2番目に多い月」である2025年8月の35,472件も調べてみました。こちらの上位は @zalastax（4,135件）、test（1,952件）、project（999件）、@malware（648件）といった名前で占められています。実際の攻撃というより、研究・検証目的で登録されたものや、名前を押さえるためのプレースホルダーが大半と見られます。手口分類でも「テスト・ゴミ」が6,506件と最多でした。

ここまでの分析から、セキュリティ統計を読むときに共通して使える教訓が3つ抽出できます。これはパッケージの話に限りません。

罠1：「登録日」は「発生日」ではない

2025年11月の142,256件は、その月に作られたものではなく、その月に報告されたものでした。実際の公開は1年半にわたって続いていたものです。

脆弱性データベースでも漏えい事故のデータベースでも、同じ問題が起きます。グラフの山が「攻撃の山」なのか「報告の山」なのかを、必ず確認してください。大きな組織が一括で報告すると、その月だけが跳ね上がります。

罠2：1つの報告元が全体を左右する

このデータベースは、Amazon Inspector 1社の報告だけで64.5%を占めています。つまり「悪性パッケージの傾向」を語っているつもりで、実際にはAmazon Inspectorの検知ルールの傾向を語ってしまう危険があります。

検知する側が新しいルールを入れれば数字は増え、その分野への関心を失えば数字は減ります。数字の増減は、脅威の増減であると同時に、観測体制の増減でもあります。

罠3：件数と危険度は別の軸

第3章で見たとおりです。64.5%のゴミより、0.5%のワームのほうが桁違いに危険でした。「過去最多」という見出しは、危険が最大であることを意味しません。

データから見えた実際の脅威に対して、効果のある順に並べます。プログラミングを学び始めた方から、業務で開発している方まで対象です。

1. インストール時のスクリプト自動実行を止める（Shai-Hulud対策の本丸）

Shai-Huludは、パッケージを入れた瞬間に自動で走るスクリプトによって動きました。これを止めるだけで、多くの攻撃は無力化されます。

ただし、一部のパッケージはビルドに必要なスクリプトを持っているため、動かなくなる場合があります。まずCI/CD環境から適用するのが現実的です。

2. 打ち間違いを目視でなくコピーで防ぐ

第4章のとおり、標的はPythonの定番ライブラリです。パッケージ名は記憶で打たず、公式ドキュメントやPyPI・npmの公式ページからコピーする。これだけでタイポスクワッティングはほぼ防げます。requests と request、colorama と colourama の差は、目視では見落とします。

3. バージョンを固定する

Shai-Huludは、正規のパッケージの新しいバージョンとして汚染版を公開しました。つまり「いつも使っている安全なライブラリ」が、ある日突然汚染された版に更新される形です。

package-lock.json や requirements.txt でバージョンを固定し、更新するときは意図して更新する運用にしてください。自動で最新版を取りに行く設定は、この攻撃に対して無防備です。

4. トークンの棚卸しと有効期限の設定

盗まれたのはnpmトークン、GitHubのアクセストークン、SSH鍵、クラウドの鍵でした。無期限のトークンを発行したまま忘れていないかを確認してください。期限を切っておけば、盗まれても被害は期限までに限定されます。

5. 社内用パッケージ名を先に押さえる

依存関係混乱（6,192件）への対策です。社内でしか使わない名前でも、公開レジストリ側に同名を先回りで登録しておくか、社内レジストリを明示的に優先する設定にしておきます。

大きな数字は不安をかき立てますが、行動の指針にはなりません。23万件に怯えるかわりに、1,185件がどう動いたかを知るほうが、はるかに役に立ちます。そして、そのために必要なデータは、すべて無料で公開されています。

オープンソースそのものの脆弱性については、実際に使われているツールを題材にしたOllama に CVSS 9.1の重大脆弱性｜APIキーと会話データが盗まれる前に今すぐ確認もあわせてご覧ください。