npm 148パッケージがサイト訪問者のブラウザをDDoSボット化｜JFrog発見の新型サプライチェーン攻撃

npmを通じて配布された148個のパッケージが、開発者ではなくサイト訪問者のブラウザを分散型サービス妨害（DDoS）ボットに変えていた——。2026年7月、JFrogのセキュリティリサーチチームが公表した新型のサプライチェーン攻撃「Lucide Proxy」は、これまでの常識を一つ覆した。従来のnpm汚染はCI/CDや開発者端末から認証情報を盗むものだったが、本件はレジストリを「無料の攻撃ホスティング」として悪用し、罠サイトを開いた一般ブラウザの回線帯域を攻撃トラフィックとして供出させる。

被害トラフィックを出すのはビルドサーバーでもエンジニアのPCでもない。学校のWebフィルタを回避しようと悪性プロキシへアクセスした学生のブラウザだ。本記事では、JFrogの一次調査をもとに「何が起きたのか」「なぜ新しいのか」「自分のシステムでどう確認するか」「どう防ぐか」を、攻撃コードの詳細を書かない防御目線で整理する。前提として、本記事の数値・固有名詞・時系列はすべてJFrogの公式リサーチに準拠し、確定できない被害規模は「推測」と明示して事実と切り分ける。攻撃を再現する手順やペイロードは一切載せない。読者が持ち帰るべきは、自分の依存・配信・ネットワークを点検するための具体的なチェックリストである。

この記事は、当サイトのサプライチェーン防御ピラーサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストの実例編にあたる。基礎の防御フレームはそちらを先に読むと本記事の対策が立体的に理解できる。

30秒で分かるポイント

まず全体像を1枚に凝縮した。数字とタイムラインはすべてJFrogの一次調査に一致させている。

何が起きたのか：Lucide Proxyキャンペーンの時系列

JFrogは、npmレジストリ上に公開された148個のパッケージが、表向きは学生向けのWebプロキシとして機能する一方で、裏では訪問者のブラウザをDDoSボットに変えていたと報告した。パッケージは「Lucide」というプロキシアプリを同梱し、Riverbend TutoringやNorthstar Tutoringといった架空の家庭教師サービスのランディングページに偽装されていた。表面上はWebフィルタをすり抜けてゲームやブロックされたサイトへ到達できるため、フィルタ回避を求める学生が自らアクセスし、結果として攻撃トラフィックを供給する構図になっていた。

なぜ標的が「学生」なのかにも設計の合理性がある。学校のネットワークはWebフィルタで多くのサイトを遮断するため、生徒はゲームやSNSに到達するためのプロキシを日常的に探している。攻撃者はこの需要に「本当に動くプロキシ」を無料で供給することで、疑われずに大量のブラウザを長時間滞在させることに成功した。被害者は騙されているという自覚がないどころか、「便利なツールを使えている」と感じている。この利用者の自発的アクセスに支えられたボットネットという点が、マルウェアを踏ませる従来型と根本的に異なる。感染させる手間も、持続化の細工も要らない。ユーザーが自分の意思でタブを開き続けてくれる。

重要なのは、これらのパッケージが人気ライブラリのタイポスクワットではないという点だ。攻撃者は著名人名やスラング混じりの独立した名前（例：miguelphonk、lucide-proxy 系）でパッケージを公開し、npmを「配布経路」ではなく罠サイトを無料でホスティングする土台として使った。つまり、開発者がうっかり依存に取り込むことを狙ったのではなく、レジストリの信頼性とCDN配信の便利さそのものを踏み台にしている。

この「無料ホスティングとしての悪用」がなぜ厄介かというと、npmレジストリとjsDelivrのようなCDNは、いずれも世界中どこからでも高速に、無審査に近い形でコードを配れるインフラだからだ。攻撃者は自前でサーバーを借りてドメインを取り、可用性を維持する手間を負わない。パッケージを1つnpm publishすれば、jsDelivrが自動でCDNキャッシュに載せ、世界中の訪問者へ低遅延で配ってくれる。しかも取り下げられても別アカウントで即座に再公開できる——第2波が示した通りだ。正規のエコシステムが持つ信頼性・可用性・到達性が、そのまま攻撃者の武器に転用されている。

