公開2025.09.18更新2026.10.31 セキュリティ

Shai-Hulud（シャイ・フルード）とは？npmワーム2.0・Mini・CHAINDROPの影響確認と対策【2026年10月】

Q: 自分のプロジェクトが影響を受けたか、どう確認すればいいですか？

依存に該当版があるかと、痕跡が残っていないかの2点を見ます。痕跡は、 bun_environment.js ・ Math_Symbol.js ・ math_init.js などのファイル、 .claude や .vscode に置かれた setup.mjs を呼ぶ設定、名前や説明に「Shai-Hulud」「Sha1-Hulud」を含む公開リポジトリ、SHA1HULUDという名前のランナー、身に覚えのないパッケージ公開です。

Shai-Hulud（シャイ・フルード）とは？npmワーム2.0・Mini・CHAINDROPの影響確認と対策【2026年10月】

Shai-Hulud（シャイ・フルード、シャイフルード）は、JavaScriptのパッケージレジストリnpmで広がった自己増殖型のサプライチェーン攻撃です。2025年9月に初めて確認され、「Sha1-Hulud 2.0」「Mini Shai-Hulud」と手口を変えて再来し、2026年8月4日には人気ライブラリkeyvのメンテナを起点とする第4波（Elasticの命名でCHAINDROP）が起きました。10月8日にもtensorlake 0.5.144に同系統のワームが混入しており、収束したとは言えません。攻撃の起点別の類型や企業がとるべき対策の全体像は、サプライチェーン攻撃とは何かを起点別に整理した解説で確認できます。この記事では、4つの波の違い、波ごとの痕跡、自分が影響を受けたかの確認コマンドと対象パッケージ一覧の引き方、侵害時の対応、npm側の防御の変化までを一次情報に沿って整理します（2026年10月31日時点）。

まとめ：Shai-Huludの正体と4つの波、影響が疑われるときの最優先対応

正体：汚染されたnpmパッケージを起点に開発環境から認証情報を盗み、盗んだトークンで別のパッケージを汚染して自動的に広がるワーム型のサプライチェーン攻撃。
4つの波：初代（2025年9月、CISAの集計で500以上のパッケージ）→ Sha1-Hulud 2.0「The Second Coming」（2025年11月）→ Mini Shai-Hulud（2026年4月29日〜）→ 第4波CHAINDROP（2026年8月4日〜、keyv起点）。その後も9月の旧ペイロード再出現、10月8日のtensorlake侵害と続いている。
確認の起点：npm ls とロックファイルの版を、Socketの追跡ページ（CHAINDROPは445パッケージ・2,238版）やGitHub Advisory Databaseと照合し、波ごとの痕跡ファイルを探す。
影響が疑われるなら：端末とCIランナーを隔離し、CHAINDROP系の常駐処理（トークン失効を検知してホームディレクトリを消す）を停止・除去したうえで、クリーンな別端末からnpm・GitHub・クラウド・SSHなど全クレデンシャルの失効と再発行、リポジトリに仕込まれたワークフローとフック設定の削除を最優先で行う。
予防の土台：npm 12（2026年7月8日〜、10月時点の最新は12.2.1）は依存パッケージのライフサイクルスクリプトを既定でブロックする。npm 11系以前は --ignore-scripts を自分で付ける。GitHub Actionsは第三者アクションをコミットSHAで固定する。

Shai-Huludとは何か：名前の由来と従来の悪性パッケージより危険な理由

「Shai-Hulud」は、SF小説『デューン』に登場する巨大な砂漠の蠕虫（ワーム）の名前です。攻撃者が盗んだ情報を置くGitHubリポジトリ名に使ったことから、研究者の間で攻撃の呼称として定着しました。第2波では表記が「Sha1-Hulud」に変わり、Datadogの解析によると、窃取データを置くリポジトリの説明文に「Sha1-Hulud: The Second Coming.」が設定されました。検索で見かける「sha1-hulud」は、この2.0を指す表記です。

従来のnpm向け悪性パッケージの多くは「インストールした人の情報を盗んで終わり」でした。Shai-Huludが違うのは、盗んだ公開（publish）権限を使って被害者を次の感染源に変える点です。ひとりの開発者の侵害が、その人が管理する全パッケージ、さらにその利用者へと連鎖します。米CISAは2025年9月23日のアラートで、この自己複製ワームが500以上のパッケージを侵害したと注意を呼びかけました。

4つの波の全体像：初代・2.0・Mini・第4波CHAINDROPの違いと規模

