GitHub自体のセキュリティ保護が破られたわけではありませんが、顧客個々の防御が突破されました。この攻撃では、自律型コーディングエージェントも一役買っています。
セキュリティ調査会社は月曜日、サードパーティーの42のGitHubリポジトリで侵害を確認したと報告しました。攻撃者は、この種の侵害を見つけるために通常使われるGitHubの検索パスやAPIパスを「回避できるほど」巨大なペイロードのブロブを仕込んでいたといいます。
JFrog Security Researchが公開したレポートによると、被害を受けたリポジトリには、AIコーディングアシスタントやIDE向けの実行フックが含まれていました。さらに、最大13.7MBのポリモーフィック型ラッパーも見つかっています。これらは「すべて、同一の隠されたCI公開用ペイロードにデコードされました。このキャンペーンで攻撃者が所有するリポジトリは、暗号化データの受け皿としても稼働しており、スナップショットのエンベロープを受信しています。攻撃では新たな偽装手法も使われました。それは、ペイロードを一切含まないコンパイル済みネイティブアドオンです。このアドオンは実行時に.napi_cacheというファイルを復号し、本物のペイロードを展開します」。
JFrogによると、調査ではほかにも、アカウントの乗っ取り、偽造されたコミットのタイムライン、短命な公開用ブランチ、露出したnpm認証情報が確認されました。同じ乗っ取り対象オーナーのクラスターからはShellpanelのアーティファクトも見つかっています。これにより、今回のGitHub被害インフラは、インターネットに公開されたcPanelシステムを狙うGitHub Actionsの悪用として以前報告された事例とつながります。
JFrogは次のように記しています。「10月21日、当社のスキャナーがnpmエコシステムでshai-huludパッケージを検知しました。SafeDepの10月22日付の分析が、この活動のnpm／パッケージ側を最初に文書化し、[email protected]をデコードしました。SafeDepはこのペイロードをMiasmaファミリーと説明する一方、系統については不確かさが残ると明記しています」。
SafeDepは当初、自らが発見した「testmetest」と名付けたキャンペーンのパッケージについて、攻撃者による単なるテストだと考えていました。しかし今週、既存のリポジトリが悪意あるコンテンツで侵害されていることを突き止めました。
JFrogの投稿は、npmチェーンが持つ意味にも焦点を当てています。
投稿によると、「npmチェーンは、より広範な攻撃活動への手がかりとなります。悪意あるtestmetestのリリースは、通常のインストールスクリプトを宣言していないにもかかわらず、binding.gypのコマンド展開を利用して、インストール時にindex.jsを実行しました。ローダーは、文字コード配列にビルドごとのシーザー変換を適用し、AES-128-GCMのステージを復号したうえで、Bun 1.2.18を探し出すか、ダウンロードしました。ビルドによって、復号したペイロードはbun run -にパイプされるか、一時的な.b-*ディレクトリに書き出され、実行後に削除されます。npmペイロードの全体は、認証情報を収集し、リポジトリとCI設定を汚染して、パッケージレジストリを通じて拡散しました」。
JFrogは、攻撃者が管理するこれらのリポジトリが、対応するnpmパッケージ向けのカバープロジェクトの供給源になっていたと説明しています。
研究者らは次のように述べています。「悪意あるリリースはnpmワームを配布し、サードパーティーのリポジトリにアクセスできるGitHubとnpmの認証情報を盗みました。乗っ取られたリポジトリ内に、このキャンペーンはスモークテスト用のプレースホルダー、または起動可能なペイロードを残しました。起動可能なci.jsファイルをデコードすると、GitHub Actionsを通じて実行されるよう設計された公開用コードが見つかりました。これはnpmトークンや信頼された公開（トラステッドパブリッシング）を使ってtestmetestの悪意あるリリースをさらに作り出し、パッケージ配布の成果をリポジトリ侵害へと還流させる仕組みです」。
推奨される防御策
JFrogの投稿は、こうした攻撃の検知と緩和に向けて、さまざまな防御策を推奨しています。たとえば、CISOは「完全版ワームのインストールを、ホストの侵害として扱うべき」だとしています。また、GitHub、GitLab、npm、PyPI、RubyGems、クラウド、SSH、Vault、Kubernetes、AIプロバイダーのすべての認証情報を失効させてローテーションするよう提案しています。さらに、「影響を受けたIDがアクセスできるすべてのリポジトリを監査し、.github/init.js、.claude/settings.json、.gemini/settings.json、.cursor/mcp.json、.cursor/rules/setup.mdc、.vscode/tasks.json、想定外のcomposer.jsonやMakefileの実行フック、skip-checks:true付きのコミットがないか調べる」ことも求めています。
JFrogはまた、ラッパーのサイズが問題になるため、企業はリポジトリのツリーを直接列挙すべきであり、IT部門はGitHubのコード検索やコンテンツAPIに頼るべきではないとも提案しています。
JFrogは次のように提案しています。「許可されていないchore/ci-*およびdeps/upd-*ブランチを削除し、悪意あるワークフローを無効化して、scan-outputという名前の偽のCodeQLアーティファクトを削除してください。hxxp[:]//43[.]228[.]157[.]68:80や関連する悪意あるインフラは、ネットワーク制御で遮断してください」。さらに、「GitHub Actionsのログとランナーを調べ、/tmp/.svc、ipscan、CVE-2026-41940、アーキテクチャ別の/api/dl/<arch>リクエスト、ホスト型またはセルフホスト型ランナーからの異常に広範なスキャンを探してください」としています。もちろん、.napi.cacheの確認も忘れてはなりません。
優先度の高い標的
GitHubリポジトリは人気が高く、今後も攻撃者にとって優先度の高い標的であり続ける可能性が高いとみられます。
ニューヨークに拠点を置く技術コンサルティング会社Tribeca Softechの最高戦略責任者、Aman Mahapatra氏は、今回の攻撃の特徴が、当面のAIを狙う新たな攻撃の方向性を予見させると指摘します。
同氏は次のように述べています。「10年間、サプライチェーンの脅威モデルは、何かをインストールまたは実行したときに悪意あるコードが動くことを前提にしてきました。今回のキャンペーンは、Claude CodeのSessionStartフック、Geminiの設定、CursorのMCP設定とルール、VS Codeのフォルダーオープン時タスクを仕込みます。そのため、開発者がツールでリポジトリを開くだけでペイロードが実行されます。.claude/settings.jsonは新しいautorun.infです」。
Mahapatra氏は続けます。「攻撃者は、トリガーをコードの実行からフォルダーを開く操作へと移しました。サンドボックスから身を隠すよう設計したマルウェアを作り、業界が最後に講じた対策さえ次の標的にしています。インストール時のスキャンを軸にしたサプライチェーン防御は、いまや的外れなタイミングを守っていることになります」。
同氏が特に懸念しているのは、攻撃者が利用したファイルサイズを使った手口です。
Mahapatra氏はこう語ります。「13MBのラッパーは、より粗雑な手口を加えています。GitHubのコード検索がインデックスする上限や、コンテンツAPIが返す上限を超えているのです。このため、初期の分析ではフックは見つかったものの、ペイロードのファイルは空だと結論づけてしまいました。攻撃者は検知ツールのドキュメントを読み込み、その制限を超えるまでファイルを水増ししたのです」。
Dickson Researchの主席アナリスト、Frank Dickson氏は、攻撃者がネイティブアドオンを使った点にも感銘を受けたと話します。
同氏は次のように述べています。「このアドオンはペイロードを一切持たず、CIシステム、コンテナ、小規模な仮想マシン、デバッガー下では実行を拒否します。Windowsでは、WiresharkやProcess Monitorが動いている場合も実行を控えます。スキャナーに見えるのはプレースホルダーだけで、本物は開発者のノートPCに届くのです」。
Dickson氏は、AIに関するリスクの要素は確かにあるものの、それはあくまで二次的な露出であり、攻撃者が有効な認証情報を盗んで初めて問題になると述べました。それでも、エージェント的な取り組みによって状況は悪化しているといいます。
「仕込まれたファイルは、Claude、Gemini、Cursor、VS Code向けの実行フックです。対応するツールでプロジェクトを開くと、ペイロードが実行される可能性があります。日常的な開発作業が起爆装置になるのです。開発者のノートPCには、いわば王国の鍵が入っています。GitHubトークン、npmトークン、クラウドキー、AIプロバイダーの認証情報などです。攻撃者は、それらを求める新たな手口を見つけました」とDickson氏は語ります。「公平を期すなら、これらのフックは欠陥ではなく機能です。根本的な原因は、AIツールではなく盗まれた認証情報にあります。それでも、フォルダーを開いたときにコードを実行する機能は、ビルドスクリプトと同じ精査に値します」。
この記事は、もともとInfoWorldに掲載されたものです。
