GitHubがShai-Hulud亜種を可能にする設計上の欠陥報告を「対象外」として却下|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年06月19日更新日時: 2026年06月19日

脅威インテリジェンス企業Deep Specter Researchが提出した2件の正式な脆弱性報告を、GitHubが「対象外（ineligible）」「セキュリティリスクではない」として却下していたことが明らかになりました。

これらの報告は、自己増殖型サプライチェーンワーム「Shai-Hulud」の亜種が世界中で数百件のソフトウェアパッケージと開発者アカウントへの感染・侵害を可能にしている設計上の欠陥を指摘するものでした。Shai-Huludはサイバー犯罪グループ「TeamPCP」が開発したツールが原型ですが、2026年5月初旬に元のコードが公開されて以降、わずかに異なるバージョンを使う模倣集団（コピーキャット）が次々と出現しています。

直近数か月でこれらの亜種は、欧州委員会・AI採用企業Mercor・LiteLLMパッケージ・GitHub自身・Red Hatへの侵害に関連付けられています。Deep SpecterはRecorded Future Newsに対し、公開データのみを用いた独自調査により、npm・PyPI・RubyGemsを含む5つのエコシステムで516件の悪性パッケージが現在も稼働中であり、3,000件超のGitHubリポジトリ・200件超の開発者アカウントが侵害されたことを確認したと述べています。本記事ではGitHubが却下した2件の報告の内容・その判断の妥当性・Shai-Huludの技術的な進化・組織が今すぐ取るべき対応を解説します。

サマリー

報告者：脅威インテリジェンス企業 Deep Specter Research
報告先：GitHubの脆弱性開示チャネル（HackerOne経由のバグバウンティプログラム）
報告内容：Shai-Hulud亜種の感染拡大を可能にしている2件の設計上の欠陥
GitHubの対応：両報告とも「対象外（ineligible）」「セキュリティリスクなし」として却下
Deep Specterが確認した被害規模（公開データのみによる独自調査）：
- 現在も稼働中の悪性パッケージ：516件
- 影響を受けたエコシステム：5つ（npm・PyPI・RubyGemsを含む）
- 影響を受けたGitHubリポジトリ：3,000件超
- 侵害された開発者アカウント：200件超
これまでに関連が指摘された侵害先：欧州委員会・AI採用企業Mercor・LiteLLMパッケージ・GitHub自身・Red Hat
Shai-Huludの起源：サイバー犯罪グループ「TeamPCP」が開発。2026年5月初旬に元コードが公開されて以降、模倣集団による亜種が拡散
GitHubが提示した緩和策：GPG/SSHによるコミット署名・オプトイン式の「Vigilant Mode」
重要な事実：Shai-Huludキャンペーンでなりすまされた開発者は、いずれもこれらの緩和策を有効化していなかった

1 GitHubが却下した2件の報告の詳細
2 GitHubの判断は妥当か——バグバウンティ運用方針との関係
3 Shai-Huludとは——進化を続けるサプライチェーンワーム
4 情報システム担当者への教訓——「表示」と「実態」のギャップ対策
5 FAQ
6 参考情報

GitHubが却下した2件の報告の詳細

報告①：コミットタイムスタンプの偽装が可能な問題

GitHubは研究者に対し、「コミットのタイムスタンプはクライアント側が提供するメタデータであり、これは設計上のものである」と説明し、根本的なセキュリティ問題は「タイムスタンプではなく、コードをプッシュするために使われた侵害済みの認証情報そのものにある」と主張しました。

つまりGitHubの立場は、「タイムスタンプが偽装可能であること」自体は問題ではなく、その前段階である「認証情報の窃取」こそが本質的なセキュリティ問題であるという見解です。

報告②：コミット作成者（author）情報の偽装が可能な問題

Deep Specterの2件目の報告は、コミットの「作成者（author）」として表示される情報に関するものでした。GitHubはコミットの作成者の名前・写真・ユーザー名を、あたかも確認済み（confirmed）であるかのように表示しますが、実際にはこれらのフィールドは攻撃者によって自由に設定可能であり、検証されることは一切ありません。

Shai-Huludワームはこの仕組みを悪用し、悪意あるコミットが、実際にはそのコードに一切触れていない信頼された（trusted）エンジニアによって行われたかのように見せかけています。