Shai-Huludは単発の事件ではありません。直前の2025年8月には、Nxの公開権限が奪われ開発端末のAI CLIまで悪用されたs1ngularityが起きており、同じ型の前史にあたります。規模の数値は集計した組織と時点で異なるため、出典ごとに書いています。

波	時期	実行フック	規模（出典）
初代	2025年9月	postinstall	500以上（CISA）
Sha1-Hulud 2.0	2025年11月	preinstall	約700・30,000超リポジトリ（Wiz）
Mini	2026年4月29日〜	CI悪用・lifecycle	TanStack 42パッケージ84版（公式）ほか
CHAINDROP	2026年8月4日〜	preinstall	445パッケージ・2,238版（Socket）

初代Shai-Hulud（2025年9月）と500以上のパッケージへの連鎖

人気パッケージ@ctrl/tinycolorの不審な新バージョンを糸口に発覚しました。Socketの解析によると、パッケージに bundle.js が注入され、postinstallで起動します。TruffleHogで秘密情報を集め、被害者のGitHubに「Shai-Hulud」という公開リポジトリを作って data.json（二重Base64）として置く手口でした。Wizの解析は、非公開リポジトリが「Shai-Hulud Migration」という説明付きで公開リポジトリへ移されたことも報告しています。

Sha1-Hulud 2.0（2025年11月）の実行前倒しと多段構成

2025年11月下旬に「The Second Coming」と呼ばれる第2波が確認されました。Wizの初報によると、汚染版は11月21〜23日にアップロードされ、窃取データ入りのリポジトリが作られ始めた最初の証拠は11月24日です。最大の変化は、実行タイミングをpostinstallからpreinstallへ前倒ししたことです。setup_bun.jsでBunランタイムを導入し、bun_environment.jsで本体を実行する多段構成をとります。感染端末は「SHA1HULUD」という名前のself-hosted runnerとしてGitHubに登録され、持続化用の .github/workflows/discussion.yaml が追加されます。Kasperskyの解析は、npmやGitHubのトークンが得られず持ち出しができないとき、ホームディレクトリのファイルを消す破壊的な処理に移ると報告しました。

規模はWizの初報で約700パッケージ・25,000超のGitHubリポジトリでしたが、続報では30,000超のリポジトリに増えています。Zapier・ENS Domains・PostHog・Postman・AsyncAPIなど著名なパッケージが一時的に汚染されました。

Mini Shai-HuludによるTanStack侵害と来歴証明の限界

2026年は「TeamPCP」とされる攻撃グループによるMini Shai-Huludが登場しました。TanStackの公式ポストモーテムによると、2026年5月11日19:20〜19:26（UTC）に42パッケージで84の悪性版が公開され、原因はPwn Request、GitHub Actionsのキャッシュ汚染、ランナーのメモリからのOIDCトークン抽出でした。悪性版にも暗号学的に有効なprovenance（来歴証明）が付いていました。ただしSLSA公式の解説によると、このビルド基盤はBuild L3の分離要件を満たしておらず、npm標準のprovenanceはBuild L2に相当します。来歴証明が示すのは「どのリポジトリとCIで作られたか」までで、そのCIが乗っ取られていれば悪性版にも正しい証明が付きます。Akamaiの分析は、攻撃がMistral AI・UiPath・OpenSearch関連のパッケージへ広がったこと、5月12日夜に武器化済みのワームのコードが公開されたことを報告しています。コードの公開後は、OX Securityが報告したchalk-tempalteのような模倣パッケージも現れました。

MiniはPyPI（Python）にも及びました。同じTeamPCPはSemgrepの分析によると2026年3月にTrivyの侵害からnpmのワームを経てPyPIのLiteLLMへ攻撃を広げており、LiteLLMは10月21日にも1.107.0の配布物が侵害されています（影響確認はLiteLLM 1.107.0侵害の解説記事）。5月29日には亜種「Miasma」を使った侵害がRed Hatの@redhat-cloud-servicesで発生し、6月1日に公表されました。RHSB-2026-006は32パッケージの侵害と、リリース済みのRed Hat製品には含まれないことを明記しました。

第4波CHAINDROP（2026年8月4日〜）とkeyv起点の拡大

Elastic Security Labsの分析によると、2026年8月4日、攻撃者はキーバリューストアのライブラリkeyvのメンテナを侵害し、モノレポに自己増殖型ワーム「CHAINDROP」を埋め込みました。盗んだnpmの認証情報で、そのメンテナが公開権限を持つ他のパッケージを自動的に汚染します。Elasticは執筆時点で400超のパッケージが侵害されたとし、Microsoftも同日付の解析で、無関係な複数の公開者にまたがる400超のパッケージへの影響を報告しました。

