ハクソク

世界を動かす技術を、日本語で。

「シャイ・フルード」テーマのマルウェアがPyTorch Lightning AIトレーニングライブラリで発見される

5時間前原文(semgrep.dev)

概要

  • PyPIのlightningパッケージ（2.6.2, 2.6.3）がサプライチェーン攻撃で改ざん
  • 認証情報・クラウドシークレット窃取やGitHubリポジトリ汚染を実施
  • npmエコシステムにも拡散、多様な開発環境が影響
  • Claude Code/VS Codeの永続化フックによる高度な持続性
  • IOCや対策方法も明示、該当プロジェクトは即時監査必要

PyPI lightningパッケージ改ざん攻撃の概要

  • 2026年4月30日公開のlightning 2.6.2/2.6.3がサプライチェーン攻撃の標的
  • pip install lightningのみでマルウェアが発動
  • _runtimeディレクトリ内に難読化JavaScriptペイロードを隠蔽
  • インポート時に自動実行し、認証情報・環境変数・クラウド秘密情報を窃取
  • GitHubリポジトリの汚染やShai-Huludテーマの痕跡（Dune関連命名）が特徴
  • 攻撃者はmini Shai-Huludキャンペーンと同一と推定

影響範囲と感染経路

  • lightning 2.6.2/2.6.3導入プロジェクト全体が対象
  • 画像分類、LLMファインチューニング、拡散モデル、時系列予測など多様な用途で依存
  • npmにも伝播し、npmパッケージへのsetup.mjsドロッパー注入・再配布を自動化
  • npm publish権限を持つトークンが発見されると、全公開可能パッケージに感染コード注入

マルウェアの動作詳細

  • 4チャンネル並列の情報流出で検知回避
    • HTTPS POST（C2サーバーへ暗号化データ送信）
    • GitHubコミット検索API経由のdead-dropトークン受信
    • 攻撃者管理の公開GitHubリポジトリへ窃取情報コミット
    • 被害者自身のリポジトリへの直接Push
  • 窃取対象
    • ローカルファイル（80種以上の認証ファイルパススキャン）
    • シェル・環境変数（gh auth token, process.env全出力）
    • GitHub Actions（LinuxランナーのWorkerメモリダンプ、Secrets抽出）
    • AWS/Azure/GCPの各種シークレット、SSMパラメータ、Key Vault、Secret Manager
  • 持続化（永続化）
    • Claude Code：.claude/settings.jsonにSessionStartフック追加
    • VS Code：.vscode/tasks.jsonにfolderOpen自動実行タスク追加
    • 両者ともsetup.mjsドロッパーを起動し、Bunランタイムを自動DL・実行
    • .claude/router_runtime.js（14.8MB本体ペイロード）を実行
  • 追加ペイロード
    • GitHub Actions用のFormatterワークフローを強制Push
    • 全SecretsをActionsアーティファクトとしてformat-results名で漏洩

Semgrepユーザー向けアドバイス

  • Semgrep Advisoryとルールで該当プロジェクトをスキャン可能
  • 最新スキャン未実施の場合は即時実行推奨
  • https://semgrep.dev/orgs/-/advisoriesで該当バージョン導入有無を確認
  • 依存関係フィルタで一致がなければ現状は安全
  • 一致した場合は下記IOCや全認証情報の即時ローテーション必須

IOC（侵害の痕跡）一覧

  • コミットメッセージ：EveryBoiWeBuildIsAWormyBoiで始まるもの
  • GitHubリポジトリ説明："A Mini Shai-Hulud has Appeared"
  • 感染パッケージ：lightning@2.6.2, lightning@2.6.3
  • システム/リポジトリアーティファクト
    • _runtime/start.py
    • _runtime/routerruntime.js
    • _runtime/ディレクトリ全体
    • .claude/router_runtime.js
    • .claude/settings.json
    • .claude/setup.mjs
    • .vscode/tasks.json
    • .vscode/setup.mjs

推奨対応策

  • 該当バージョンのアンインストールと安全なバージョンへの差し替え
  • 全リポジトリ・CI環境の再監査、上記IOCファイルの有無確認
  • GitHubトークン・クラウド認証情報・APIキーの即時ローテーション
  • 感染拡大を防ぐため、依存関係全体の洗い出しと再構築が必要
  • Claude Code/VS Code設定ファイルの手動チェックとクリーニング

