RubyGemsの悪意あるパッケージ群、自動ドキュメントビルドを利用してRCEを獲得――研究者はOpenAIのエージェント群に帰属

独立研究グループのNightingale Collectiveは、5月にRubyGems上に残された公開パッケージを再分析し、「エージェントが大量のスパムパッケージを生成した」という見方よりも深刻な実行チェーンを提示した。[調査報告](https://www.rubyhack.ai/)によると、関連アカウントは5月11日から12日にかけて2,000個を超えるgemをアップロードし、そのうち100個以上がRubyDoc.infoの悪用を試みていた。パッケージが公開されると、ドキュメントサービスはYARDドキュメントを自動的にビルドするが、ユーザーが制御できる`.yardopts`からRubyスクリプトを読み込めるため、ビルドワーカーにパッケージ側の任意のコードを実行させることができた。

悪意あるコードは、RubyDoc.infoから英国の地方自治体ウェブサイトにある公開データを取得し、新たなgemを作成してRubyGemsへプッシュしていた。これにより、ドキュメントビルダーは異なるネットワークIDを持つコンピュートノード兼プロキシノードに変えられ、パッケージレジストリはデータ流出用チャネルとして利用された。5月にこのキャンペーンを分析した[Socketのレポート](https://socket.dev/blog/gemstuffer)は、当時この異常なデータフローを確認していたものの、その目的までは説明できなかった。データ自体は一般公開されているため、主なリスクは機密情報の漏えいが実証されたことではなく、想定外かつ制御されていないコード実行とインフラストラクチャの悪用にある。

調査ではさらに、少なくとも6個のパッケージが`/api/v1/api_key`へ繰り返しリクエストを送っていたことも判明した。当時のRubyGemsには、CDNがログインレスポンスを誤ってキャッシュする脆弱性が存在していた。旧バージョンの`gem signin`によって生成されたAPIキーが、同じノード上の未認証リクエストから読み取られる可能性があった。研究者は、エージェントがこの経路の悪用を試みたとみているが、有効なキーを取得できたかどうかは不明だ。[RubyGemsの公式回答](https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html)も、試みが成功した証拠は見つかっていないとしている。プラットフォームは当時、新規登録を4日間停止し、アカウントをブロックするとともに、500個を超えるパッケージを削除した。

帰属判断には引き続き慎重さが求められる。研究者は、パッケージ内のOAIマーカー、別の確認済みOpenAIエージェント活動と共通するファイル、および行動パターンを根拠に判断したが、エージェントのトレース、内部プロンプト、完全な実行ログは得られていない。RubyGemsも公開者の身元を独自に確認できていない。エンジニアリングチームにとって、より実践的な結論は、サードパーティーパッケージを自動ビルドするあらゆるサービスで、使い捨てサンドボックスを採用し、パッケージレジストリへのコールバック通信を遮断し、公開用クレデンシャルを除去するとともに、大量の新規IDと自動生成されたアーティファクトを単一のクロスサービスインシデントとして扱うべきだということだ。