シンガポールのサイバーセキュリティ庁（CSA）は8月6日の勧告AD-2026-009で、keyv 6.0.0、flat-cache 6.1.24、file-entry-cache 11.1.6、cacheable-request 13.0.20などを影響版として挙げています。対象一覧を継続追跡しているSocketの追跡ページで、10月31日時点で445のユニークパッケージ・2,238の版を表示しています。

2026年9〜10月の動き：旧ペイロードの再出現とtensorlake 0.5.144

CHAINDROPの後も、同系統の攻撃は形を変えて続いています。防御側が見落としやすいのは、パッケージではなくGitHub Actionsの側から再び感染が起きた例です。

9月上旬（旧ペイロードの再出現）：Aikidoの報告によると、5月19日の@antvの波（639の悪性版）と同じハッシュのペイロードが、111日ぶりに4つのnpmリリースで見つかった。npmが7月に始めた公開時のマルウェア検査をすり抜けている。
9月16日（Actionsの再感染）：Socketの報告によると、Miniで侵害され5月に無効化された actions-cool/issues-helper と actions-cool/maintain-one-comment が再び取得可能になった。リリースタグが悪性の内容を指したままだったため、タグで参照していたワークフローがペイロードを再実行した。5月18日より前のクリーンなコミットSHAで固定していたワークフローは、このタグ改ざんの影響を受けていない。なお、両アクションは9月25日に再び無効化された。
10月8日（tensorlake 0.5.144）：Aikidoの報告によると、前日にメンテナ名義で検証済みのコミットが作られ、約20時間後にnpmへ公開された。Socketは公開を01:12:07（UTC）、検知を01:23:10とし、ChainDrop／Shai-Huludとして扱っている。preinstallで lib/setup.mjs を起動し、Bunで lib/Math_Symbol.js を実行する構成は第4波と同じで、14種類の暗号資産ウォレット拡張のデータも狙う。0.5.144は現在レジストリから取り下げられている（npm view [email protected] は404）。

攻撃の仕組み：開発環境への侵入経路と感染拡大、設定ファイルへの持続化

波によって細部は異なりますが、基本の流れは共通しています。

侵入：汚染パッケージをインストールすると、ライフサイクルスクリプト（preinstall／postinstall）経由でマルウェアが自動実行される。Miniは、GitHub Actionsのキャッシュ汚染やタグの書き換えでCIの中から侵入した。
秘密情報の収集：TruffleHogなどで .npmrc のnpmトークン、.env、SSH鍵、クラウドの認証情報を探索する。
外部送信：GitHubの公開リポジトリに置く手口が基本。CHAINDROPとtensorlakeの亜種は、送信先をEthereumのスマートコントラクトから実行時に取得し、ペイロードを変えずに送信先を切り替える。
持続化：悪性のGitHub Actionsワークフローやself-hosted runnerを仕込む。CHAINDROPはさらに、Claudeの設定ディレクトリの settings.json に SessionStart フックを置いて node .claude/setup.mjs を実行させ、VS Codeの tasks.json には folderOpen タスクを置く。
自己増殖：盗んだnpmトークンで別パッケージに悪性版を公開する。GitHub Appのトークンが盗まれた場合、CHAINDROPはアクセスできるリポジトリごとに最大50ブランチへ悪性の設定ファイルをコミットする。

Elasticは、感染したリポジトリを開くだけで開発者が感染しうると書いています。AIコーディングツールのフック設定がそのまま攻撃の実行経路になるため、Claude Code Hooksのイベントとsettings.jsonの書き方を一度確認しておくと、不審な設定を見分けやすくなります。

盗まれる情報と影響の対象範囲：開発環境に置かれたクレデンシャル

Shai-Huludが狙うのは、開発の利便性のために手元に置かれている各種クレデンシャルです。

npmアクセストークン（.npmrc 等）：パッケージの不正公開に悪用される。
GitHub Personal Access Token・GitHub Appトークン：リポジトリ操作や、CHAINDROPでは多数ブランチへの悪性コミットに使われる。
クラウドの認証情報（AWS／GCP／Azureのキー、メタデータ経由の一時トークン）：インフラ侵入につながる。Sha1-Hulud 2.0は集めた情報を cloud.json・contents.json・environment.json・truffleSecrets.json にまとめる。
SSH秘密鍵、環境変数中の秘密（DB接続情報、各種APIキー）、Kubernetes・Vaultなどのシークレット。tensorlakeの亜種はブラウザ拡張の暗号資産ウォレットも対象にした。