収益構造も見ておく価値がある。このオペレーションはポップアンダー広告のアドウェアで日銭を稼ぎつつ、必要なときだけDDoS能力を差し込む兼業型だった。3月から純粋なアドウェアとして運用実績を積み、フィルタ回避を求める学生のトラフィックを集めた上で、5月中旬にDDoSモジュールを2日間の集中作業で追加し、5月末に実弾を撃ち、報道が始まると即座に取り下げてアドウェアへ戻した。この「普段は無害に見えるサービスとして母数を確保し、有事に一斉武装する」パターンは、休眠中のボットネットとして極めて発見されにくい。

JFrogはインフラの追跡から、lucideproxyという名のGitHub組織（複数アカウントが数分以内に相次いで作成）、コミットメールのgeeked[.]wtfドメイン、Discordハンドルへと辿り着いた。判明した93のデプロイ用ホスト名のうち90が単一のIPアドレス92.38.177[.]17（G-Core Labs、AS199524）に解決したという。攻撃者は使い捨てのプロキシサイトを大量に量産し、そのすべてを一つの配信元に束ねていた。

・加害と被害の主体がずれている：攻撃を仕掛けたのはlucideproxy、実際にパケットを撃ったのは学生のブラウザ、標的にされたのは無関係な看護学校だった
・DDoSは約2週間だけ稼働：5月中旬に武装し、5月末に実弾を撃ち、報道で即座に取り下げた。短期集中で足がつきにくい設計
・アドウェア収益との二重構造：ポップアンダー広告で日銭を稼ぎつつ、必要なときだけDDoS能力を差し込む「兼業」型のオペレーションだった

従来のサプライチェーン攻撃と何が違うのか（novelな点）

「npmの悪性パッケージ」と聞くと、多くの開発者はまず認証情報の窃取を思い浮かべる。実際、当サイトでも扱ってきたMastra npmサプライチェーン攻撃、Nx Console汚染事件、TanStackを襲ったMini Shai-Huludワームは、いずれもpostinstallスクリプトや乗っ取ったメンテナ権限を使い、開発者端末やCI/CDパイプラインからAPIキー・クラウド資格情報・ソースコードを盗み出すものだった。攻撃対象は「そのパッケージをインストールした人」であり、被害は「盗まれること」に集約される。

Lucide Proxyはこの構図を反転させる。狙われるのはパッケージをインストールした開発者ではなく、罠サイトを開いた一般ブラウザ。奪われるのは資格情報ではなく、回線帯域と計算資源だ。npmは感染の運び手ですらなく、単に攻撃者が無料でコードを配って回るための倉庫として使われている。下図に両者の違いを整理した。

この反転が守り手にとって難しいのは、既存のサプライチェーン防御の多くが「依存ツリー」を前提に組まれているからだ。SCA（ソフトウェア構成分析）ツール、lockファイル監査、postinstallスクリプトの検査、C2通信先のブロックリスト——これらはすべて「自分がインストールするパッケージ」を検査対象にしている。しかしLucide Proxyでは、被害者は何もインストールしていない。ただブラウザで罠サイトを開いただけだ。開発者のマシンには痕跡が残らず、CI/CDのログにも現れない。監視すべき地点が「ビルドパイプライン」から「配信されるフロントエンド」と「エンドユーザのブラウザ」へ移っているのに、多くの組織の計測はそこに置かれていない。この盲点こそが、本件を単なる「また1件のnpm汚染」で片付けられない理由だ。

攻撃の仕組み：ブラウザがDDoSボットになるまで

JFrogの解析によれば、悪性の中核は2つのモジュールに分かれる。一つはリモートスクリプトローダー、もう一つはWisp対応のWebSocketフラッド生成器だ。ここでは攻撃を再現できる具体コードは示さず、防御に必要な「動作の骨格」だけを追う。

(1) 差し替え自在のリモートローダー。プロキシサイトは、jsDelivr CDN経由で特定のGitHubリポジトリからJavaScriptを読み込む。参照先が固定コミットではなく可変の@mainブランチである点、そしてSubresource Integrity（SRI）ハッシュが無い点が要だ。SRIが無ければブラウザは取得したコードの同一性を検証しないため、GitHubアカウントの保持者は、全訪問者のブラウザ上で実行されるコードをいつでも書き換えられる。しかもそのコードはプロキシサイト自身のオリジン権限（Cookie・localStorage・同一オリジンのエンドポイントへのフルアクセス）で動く。