GitHubはこの報告に対し、「任意の作成者メタデータはgitバージョン管理システムそのものの性質であり、GitHubの脆弱性ではない」と回答し、さらに自社のバグバウンティプログラムの文書において、コミット作成者の偽装は『既知の対象外事項』として明記されていると説明しました。

GitHubが提示した「緩和策」とその限界

GitHubはDeep Specterに対し、利用可能な緩和策として以下を提示しました。

GPG/SSHによるコミット署名
オプトイン式の「Vigilant Mode（厳格モード）」

しかし重要な事実として、Shai-Huludキャンペーンで身元を偽装された開発者は、いずれもこれらの管理機能を有効化していませんでした。 つまり、これらの機能は存在するものの、デフォルトで有効化されておらず、多くの開発者が利用していない実態が今回の感染拡大を許した一因と言えます。

「見えているが、表示されていない」記録の存在

注目すべきは、GitHubが実際に各コミットをどのアカウントがプッシュしたかという、偽装不可能なデータを内部的に記録している点です。この情報はGitHubのEvents APIを通じて取得可能ですが、レビュー担当者が目にするコミットページ上には表示されません。

さらに、この記録は公開から約90日後にビューから消滅します。Deep Specterはこの記録の可視性を向上させることの「セキュリティ上の価値」を提起しましたが、GitHubはこれを「セキュリティ修正」ではなく「機能リクエスト（feature request）」として扱うとの判断を下しています。

GitHubの判断は妥当か——バグバウンティ運用方針との関係

GitHubの判断には一定の文脈があります。GitHub公式ブログ（2026年5月）によれば、同社のバグバウンティプログラムは「品質と責任の共有」を強調する方針へと移行しており、対象外（ineligible）と分類される項目（DMARC/SPF/DKIM設定・ユーザー列挙・実証された攻撃経路のない不十分なセキュリティヘッダー等）への報告が「Not Applicable」として一律に却下される運用が明確化されています。

コミット作成者の偽装についても、HackerOne上のGitHubプログラムページにおいて「既知の対象外事項」として明記されており、個別のバグ報奨金プログラムの運用基準としては一貫した対応と評価できます。

一方で、今回の事案が示す問題は「バグバウンティの個別審査基準としては正しくても、実際に進行中の大規模なサプライチェーン攻撃を可能にしている構造的な欠陥への対応としては不十分」という点にあります。研究者が指摘しているのは単発の脆弱性ではなく、実際の攻撃で悪用され続けている設計上の弱点であり、バグバウンティの「対象外リスト」に該当するという理由だけで本質的な議論を終えてしまうことのリスクが浮かび上がっています。

Shai-Huludとは——進化を続けるサプライチェーンワーム

「Worker」と「Miasma」という2つの株（strain）

Deep Specter Researchの技術分析（Substack「Riding the Sandworm」）によれば、Shai-Huludは現在2つの異なる「株」として活発に進化を続けています。

「classic」Shai-Hulud（Worker型）：使い捨てのリポジトリ上でGitHub Actionsワークフローを通じて難読化されたスクリプトを実行する手法。ペルソナ作成者名「THE ASSET」を使用し、タイムスタンプは実際のものを使用——身元の偽装は行いません。比較的「目立つ（loud）」タイプです。

「Miasma」（インジェクション型）：窃取したメンテナートークンを使い、既存のリポジトリに巨大な.github/setup.jsをコミットする手法。実在するメンテナーになりすまし、さらに**数年単位の遡及的な日付偽装（バックデート）**を行うことで、コミット履歴の中に紛れ込ませます。今回GitHubが却下した2件の報告で指摘された偽装手法は、まさにこの「Miasma」が悪用するメカニズムです。

Deep Specterは「手口は静かで（loud）使い捨てのワーカーから、巧妙で歴史に紛れ込むインジェクションへと進化している。今後の波ではさらに高度な回避策を伴うと予想される。IOC（侵害指標）ではなく、振る舞いで狩るべきだ」と警告しています。

GitHub自体をC2サーバーとして悪用する手口

OX Securityの分析によれば、最新のShai-Hulud亜種はGitHubを単なる「データの投棄先（dead drop）」としてだけでなく、生きたC2（コマンド＆コントロール）サーバーそのものとして悪用しています。攻撃者は窃取した認証情報をアップロードするだけでなく、悪意あるコードそのものをリポジトリに保管し、「firedalazer」という文字列を含むコミットを通じて新しいペイロードを動的に配信する仕組みを構築しています。1つのアカウントがブロックされても、別のアカウントが処理を引き継ぐため、信頼され広くホワイトリストに登録されたプラットフォーム上で動作するアダプティブなC2として機能しているのが実態です。

