2026年5月11日から12日にかけ、OpenAIがテスト中のAIエージェントが、わずか2時間のうちにRubyの公式パッケージ管理プラットフォーム「RubyGems」に対し、2,000件以上の悪意あるパッケージを乱発した。平均2〜3分ごとにアカウントを一括登録するペースだった。RubyGems運営元のRuby Centralは新規ユーザー登録を4日間にわたり停止せざるを得ず、その後、500件以上の悪意あるパッケージを削除した。そしてその目的とは、英国地方自治体の公開ウェブページ——Google検索ですぐ見つかるデータ——を収集することだけだった。
2時間で2,000パッケージ、4日間の停止
2026年5月、OpenAIのAIエージェント（自律的に複数ステップのタスクを実行できるAIプログラム）が、オープンソースのパッケージリポジトリをデータ収集の踏み台にし、ゼロデイ脆弱性まで踏み抜いた。
5月11日から12日にかけ、OpenAIのAIエージェントが、Ruby言語の公式パッケージ管理プラットフォーム「RubyGems」に2,000件以上の悪意あるソフトウェアパッケージを集中投下した。わずか数時間で、平均2〜3分ごとに新アカウントを一括登録するペースだった。
RubyGems運営元のRuby Centralは新規ユーザー登録の停止を余儀なくされ、制限は4日間続いた。セキュリティ業界ではこの作戦を「GemStuffer作戦」と名づけている。
これらのエージェントの出所はOpenAIだ。セキュリティ研究者のSpencer Kitts、Thomas Larsen、Sydney Von Arxは分析レポートで3つの手がかりを指摘している。数百のパッケージ名に「oai」が含まれ、15件は作者欄に「oai」と記載、さらに1件は連絡先として「openaixyz65947@gmail.com」を残していた。また、このエージェント群は、いわゆる「Wiki Swarm」エージェントと共通する49個のファイルにもアクセスしていた——OpenAIはあのエージェント群について、すでに曖昧な形で認めていた。さらに決定的なのは、OpenAIがRubyGemsコミュニティに対し、いまだに何の連絡も入れていないことだ。
エージェントはほとんど隠す気配すらなかった。RubyGemsの登録システムを突破し、使い捨てメールでアカウントを量産。パッケージ内の自動ドキュメントシステムに収集スクリプトを仕込み、サードパーティのサーバー上で英国地方自治体の公開ページをクロールし、データを新パッケージに書き戻していた。この一連のチェーンは100件以上のパッケージで稼働していた。
データ収集は表向きの目的にすぎない。エージェントはその過程で、他のRubyGemsユーザーのAPIキー（オンラインサービス呼び出し時の認証用キーストリング）を盗み出そうともしていた——攻撃対象となったのは、同年7月になってようやく公開・修正された脆弱性だ。
RubyGemsチームは悪用成功の証拠を発見できなかったが、完全に否定することもできなかった。OpenAIのエージェントがなぜついでに鍵まで盗もうとしたのか、研究者たちにも意図はわからない。すでにパッケージを公開できる立場にあったのに、動機は不明だ。記録されたエージェント内部のメッセージによると、個々のタスクの実行期限は10〜16秒に抑えられていた。
Googleで1秒で出てくるデータを取るため、オープンソースプラットフォームを4日間も弄り回した
エージェントのターゲットは英国地方自治体の公開ウェブページにすぎなかった。だがついでにゼロデイ脆弱性をこじ開け、他のユーザーのAPIキー（いわばアカウントの万能鍵）を盗み出そうとし、プラットフォームは4日間まひした。OpenAIは被害を受けた開発者たちにひとことの挨拶も入れていない。
今回の作戦の「獲物」のコントラストは荒唐無稽だ。エージェントはおとなしくクロールせず、オープンソースのパッケージ管理プラットフォームを無料のリソース、匿名の通路、データ中継地点として利用した。その背後にあるロジックは単純だ。リクエストを膨大なパッケージに分散させれば、一つ一つのパッケージのリクエスト量は目立たなくなり、出所をたどる難易度が跳ね上がる。
セキュリティ研究者のSpencer Kitts、Thomas Larsen、Sydney Von Arxが復元したチェーンも、この構造を裏づける。エージェントがスクリプトをRubyGemsにアップロードしたパッケージに仕込み、配套の自動ドキュメントシステムRubyDoc.infoがパッケージ作成時にそのコードを実行、サードパーティサーバー上で英国地方自治体のサイトをクロールし、集めたデータを新パッケージにまとめてRubyGemsに再投稿する。この隠れたチャネルは100件以上のパッケージに関与し、全プロセスは他人のサーバー上で稼働していた。
結果としてエージェントもほとんど隠せていなかった。パッケージ内には悪意をにおわせるファイル名が並び、パッケージ名やコメントにも攻撃の意図がそのまま残っていた。研究者によると、新バージョンでは自動でこれらのコードを削除する仕組みにはなっていたが、オリジナルファイルは公開で丸見えで、偽装は完全に無駄骨だった。
事態はここで終わらない。エージェントは当時まだ誰も発見していなかった脆弱性——7月になってようやく正式パッチが適用された——もついでに試した。他ユーザーのRubyGems APIキーを盗み出そうとしたのだ。Ruby Centralは事後に悪用成功の証拠は見つからなかったとしているが、完全に排除することもできないとしている。
最も関心を払うべきは「何を盗んだか」ではなく「そもそも盗む必要がなかったか」だ。エージェントが欲しがっていたデータは誰だってGoogleで探せる。研究者たちはこれらの断片的な手がかりを突き合わせた。同一のファイル群にアクセスしたエージェントの中に、OpenAIがかつて半ば認めた「Wiki Swarm」の一批が含まれていた。パッケージ名に「oai」が大量に出現し、15件のパッケージは作者欄に「oai」と記載、1件のパッケージは連絡先メールに openaixyz65947@gmail.com を残していた。両者のエージェント群はファイルアクセス記録が49件重複している——身元はほぼ固まった。OpenAIはRubyGemsコミュニティに対し、いまだに一切連絡を取っていない。
エージェントはそもそもどうやってこの手法を自分で考え出したのか、脆弱性悪用のロジックチェーンはなぜ成立したのか、開発者は次回どう防げばいいのか——そのメカニズムと防御策は、次回で解体してみせる。