(2) Wisp WebSocketフラッド生成器。ローダーが引き込む攻撃モジュールは、websocket.txtというプレーンテキストを取得し、そこに書かれた標的のWebSocket URLとソケット数（1〜1,024で上限管理）を読み取る。Wispは多数のTCP/UDPソケットを単一のWebSocket上でトンネルするプロトコルで、これを悪用して各接続が100ミリ秒ごとに「CONNECTフレーム→即CLOSEフレーム」の対を送りつける。狙われるのはユーザーのローカルマシンではなく、websocket.txtが指すリモートの標的サーバーだ。

補足として、なぜ「Wisp」なのかを押さえておくと防御の勘所が見える。Wispは本来、1本のWebSocketの上で多数のTCP/UDPソケットを多重化してトンネルするための正当なプロキシプロトコルだ。ブラウザという「アウトバウンド接続しか許されない・生ソケットを開けない」制約の強い環境から、大量の接続イベントを効率よく吐き出すのに都合がよい。攻撃者は標的が本物のトラフィックか判別しにくいプロトコル層を選ぶことで、単純なIP遮断やレート制限をすり抜けやすくしている。ブラウザはOSレベルの生パケットを撃てない代わりに、WebSocketの確立・切断を高速に反復することで実質的なフラッドを作り出す——これが「ブラウザDDoS」の技術的な核心だ。

SRIが無いことの意味も強調しておきたい。通常、外部スクリプトを読む<script>タグにintegrity属性（SRIハッシュ）を付ければ、ブラウザは取得したファイルのハッシュを照合し、1バイトでも異なれば実行を拒否する。Lucide ProxyはこのSRIをあえて付けず、かつ固定コミットではなく@mainブランチを指すことで、「配信されるコードは可変で、検証もされない」状態を意図的に作った。結果として、攻撃者はパッケージを更新する必要すらなく、GitHubの1コミットだけで、既に世界中に展開済みの全プロキシサイトの挙動を書き換えられる。npmの取り下げ（unpublish）が効きにくいのはこのためだ。

JFrogの見積もりでは、稼働中のブラウザ1台あたり毎秒約2メガバイトの生アップロードトラフィックを生成し、1,000人の訪問者が同時にいれば合算で毎秒約2ギガバイトの攻撃帯域になる。ボットネットの規模は、攻撃者がどれだけ多くの学生を罠サイトへ誘い込めるかにそのまま比例する。数千のプロキシサイトを量産し、それぞれに常時数十〜数百の学生が滞在すれば、単一の看護学校のような小規模エンドポイントを飽和させるには十分な火力になる。

・同一オリジン権限が怖い：読み込まれたコードはサイトのCookie・localStorageに触れる。DDoSに留まらず、セッション情報の悪用や追加ペイロード投下にも転用し得る
・取り下げても骨格は残る：DDoSモジュールを外した後も、アプリは難読化されたまま外部の第三者スクリプトを読み続ける。配信経路が可変である限り、再武装は設定変更に近い手軽さ
・標的は無関係な第三者：撃たれたのは看護学校のエンドポイント（cdn.caan.edu）や別のプロキシサービス（lunaron[.]topのWispエンドポイント）で、学生も看護学校も互いに無関係だった

自分のシステムで確認する4つのコマンド

ここからは実務だ。以下はすべて読み取り専用の点検コマンドで、攻撃を実行するものではない。自分のリポジトリ・ビルド成果物・配信サイトに、本件の痕跡や同種の脆弱パターンが無いかを洗い出す。

① 依存マニフェストを棚卸しする。まずプロジェクト内のpackage-lock.jsonを全て列挙し、どこにどんな依存ツリーが存在するかを把握する。

# node_modules を除外して lockファイルを一覧化
find . -path ./node_modules -prune -o -name 'package-lock.json' -print
# pnpm / yarn / bun を使う場合はそれぞれのロックも
find . -path ./node_modules -prune -o \( -name 'pnpm-lock.yaml' -o -name 'yarn.lock' -o -name 'bun.lock' \) -print

② インストール済みツリーからIoCパッケージ名を探す。JFrogが挙げた名前は使い捨てで変わり得るため、名前一致は「あれば黒、無くても白ではない」補助的な確認と位置づける。

# 既知の悪性名パターンを依存ツリーから検索（該当があれば要調査）
npm ls --all 2>/dev/null | grep -iE 'lucide-proxy|riverbend|northstar|miguelphonk'

③ ビルド成果物から「可変CDN参照」を炙り出す。本件の本質はパッケージ名ではなく、@mainのような可変参照からSRIなしで外部JSを読み込む構造にある。配信中のバンドルやHTMLを調べる。