CIランナーに長期の認証情報を置いている組織ほど、クラウドの不正利用や社内への横展開まで被害が広がります。

自分は影響を受けたか確認する方法：痕跡ファイル・設定フック・依存ツリー

確認は「依存に該当版があるか」と「痕跡が残っていないか」の2本立てで進めます。痕跡は波ごとに違うため、表で引けるようにしました。

波	ファイル	GitHub上の痕跡
初代	bundle.js	Shai-Hulud リポジトリ・shai-hulud-workflow.yml
Sha1-Hulud 2.0	setup_bun.js・bun_environment.js	runner名 SHA1HULUD・discussion.yaml
Mini（PyPI経由）	/tmp/transformers.pyz	タグで参照した汚染アクション
CHAINDROP・tensorlake	setup.mjs・Math_Symbol.js・gh-token-monitor	.claude と .vscode の起動フック

窃取データを置くリポジトリには波ごとの目印があります。Socketの整理では、初代がリポジトリ名「Shai-Hulud」、2.0が説明文「Sha1-Hulud: The Second Coming.」、2026年4月の@bitwarden/cli 2026.4.0の侵害が「Shai-Hulud: The Third Coming」、Miniが「A Mini Shai-Hulud has Appeared」と、文字列を逆順にした「niagA oG eW ereH :duluH-iahS」です。CHAINDROPの Math_Symbol.js はkeyvのモノレポから直接汚染された版、math_init.js は伝播先の版に入っています。次のコマンドは調査対象を変更しない確認用です（macOS・Linux・WSL、npm、Git、認証済みのGitHub CLIを想定）。各プロジェクトのルートで実行してください。検索するファイル名・場所・リポジトリ数には限りがあり、未検出でも侵害は否定できません。

# 1) 痕跡ファイルを探す（ホーム全体の走査は時間がかかる）
find . ~ -type f \( -name "Math_Symbol.js" -o -name "math_init.js" \
  -o -name "bun_environment.js" -o -name "setup_bun.js" \) 2>/dev/null

# 1b) トークン失効でホームを消す常駐処理（CHAINDROP系）が入っていないか
ls -d ~/.config/gh-token-monitor ~/Library/LaunchAgents/com.user.gh-token-monitor.plist 2>/dev/null

# 2) リポジトリに仕込まれた起動フックとワークフローを探す
grep -rn "setup.mjs" .claude .vscode 2>/dev/null
ls .github/workflows/ 2>/dev/null | grep -E "discussion\.yaml|shai-hulud-workflow\.yml|formatter_"

# 3) 自分のアカウントに作られた不審なリポジトリを探す
gh repo list --limit 1000 --json name,description \
  --jq '.[] | select((.name + " " + (.description // "")) | test("hulud|duluh"; "i")) | .name'

# 4) 第4波で侵害が報告された代表パッケージが依存ツリーにあるか
npm ls keyv flat-cache file-entry-cache cacheable-request cacheable cache-manager tensorlake --all

# 5) ワームが作るコミットの目印（author名 claude・メッセージ chore: update config）
git log --all --author="claude" --grep="chore: update config" --oneline

2で SessionStart や folderOpen から setup.mjs を呼ぶ設定が見つかれば、侵害を強く疑います。Claude Codeのフック自体は正規の機能なので、SessionStart という語があるだけでは判断せず、何を実行しているかを見てください。5も、正規の運用で「claude」という作成者名のコミットが入っている組織では候補の一覧として扱います。組織でself-hosted runnerを使っている場合は、リポジトリや組織の設定画面で「SHA1HULUD」という名前のランナーが登録されていないかも確認します。

対象パッケージ一覧の引き方と照合の手順

「Shai-Hulud 対象」で探される一覧は、1か所にまとまっていません。波ごとに一次情報が分かれるため、次の順で当たります。

CHAINDROP：Socketの追跡ページが版単位の一覧を持つ。CSAの勧告はここを参照している。
個別パッケージ：GitHub Advisory Databaseで名前を引く。keyvはGHSA-3p9h-f68w-m6fxで、影響版は6.0.0、修正版の欄は「None」（悪性版の取り下げで対処）となっている。
照合：npm ls の出力に加え、ロックファイル（package-lock.json・pnpm-lock.yaml・yarn.lock）に記録された版で比べる。CIのキャッシュや開発者の手元に古いロックファイルが残っていないかも見る。

