Megalodonが6時間でGitHub Actionsを5,561リポジトリの裏口に変えた

自動化されたキャンペーンが、5月のある月曜の朝、6時間で5,561のGitHubリポジトリに5,718のコミットを送り込んだ。コミットは通常のCIメンテナンスのように見え（「ci: add build optimization step」「build: improve ci performance」「chore: optimize pipeline runtime」）、build-bot、auto-ci、pipeline-botといった目立たない名前の作者から届いていた。5月18日の午前が終わるころには、それらのリポジトリの一つひとつに、base64でエンコードされたbashペイロードを内側に抱えたワークフローファイルが置かれていた。

キャンペーン名はMegalodon。SafeDepの調査チームは5月21日、コミットを分解し、痕跡をたどって216.126.225.129:8443にある単一の指令統制サーバーへ行き着いた上で公表した。注目すべきはGitHubが攻撃されたことではない。注目すべきは、攻撃者がGitHub本体を侵害する必要が一切なかったということだ。攻撃者は、コードの完全性を担保するために設計されたCI/CDシステムであるGitHub Actionsそのものを、裏口配送の手段として使った。

大量型と休眠型、二つのワークフロー

Megalodonは二つのモードで動いた。大量型のSysDiagは新規のワークフローファイルを追加し、pushとpull requestのたびに発火して、そこを通る一切を持ち去った。標的型のOptimize-Buildはもっと辛抱強い。既存のワークフローを、誰かが手動で呼び出すまで眠り続けるworkflow_dispatchトリガーに置き換えた。プロジェクトのCIディレクトリで眠る裏口は、SysDiagという新顔のワークフローよりはるかに気づきにくい。多くのメンテナは、自分がかつて書いたファイルを再監査しないからだ。

ワークフローが走ると、ペイロードはCI環境で届く範囲のすべてを読み取る。CIの環境変数。AWSのアクセスキー、シークレットキー、セッショントークン。GCPのアクセストークン。SSHの秘密鍵。.npmrcの資格情報。Docker設定。Kubernetes設定。GitHub ActionsのOIDCトークンは、攻撃者がそのワークフロー自身として、認可されたあらゆるクラウドアカウントになりすますことを可能にする。終了する前にペイロードは、リポジトリのソースコードから30種類以上のシークレットパターン（APIキー、パスワード、証明書の断片）をgrepする。人間が貼り付けてしまった一片を取り逃さないためだ。AWS IMDSv2、GCP、Azureのメタデータエンドポイントにも、クラウド上のマシン身分を得るために問い合わせる。

自分の裏口を出荷するパイプライン

今のところ最も深刻な被害者はTiledeskだ。オープンソースの顧客エンゲージメント基盤で、9つのGitHubリポジトリを直撃された。5月19日から21日にかけて、Tiledeskは裏口を組み込んだままtiledesk-serverパッケージをnpmに公開した。@tiledesk/tiledesk-serverの2.18.6から2.18.12までのバージョンはいま、その窓の中でnpm installを走らせたすべての下流開発者にインストールされた、ペイロードコードを抱えている。これこそMegalodonが狙ったテコだ。たった一つのオープンソースプロジェクトに裏口を仕込み、そのリリースパイプラインに依存先の数百のプロジェクトへ裏口を撒かせる。

Black-Iron-Projectは8つのリポジトリを失った。より小さなプロジェクトの数百個（個人開発者のアカウント、大学のクラスタ、放置されたサンドボックス）が一つか二つずつ食らった。攻撃者は的を選んでいる様子はなかった。模様は精度より広さ。八文字のランダムなユーザー名の使い捨てアカウントが、分刻みに同じコミットメッセージを押し込んだ。C2サーバーは戻ってくるものを静かに記録した。

CIファイルが監査を生き延びた理由

この攻撃が成功した理由は、2026年の残りで再演される理由でもある。CI/CDパイプラインは設計上、信頼の上に成り立っている。ダウンロード中の見慣れないバイナリには疑いを向ける開発者が、先週リポジトリに届いたワークフローファイルは何の躊躇もなく走らせる。なぜならワークフローファイルとはまさにそういうものだからだ。プラットフォームが走らせるはずのコード。監査ログはあるが、ほとんどのチームは読まない。新しいコミットはbuild-botやci-botのような名前で届く。差分は小さい。ワークフロー末尾のbase64文字列は、意図的に不透明だ。

防御の手順は単純で、しかも気持ちのよくないものだ。5月18日から今までにリポジトリに触れたあらゆる秘密をローテーションする。管理下のすべてのプロジェクトの.github/workflowsディレクトリを監査する。作者メールが既知のメンバーと一致しないコミットを点検する。Actionsファイル内のbase64ブロブは、復号されるまで有罪と扱う。Tiledeskを使う組織は2.18.5にダウングレードするか、クリーンなリリースを待つべきだ。Actionsとクラウドプロバイダの間にOIDC信頼を持っているなら、その信頼関係を取り消し、発行し直すべきだ。

Megalodonはこの規模で初めて、CIワークフローそのものを柔らかい標的として扱ったキャンペーンだ。最後ではないだろう。この攻撃が置いていく教訓は、開発者が以前より静かな声で聞いたことのあるものだ。パイプラインのうち読んでいない部分は、攻撃者があなたに代わって書いてくれている部分だ。