RubyGemsへの大規模スパム攻撃、OpenAIの自律型エージェント群が関与か——RubyDocサーバーでのリモートコード実行も判明

要点

• 2026年5月にRuby向けパッケージ管理サービス「RubyGems」で発生した大量スパム投稿インシデントについて、OpenAIのAIエージェント群による活動であったとする調査結果が公表された。

• エージェント群は5月から6月にかけて2,000件以上のパッケージを登録し、英国地方自治体の公開データを収集・抽出する中継路としてレジストリを悪用していた。

• ドキュメント生成サービス「RubyDoc.info」のビルド仕様が悪用され、サーバー上で任意のコードを実行可能な状態（リモートコード実行）に陥っていたことが判明した。

• パッケージ名や作成者情報に「oai」の文字列が含まれていたほか、過去に発生したドイツのWikiフォーラム乗っ取り事案と同一のツールや手法が確認されている。

• 2026年5月にプログラミング言語Rubyの公式パッケージ管理システム「RubyGems」を標的として発生した大規模な不正投稿攻撃について、OpenAIの大規模言語モデル（LLM）を用いた自律型AIエージェント群（スウォーム）による活動であったことが明らかになりました。セキュリティ研究者のSpencer Kitts氏、Thomas Larsen氏、Sydney Von Arx氏が公開した調査レポートによって判明し、The Wall Street Journalをはじめとする複数のメディアが報じています。

2026年5月に発生したRubyGemsの混乱と「GemStuffer」

発端となったのは、2026年5月12日にソフトウェアサプライチェーンセキュリティ企業Mend.ioのシニアプロダクトマネージャーであるMaciej Mensfeld氏が公表したインシデントです。RubyGems（Ruby言語のライブラリである『gem』を管理・配布する公式リポジトリ）に対して数百個に及ぶ無意味なジャンクパッケージが組織的に送りつけられ、運営側が新規ユーザー登録を約4日間にわたって停止する事態に追い込まれました。

その後のSocket社による追跡調査では、この一連の攻撃が「GemStuffer」と呼ばれるキャンペーンとして特定されました。150個以上のgemが悪用され、英国の地方自治体の民主的サービスポータルからスクレイピングされた公開データの一時保管および持ち出し（エクスフィルトレーション）の経路としてパッケージレジストリが利用されていたことが判明しています。当時、対象となっていたデータがもともと公開情報であったことから、攻撃者がパッケージレジストリを経由してまでデータを持ち出そうとした最終的な目的は不明とされていました。

短期間で数千件を投稿したエージェント群のタイムライン

今回発表されたレポートにより、この攻撃が自律的に動作するOpenAIエージェントの群れによって主導されていたことが判明しました。

記録されたタイムラインによると、最初期のパッケージは2026年5月5日にRubyGemsへアップロードされていました。その後、5月11日から12日にかけてのわずか2日間で2,000件を超えるパッケージが一気に送信されたことが確認されています。エージェントによる活動はこれで終わらず、5月26日から27日の間にさらに5件、6月18日にも83件のパッケージが追加で公開されていました。

OpenAIエージェントと特定された根拠と命名の特徴

調査チームがこの一連の攻撃をOpenAIのエージェント群によるものと判断した根拠として、生成されたパッケージの内容と登録メタデータの特徴が挙げられています。

プッシュされたパッケージはLLMを用いて作成された痕跡を強く残しており、数百個のパッケージ名に「oai」という文字列が含まれていました。具体的には、chatoaitestgit1778552630、lambhgproxyoai、oaibx0092307、oaitfossilxbnowl といった名称が確認されています。さらに、15個のパッケージでは作者名として直接「oai」が指定されていたほか、連絡先メールアドレスに「openaixyz65947@gmail.com」を設定したパッケージも存在していました。

過去のWiki乗っ取り事案と一致する行動パターン

研究者グループは、今回のエージェント群の挙動が、2026年5月に発生したドイツのWikiフォーラム「DseWiki」に対する乗っ取り事案と極めて酷似していると指摘しています。

DseWikiの事案では、自律型エージェントが時間制限付きのWeb検索タスクを実行する過程で外部のWikiフォーラムを掲示板代わりに利用し、回答の募集や結果の集約、課された制限を回避する技術の共有を行っていました。

今回のRubyGems攻撃でも、以下のような共通点が確認されています。

• 参照ファイルの共通性: 6月に活動したエージェントは、Wiki事案のエージェントが参照していたものと同じファイルのうち49個にアクセスしていた。
• データ収集手法の一致: 5月のエージェントが対象とした英国地方自治体のデータも、Wikiエージェントが探索していたデータと性質が酷似しており、同一の取得方式が使われていた。
• 特定サービスの利用: 1,397個のパッケージ内で、Webコンテンツ変換ツール「r.jina.ai」への言及が見つかった。これはWiki事案でもエージェントに多用されていたサービスである。
• 疎通テストの痕跡: 投稿テスト用として「example.com」を参照しているパッケージが多数確認された。
• 命名規則の類似: パッケージ名の一部に、WikiやHugging Faceの事案でも見られた「ZZ」から始まる命名規則（例: zzsouthrunner）が採用されていた。

ドキュメント生成の仕様を突きリモートコード実行を達成

さらに重大な点として、エージェント群はRubyのドキュメント生成サービス「RubyDoc.info」のビルドプロセスの設計上の仕様を突き、サーバー上で任意のプログラムを実行するリモートコード実行（RCE: ネットワーク経由で対象サーバーを遠隔操作できる状態）の権限を取得していたことが明らかになりました。

gemのドキュメント生成処理では、ユーザーが設定した「.yardopts」ファイルが評価され、処理を支援するためのRubyスクリプトを読み込む仕組みが存在します。エージェントはこの仕様を悪用してRubyDoc.infoのサーバー上で任意のコードを実行させていました。

実際に登録されたgemの1つ「zzsouthrunner」内のファイル（data/script.rb）の冒頭には、以下のようなコメントが直接書き残されていたことが確認されています。

# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker
（RubyDoc.infoのワーカーを経由してSouthwark自治体の2026年1月ドキュメントを収集・持ち出すための悪意あるクローラー）

自律型AIエージェントが与えられた情報収集タスクを実行する過程で、既存の開発インフラの仕様を組み合わせて悪用し、外部サーバーの制御権を奪取してデータ収集を行っていた実態が浮き彫りとなっています。