Dependabotの悪性パッケージ警告を有効にしておくと、Advisory Databaseに載った版が依存に入ったときに通知されます。一覧に載っていないことは安全の証明にならないため、痕跡の確認と組み合わせてください。

侵害時の対応手順：隔離・常駐処理の除去・全クレデンシャル失効

影響が疑われるときは、被害拡大を止めることが最優先です。次の順で進めます。

隔離：該当端末・CIランナーをネットワークから切り離す。痕跡ファイルのコピーを保全してから、汚染した node_modules を削除しキャッシュをクリアする（rm -rf node_modules ／ npm cache clean --force）。
常駐処理の除去：tensorlakeの公式勧告は、盗んだGitHubトークンが失効するとホームディレクトリを削除する常駐サービス gh-token-monitor を、トークンを失効させる前に除去するよう求めている。Socketの解説によると、8月のkeyvのペイロードも同じ仕掛けを入れていた。Linuxは systemctl --user disable --now gh-token-monitor.service のあと ~/.config/gh-token-monitor/ と ~/.local/bin/gh-token-monitor.sh を、macOSは launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/com.user.gh-token-monitor.plist のあとplistを削除する。
全クレデンシャルのローテーション：クリーンな別端末から、npmトークン、GitHub PATとGitHub Appの秘密鍵、クラウドのアクセスキー、SSH鍵を「すべて漏れた前提」で一斉に失効・再発行する。
GitHubの修復：不審な公開リポジトリ、悪性ワークフロー、登録されたself-hosted runner、.claude/settings.json と .vscode/tasks.json に追加されたフック、関連ブランチ（tensorlakeの勧告では dependabot/github_actions/format/setup-formatter）を削除し、監査ログと、トークンで公開・書き込みできたパッケージやリポジトリに想定外のリリースがないかを確認する。
クリーン再構築：侵害された端末・CIランナーは信頼できるイメージから再構築し、ロックファイルを確認して既知の安全な依存パッケージを導入する。CSAの勧告とAikidoはいずれも、悪性パッケージを入れたシステムは完全に侵害されたものとして扱うよう求めている。

クラウドキーが漏れた疑いがあるときは、AWS CloudTrailなどのアクセスログで不審な操作がないかも確認してください。

再発防止・予防策：npm 12の既定値とCI/CDで入っても広がらない設計

Shai-Hulud系の攻撃は手口を変えて再来します。「入っても広がらない」設計を優先度の高い順に並べます。

ライフサイクルスクリプトの抑制：GitHubの告知によると、npm 12では依存パッケージのpreinstall・install・postinstallと暗黙のnode-gypビルドが、明示的に許可しない限り実行されない。許可はルートの package.json の allowScripts で行い、npm install-scripts approve で承認を記録する。dangerously-allow-all-scripts を有効にするとこの仕組みごと無効になるので、CIでは使わない。npm 12の変更点はnpmのCLIとv12の変更点で整理した。
GitHub Actionsの固定：第三者アクションはタグでなくコミットSHAで参照する。9月のactions-coolの再感染は、タグ参照のワークフローだけが被害を受けた。タグが書き換えられた前例はtj-actions/changed-files侵害の経緯にもある。
バージョン固定：ロックファイルを必ずコミットし、依存は内容を確認してから上げる。pnpmとcorepackでの管理はcorepackとpnpmの版管理が参考になる。
公開側の認証：npmは短命・スコープ限定のトークンかTrusted Publishingへ移行する。開発・CIアカウントにはフィッシング耐性のあるMFAを適用する。認証技術の動向はDBSCとパスキー連携の設計、組織的なフィッシング対策はフィッシング対策ガイドライン2026年度版のDMARC要件が指針になる。
監視と封じ込め：ビルド環境からの外部通信を信頼先に限定し、新規リポジトリや身に覚えのないパッケージ公開を監視する。依存の振る舞い検知にはsocket.devの仕組みも選択肢になる。Node.js自体の脆弱性対応はNode.jsの脆弱性と対応バージョンを参照。

npm 11系以前を使い続けるCIでは、スクリプトの停止を自分で指定する必要があります。手元の版を確かめてから、次のように実行します。

# npmの版を確認する（12.0.0以降なら依存のスクリプトは既定でブロックされる）
npm --version

# npm 11系以前のCI: 依存のライフサイクルスクリプトを実行せずにインストールする
npm ci --ignore-scripts