これまでの主要なタイムライン

時期	出来事
2025年8月27日	S1ngularityキャンペーン（nxパッケージ標的）の報告
2025年9月14〜16日	Shai-Hulud最初の感染波。GitHubが侵害されたメンテナーアカウントを起点と特定。500件超のパッケージをnpmから削除
2025年11月24日	「The Second Coming（再来）」と呼ばれる第2波。npmのトークン失効期限直前を狙うタイミング
2025年12月15日頃	GitHub Actionsワークフローの脆弱性を悪用する、より高度な侵入経路を確認（AsyncAPI・PostHog・Postman等）
2026年5月初旬	元のコード（TeamPCP由来）が公開。これを起点に模倣集団による亜種が拡散開始
2026年6月	欧州委員会・Mercor・LiteLLM・GitHub自身・Red Hatへの侵害に関連付け。Deep Specterが516件の稼働中パッケージを確認

情報システム担当者への教訓——「表示」と「実態」のギャップ対策

今回の事案から、組織のセキュリティ担当者・開発者が今すぐ実施すべき対応を整理します。

① GPG/SSHコミット署名の組織的な強制化

GitHubが提示した緩和策（GPG/SSH署名）は、オプトインであるため有効化されていない場合は無意味です。組織として、すべての開発者にコミット署名を義務化するポリシー・ブランチ保護ルールを設定してください。GitHubの「Require signed commits」設定を有効にすることで、署名されていないコミットのマージを拒否できます。

② 「Vigilant Mode」の有効化

GitHubの「Vigilant Mode」は、署名されていないコミットや検証されていないコミットを視覚的に警告する機能です。組織内の全メンバーに有効化を推奨してください。

③ コミット作成者情報を信頼しない文化の醸成

今回の事案が示す通り、コミットページに表示される作成者名・写真・ユーザー名は検証されていません。「見覚えのある名前のコミットだから安全」という思い込みを排除し、コードレビューにおいては内容そのものの精査を優先する文化を徹底してください。

④ Events APIを活用した実際のプッシュ元の監査

可能であれば、GitHub Events APIを通じて実際にコミットをプッシュしたアカウントの記録を定期的に取得・保存する仕組みを構築してください。デフォルトでは90日でビューから消滅するため、自組織で長期保存する体制が必要です。

⑤ IOCベースではなく振る舞いベースの監視

Deep Specterが警告する通り、Shai-Huludは進化を続けており、固定的なIOC（既知の悪性パッケージ名・ハッシュ等）のみに依存した検知では新しい亜種を見逃します。GitHub Actionsワークフローの異常な変更・予期しないnpm公開・遡及的なコミット日付などの振る舞いパターンに基づく監視を導入してください。

⑥ 自組織で使用するOSS依存関係の継続的スキャン

npm・PyPI・RubyGems等のパッケージマネージャーを通じて導入している依存関係について、サプライチェーンセキュリティツールを用いた継続的なスキャンを実施し、516件の悪性パッケージリストやIOC情報を定期的に参照してください。

FAQ

Q. GitHubは今回の判断について何らかの対応を変える予定はありますか？ A. 本記事執筆時点で、GitHubがDeep Specterの提案（プッシュ元情報の可視性向上等）を将来的に実装する計画があるかどうかは明らかにされていません。GitHubはこれを「機能リクエスト」として扱っており、優先度の高いセキュリティ修正としては位置付けていません。

Q. 自社のリポジトリがShai-Huludの影響を受けているか確認する方法は？ A. Deep Specter Researchの技術分析（Substack「Riding the Sandworm」）に記載されているマーカー（特定のREADME文字列パターン等）を参考に、自組織のリポジトリ・依存関係を確認することを推奨します。サプライチェーンセキュリティベンダー（Aikido・OX Security等）が提供する無料スキャナーの利用も有効です。

Q. なぜGitHub自身もShai-Huludの侵害先として名前が挙がっているのですか？ A. The Recordの報道によれば、GitHub自身もShai-Hulud亜種に関連する侵害に名前が挙がっています。これは大手プラットフォーム自体の従業員・関連プロジェクトのリポジトリも、サプライチェーン攻撃の対象から免れないことを示す事例です。