まとめ

  • lightningパッケージのサプライチェーン攻撃は、現代開発環境の多層的な脆弱性を露呈
  • 依存関係管理・CI/CD・IDEツールすべてが攻撃経路となり得る
  • 迅速なIOC監査・認証情報ローテーション・環境再構築が被害最小化の鍵

Hackerたちの意見

創造主とその水に感謝を。
リポジトリ検索をしたら、「A Mini Shai-Hulud has Appeared」ってテキストのリポジトリが2.2Kも見つかったよ。全部、昨日のうちに作られたみたい。: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...
└
これって一体何のこと？
└
リポジトリ名は、ダンの用語（ハルコネン、メンタット、オーニソプターとか）と数字が組み合わさった感じになってるね。これって、アカウント（おそらくGitHubの認証/アクショントークン）がハッキングされて、その後リポジトリが作られたってことを示してるんじゃないかな。
確認だけど、PyTorchじゃなくて、このLightning AI会社のライブラリのこと？
└
そうだよ。
└
おっと、PyTorch LightningがPyTorchと関係あると思ってた。無関係な第三者のものにしてはあまり良い名前じゃないね。
セキュリティの専門家じゃないけど、依存関係がどうやって侵害されたのか、具体的にどういうこと？ GitHubのメインリポジトリにPRを出して、メンテナが承認したの？それとも、他のミラーに侵害されたバージョンをホストしてたの？
└
こちらはLightningのAndyです。悪意のあるコードはGithubのメインリポジトリには提出されていません。どうやら私たちのPyPiの認証情報が漏洩して、2.6.2と2.6.3のバージョンが直接公開されたようです。
PyTorch Lightning 2.6.2と2.6.3のセキュリティ問題を報告してくれたコミュニティに感謝！現在、調査中だよ。その間は、2.6.1を使ってね。2.6.4を公開するまで。詳しくは: https://github.com/Lightning-AI/pytorch-lightning/security/a...
依存関係がなくなるのが待ちきれない！今は娘のためにインタラクティブな教育アプリを作ってるんだけど、OpusにはプレーンなJSとHTMLだけを使わせてるんだ。二重振り子から流体シミュレーションまで、一発で動くよ。前は何百もの依存関係があったけど、MITライセンスのコードのおかげで、必要な部分だけを抽出して埋め込むことができるし、自分の使い方に合わせて調整もできる。今のところ趣味のプロジェクトにはすごくいい感じだけど、将来的には商用ソフトウェアも依存関係がなくなるといいな。
└
迷ってるんだよね、RustがGoより好きだし、LLMの観点から見るとRustの方が優れてる。でも、Rustの依存関係の哲学は基本的にセキュリティのブラックホールみたいで、Goの方がずっとマシなんだ。
└
これの問題は、今やすべての変更やライフサイクルのバリエーションを管理する責任があなたにあるってこと。ChromeがこのAPIの形を変えたら、それを見つけて更新するのはあなたの責任。モロッコの夏時間が適用されるときも、日付/時間処理のコードを更新しなきゃいけない。ライブラリがそれを処理してくれてるから当たり前だと思ってることがたくさんあって、依存関係がないとすべて自分でやらなきゃいけない。娘のために作る二重振り子シミュレーターなら来週にはどうでもよくなるけど、将来的にずっと動き続けるものを作ろうとしてる会社には心配なことだよね。
└
あなたのLLMは依存関係じゃないの？
└
まあ、Opusがコードに脆弱性を入れることは絶対にないだろうから、それが解決策っぽいね。
└
もちろん、Opusが生成するコードのすべての行を、オープンソースのメンテナンスに期待されるのと同じくらい厳しくチェックするよね？ね？俺はMITライセンスのリモートアクセスコードを公開して、Opusのトレーニングデータに入れようと思ってるんだけど。
└
比較的近い将来、言語モデルのトレーニングデータに対する高度なサプライチェーン攻撃が見られるようになると思う。トレーニングデータの中で個別には無害に見える脆弱性を設計するのは可能だし、それらを組み合わせてエージェントプレーンで実行すると、エクスプロイトを引き起こすことができる。今のところ、技術的にそれを阻止するものは何もない。ただ、まだ誰もその努力をしていないだけなんだ。
これは単なる頻度錯覚かもしれないけど、最近大きなパッケージで目立つサプライチェーン攻撃がいくつかあったみたい。HNの最初の数ページには、いろんなケースについての記事がいくつか載ってる。10年前の`left-pad`を振り返ると、今の方が成功した攻撃が多いんじゃないかな？そう思うし、成功した攻撃の価値も上がってるから、実際にパッケージリリース前にそれを検出する能力はコミュニティ全体で向上してるのかな？これは複雑な問題で、商業ソフトウェアの会社はもっと頑張るべきだけど、優れた商業製品（例えばCIスキャンツール）はあるものの、趣味やアマチュアのコードから始まって他のプロジェクトの依存関係になるようなプロジェクトには、一般にアクセスしやすくて使いやすいツールが不足してる気がする。今のSAPサプライチェーン攻撃スレッドからコメントをクロスポストしたよ。[0]: https://news.ycombinator.com/item?id=47964003
└
人々はコードを見ずにどんどん詰め込んでるから、サプライチェーン攻撃が増えるのも当然だよね。
└
> 10年前の`left-pad`を振り返ると、今の方が成功した攻撃が多いのかな？そうだと思うし、成功した攻撃の価値も上がってるから、実際にパッケージリリース前にそれを検出するのがコミュニティ全体として上手くなってるのかな？価値が上がってるのは確かで、それがこういう攻撃を引き起こす要因になってる。特に暗号通貨が悪いよね。彼らは利益を洗浄する手段を提供しただけでなく、自体が魅力的なターゲットでもあるから。で、今日のマルウェアで盗まれるのは何かって？クラウドの認証情報だよ。違法なマイニングに使われるか、今は減少してるけど、恐喝キャンペーンを実行するために使われる。こういうキャンペーンを運営してるのは、北朝鮮やイランが多いんだよね。
今週、Pythonのバージョン管理にuvを使うのがいいアイデアかどうか考えてたんだけど。彼らのウェブサイトによると、> 「Pythonは公式の配布可能なバイナリを公開していません。」だから、uvはAstralのpython-build-standaloneプロジェクトからの配布物を使ってるみたい。詳しくはPythonの配布に関するドキュメントを見てね。これがGitHubのリポジトリを指してるんだ：https://github.com/astral-sh/python-build-standalone これが別のリンクを言及してる：https://gregoryszorc.com/docs/python-build-standalone/main/r... もし俺の理解が正しければ、Pythonをビルドするためのソースコードはpython.orgから直接取得されてないんだよね。それがどれだけ安全かはちょっと疑問。asdfにも同じ懸念があるけど、彼らはpyenvを使ってるから、こっちの方が公式っぽい気がする。誰かこれについて詳しく教えてくれない？Pythonをインストールするのにどっちのツールがいい/安全なの：uvかasdfか？
└
つまり… uvはすでにコンピュータ上でPythonのバイナリやパッケージ（それに関連するバイナリ）、システム全体のツールを管理するためのバイナリなんだから、Pythonのバイナリを自分たちでビルドするか他の誰かがやるかで、どれだけ変わるの？
└
> もし俺の理解が正しければ、Pythonをビルドするためのソースコードはpython.orgから直接取得されてないんだよね。それがどれだけ安全かはちょっと疑問。python-build-standaloneはCPythonのソースを直接python.orgから取得してるよ[1]。他にどこから取得するかなんて、俺にはわからないよ！ [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
Fast.AIのディープラーニングコースを受けてた時、機械学習プロジェクトが持つPythonの依存関係の多さに驚いた。ウェブのフロントエンドプロジェクトはいつもサードパーティの依存関係が多いとされてたけど、機械学習のエコシステムはもっと絡み合ってるように見える。それに、ウェブ開発はセキュリティが重要視されてて、長年の知恵や良いセキュリティ関連の実践が蓄積されてるけど、機械学習の開発はもっとアドホックで、一般的なソフトウェアエンジニアリングの実践があまり適用されてない印象。例えば、その時、機械学習モデルを配布する一つの方法はPythonのピクルスを使うことだった。これは制限なしに実行可能なオブジェクトなんだ。こういう形式のモデルは、インポートしたコンピュータ上で何でもできちゃう。こんな初期の「無法地帯」エコシステムは、セキュリティの妥協を容易にし、サプライチェーン攻撃をより一般的にする可能性があるね。
私のpipインストールのほとんどは、Claude Codeが提案してくれたものをそのままエンター押してるだけなんだ。モデルは数ヶ月前にトレーニングされたから、今週何が危険になったかなんて全然わからない。今の「このパッケージは安全？」っていうフィルターは最悪のものを作っちゃったね。
└
「最悪のフィルター」って、要するに「Claudeが言ったらエンター押すこと」ってこと？