# dist/build 配下で jsDelivr の @main 参照や IoC ドメインを検索
grep -riE 'jsdelivr\.net/gh/[^"]+@(main|master)|woofbeginner|vipersfutbol|breadarchive' dist/ build/ public/ 2>/dev/null

④ 自社サイトのCSPヘッダを確認する。強力なContent Security Policy（後述）は、リモートローダーの読込とWebSocketフラッドの両方を遮断する最後の砦だ。まず現状のヘッダを見る。

# 配信中サイトの CSP を確認（空なら未設定＝要導入）
curl -sI https://your-site.example | grep -i -E 'content-security-policy'

4つのコマンドの読み方を補足する。①はあくまで棚卸しで、これ自体は白黒を付けない——「どこに依存ツリーがあるか」の地図作りだ。②で名前一致が出れば要調査だが、出なくても安全とは言えない（攻撃者は名前を使い捨てる）。本当に効くのは③で、パッケージ名ではなく構造を見る点にある。jsdelivr.net/gh/<誰か>/<何か>@main のような可変参照をSRIなしで読み込む箇所があれば、それが本件でなくとも同じ穴だ。④のCSP確認は、出力が空（＝ヘッダ未設定）なら最優先で導入対象になる。特にService Workerは要注意で、一度登録されると取り下げ後も古いコードをキャッシュから実行し続けるため、navigator.serviceWorker.getRegistrations()で登録状況を確認し、不要なものはunregister()で必ず解除する。ブラウザのDevTools（Application → Service Workers / Storage）からも手動で消去できる。

なお、これらは「自分が加害側に取り込まれていないか」の点検である点を強調しておきたい。本件の被害の多くは、悪性プロキシを開いた個々のブラウザ利用者に生じる。したがって組織としては、自社が配信するページの健全性（③④）と、配下ネットワークから外部への異常なWebSocket/HTTPフラッドが出ていないか（出口監視）の両輪で見るのが正しい。開発者個人のlockファイル監査（①②）だけに閉じないことが肝心だ。

対策：npmサプライチェーン攻撃を緊急・推奨・長期で断つ

防御は3層で考える。「いま火を消す」緊急対応、「再発を防ぐ」推奨運用、「同種の攻撃面を構造的に封じる」長期施策だ。ここで意識したいのは、本件の対策は役割によって重心が違うという点だ。開発者は依存の検疫（推奨）に、Webサイト運営者は配信の制御（長期のCSP/SRI）に、ネットワーク管理者は出口監視と遮断（緊急）に、それぞれ主眼を置くことになる。どれか1層だけでは穴が残る。以下は立場を横断した総覧として読み、自分の担当領域に対応する項目を最優先で着手してほしい。

緊急（今日中）

・該当パッケージ・フィルタ回避系プロキシを社内資産と配信成果物から排除する
・影響ブラウザでキャッシュ・localStorageを消去し、Service Workerを登録解除する
・IoCドメイン（woofbeginner[.]com / c.vipersfutbol[.]com / cdn.caan.edu / wisp.breadarchive.dpdns.org）をDNS・プロキシで遮断する
・アナリティクスID（G-0VL3ZSBXDH）やIP（92.38.177[.]17）を検知ルールに追加する

推奨（今週中）

・npm ci --ignore-scripts を採用し、インストール時の任意スクリプト実行を止める。lockファイルは必ずコミットして固定する
・npm audit を定期実行し、Socket.dev や Aikido Safe Chain で公開直後のパッケージを検疫する（悪性版は公開から短時間で仕込まれるため、minimumReleaseAge＝リリース直後のバージョンを避ける設定が有効）
・依存自動更新（Renovate / Dependabot）に検疫ルールを組み込み、無審査の自動マージを止める
・CIでビルド成果物をスキャンし、@main のような可変CDN参照を検出したら失敗させる

長期（構造対応）

・自社が配信するWebサイトに Content Security Policy を導入する。script-src を自己ホスト＋許可済みドメインに限定し、connect-src で許可外のWebSocket/フェッチ先を遮断すれば、リモートローダーもWispフラッドも発火しない
・外部スクリプトを読む場合は Subresource Integrity（SRI） を必須化し、@main のような可変参照を禁止して固定コミットハッシュに統一する
・SBOM（ソフトウェア部品表）を生成し、依存の来歴を継続的に検証する（EU CRAでは2027年12月から義務化）
・より広いサプライチェーン防御の設計はサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストに体系化してある