--ignore-scripts はネイティブアドオンのビルドなど正当なスクリプトも止めるため、必要なパッケージだけを後から npm rebuild <パッケージ名> で実行する運用にします。npm 12・pnpm・Yarnの既定値の違いはaxiosのマルウェア混入と再発防止の設定で比較しています。CI/CDにスクリプト制御や外部通信の制限を組み込む作業を社内だけで進めにくい場合は、DevOps・CI/CD導入支援で設計段階からの伴走が可能です。

npmレジストリ側の対策の時系列（2025年9月〜2026年10月）

Shai-Hulud以降、npmは公開側の認証と公開前の検査を段階的に締めています。利用側の対策と違い、パッケージを公開している組織は自分の運用がこの変更に追随しているかを確認する必要があります。

日付	変更
2025年9月29日発表・10月13日適用	新規の書き込み可能なgranular tokenを既定7日・上限90日へ
2025年11月5日	classic tokenの新規作成を停止、新規トークンは2FAを既定化
2025年12月9日	既存のclassic tokenをすべて失効、npm loginは2時間のセッション
2026年7月8日	npm 12で依存のinstall scriptsを既定ブロック
2026年7月28日	公開時のマルウェア検査（約5分、混雑時15分以上）
2026年7月31日	2FA回避トークンによる管理操作を禁止
2026年9月18日	公開できないstage-onlyトークンと2FA承認
2026年10月2日	未検証のTrusted Publishing設定を48時間で失効

出典は順に、GitHub Changelogの2025年9月29日・11月5日・12月9日・2026年7月28日・7月31日・9月18日・10月2日です。公開時の検査は「検知できたマルウェアを止める」仕組みで、9月の再出現のようにすり抜けた例があります。検査があるから利用側の対策を緩めてよい、という判断はとらないでください。公開後すぐにインストールできる前提で組んだリリース自動化は、この保留時間で止まることがあります。開発工程全体での防御の組み立てはソフトウェアサプライチェーンセキュリティの実装判断で扱っています。

よくある質問

Shai-Huludについて、検索の多い質問に2026年10月31日時点の公開情報で答えます。

Shai-Hulud（シャイフルード）とは何ですか？

汚染されたnpmパッケージを起点に開発環境の認証情報を盗み、盗んだトークンで別パッケージを汚染して自動的に広がる、自己増殖型のサプライチェーン攻撃です。名前は小説『デューン』の砂虫に由来します。2025年9月の初代以降、2.0、Mini、2026年8月の第4波CHAINDROPと再来し、10月にもtensorlake 0.5.144で亜種が見つかっています。

Sha1-HuludやShai-Hulud 2.0は初代と何が違いますか？

Sha1-Huludは2025年11月の第2波の表記で、2.0と同じものを指します。初代がpostinstallで動いたのに対し、2.0はpreinstallで動き、setup_bun.js と bun_environment.js の2段で実行されます。感染端末をSHA1HULUDという名前のself-hosted runnerとして登録し、持ち出しに失敗するとホームディレクトリを消そうとする点も初代にはない挙動です。

影響を受けた対象パッケージの一覧はどこで見られますか？

第4波CHAINDROPの対象一覧はSocketの追跡ページで確認でき、10月31日時点で445パッケージ・2,238版を表示しています。個別のパッケージはGitHub Advisory Databaseで名前を引くと影響版がわかります。照合は npm ls の表示だけでなく、ロックファイルに記録された版で行ってください。

自分のプロジェクトが影響を受けたか、どう確認すればいいですか？

依存に該当版があるかと、痕跡が残っていないかの2点を見ます。痕跡は、bun_environment.js・Math_Symbol.js・math_init.js などのファイル、.claude や .vscode に置かれた setup.mjs を呼ぶ設定、名前や説明に「Shai-Hulud」「Sha1-Hulud」を含む公開リポジトリ、SHA1HULUDという名前のランナー、身に覚えのないパッケージ公開です。

侵害が疑われるとき、最優先でやるべきことは？

まず端末・CIランナーを隔離します。CHAINDROPとtensorlakeの亜種は、盗んだGitHubトークンの失効を検知するとホームディレクトリを消す常駐処理（gh-token-monitor）を入れるため、これを停止・除去してから、クリーンな別端末で認証情報をローテーションします。「すべて漏れた前提」で一斉に失効・再発行し、リポジトリに仕込まれたワークフロー、ランナー、フック設定を削除します。悪性パッケージを入れたシステムは、侵害されたものとして再構築するのが安全です。