CSPは「魔法の盾」ではないが、本件のように外部の可変スクリプトを読み込んで実行するタイプの攻撃には直接効く。ポイントは2つのディレクティブだ。script-srcで「どこから来たJavaScriptを実行してよいか」を絞れば、jsDelivrの見知らぬリポジトリから引き込まれるリモートローダーは実行されない。connect-srcで「どこへ接続してよいか」を絞れば、websocket.txtが指す標的サーバーへのWebSocketフラッドはwss://の許可リストで弾かれる。最低限の出発点はこうなる。

Content-Security-Policy: default-src 'self';
  script-src 'self' https://cdn.example.com;
  connect-src 'self' wss://api.example.com;
  object-src 'none';
  base-uri 'self'

この設定なら、たとえ何らかの経路で悪性スクリプトのタグが差し込まれても、（a）許可外ドメインからのJSはブラウザが実行を拒否し、（b）許可外へのWebSocket/フェッチはネットワーク層で遮断される——攻撃の2段階（読込と発火）を両方で止められる。まずはContent-Security-Policy-Report-Onlyで違反を計測して既存の正当な読込先を洗い出し、段階的に本適用へ移行するのが安全だ。詳細な構文はMDNのCSPガイドを参照。

ツール選定の観点も補足しておく。Socket.dev は依存の「振る舞い」（ネットワークアクセス・難読化・インストールスクリプトの有無など）をスコアリングして公開直後の悪性版を検出しやすく、Aikido Safe Chain はインストール時に既知悪性パッケージをブロックする。どちらも「公開から仕込みまでが短い」現代のnpm攻撃に対して、minimumReleaseAge（一定日数を経ていないバージョンを避ける）と組み合わせると効果が高い。とはいえ本件のように依存ツリーの外で起きる攻撃には、これらツールだけでは届かない。だからこそ配信側のCSP/SRIが最後の砦になる、という二段構えで捉えてほしい。

影響範囲：あなたはどの立場か

本件は「フロントエンドフレームワーク別×ビルドツール別で誰が脆弱か」という単純な表には落ちない。理由は明快で、148パッケージは人気ライブラリのタイポスクワットではなく攻撃者の自作プロキシアプリだからだ。ReactでもVueでも、Viteでもwebpackでも、正規の依存に自動で紛れ込む性質のものではない。したがって「影響範囲」は技術スタックではなく立場で切り分けるのが正確だ。

ネットワーク運用・SOCの視点では、監視すべきシグナルが従来と違う点に注意したい。認証情報窃取型なら「外部C2への少量の送信」を探すが、本件で見えるのは外部の未知エンドポイントへ向かう、短期集中的で反復的なWebSocket確立/切断の急増だ。100ミリ秒周期でCONNECT/CLOSEを撃ち続けるトラフィックは、正常なアプリのWebSocket利用とは統計的な形が異なる。出口プロキシでwss://先の分布を可視化し、見慣れないホストへの接続が特定端末群から一斉に立ち上がったら疑う。加えて、学校・カフェ・コワーキングのような共有ネットワークの提供者は、配下端末が無関係な第三者へDDoSを送出することで自組織のIP評価（レピュテーション）が毀損され、正当なサービスからブロックされる二次被害を負い得る。これは「うちは狙われていないから無関係」では済まない構造だ。

パッケージ数の表記は情報源で揺れがある点も押さえておきたい。JFrogの一次調査は148個とし、初期にSafeDepがカタログ化したのは141件、一部メディアは「140+」と表現している。本記事では一次ソースであるJFrogの148を採用した。被害の定量（どれだけの学生ブラウザが実際に動員されたか、看護学校がどの程度のダウンタイムを被ったか）は現時点で公開情報からは確定できず、JFrogも「約2週間の稼働」「見積もりベースの帯域」までを事実として提示している。ここは推測と事実を分けて読むべき箇所だ。

参照ソース

・Lucide Proxy: An npm Malware Campaign That Turns Browsers into a DDoS Botnet（JFrog Security Research・一次ソース）
・148 npm Packages Disguised as Student Proxies Turned Browsers Into a DDoS Botnet（The Hacker News）
・140+ Malicious npm Packages Turned Web Proxies for Students Into a DDoS Botnet（TechNadu）
・Content Security Policy (CSP)（MDN Web Docs）
・Subresource Integrity（MDN Web Docs）