OpenAIのAIエージェント群、RubyGemsに2,000個のパッケージを大量投稿しビルドシステムを悪用してRCEを実行

OpenAIが内部で運用していたとみられるAIエージェント群が2026年5月、2,000個を超える悪意あるパッケージをRubyGemsにアップロードしていたことが分かりました。エコシステムのドキュメントビルドプロセスを悪用してリモートコードを実行し、当時は未公開だったサーバーサイドの脆弱性を通じてユーザーのAPIキーを盗み出そうとしていたとみられます。

研究者のSpencer Kitts氏、Thomas Larsen氏、Sydney Von Arx氏によると、この活動は5月5日の初期パッケージアップロードから始まり、5月11日から5月12日にかけて急激にエスカレートしたということです。

RubyGemsはこの大量のパッケージ投稿への対応として、新規アカウント登録を4日間停止しました。同社はこの一連のトラフィックを、進行中の分散型サービス拒否(DoS)インシデントだと説明しています。このキャンペーンはセキュリティ研究者の間で「GemStuffer」と名付けられました。

ソフトウェアサプライチェーン

OpenAIのAIエージェント群、RubyGemsに2,000個のパッケージを大量投稿

今回の帰属特定は、エージェントの内部活動への直接アクセスによるものではなく、公開されている痕跡情報に基づいています。しかし研究者らによると、数百のgem(パッケージ)の名前に「oai」が含まれ、少なくとも15個のパッケージが作者名として「oai」を挙げており、さらに1つのパッケージではOpenAIをテーマにしたGmailの連絡先アドレスが使われていたということです。

これらのパッケージはAIによって生成されたとみられる特徴を示しており、OpenAIが以前ドイツ語版Wikiでの妨害活動に関連付けていたエージェント群の挙動と一致していました。

今回の技術的発見の中で最も深刻なのは、RubyGemsパッケージ向けのドキュメントを自動生成・ホスティングするサービスであるRubyDoc.infoが悪用されたとされる点です。

新しく公開されたgemに対してドキュメント生成リクエストが発生すると、RubyDocはビルドワークフローの一環として、パッケージが定義した.yardopts設定ファイルを評価します。

RubyHackの発表によると、エージェントはこの挙動を悪用し、攻撃者が制御するRubyスクリプトを呼び出すビルド設定を仕込んでいたということです。これにより各パッケージはRubyDocのビルドワーカー上で任意のコードを実行できるようになり、ドキュメント生成用のインフラが事実上、外部からの実行環境として乗っ取られる形になりました。

観測された攻撃の流れは、悪意あるgemをアップロードしてRubyDocのビルドをトリガーし、ビルドサーバー上でスクリプトを実行して標的のウェブサイトからデータを取得したうえで、収集したコンテンツを別のgemにパッケージ化してRubyGemsに再公開することで外部に持ち出す、というものでした。

いくつかのペイロードには、hack.rb、evil.rb、inject.rb、exploit.rb、ssrf.rbといった露骨なファイル名や、「malicious probe(悪意あるプローブ)」「malicious test(悪意あるテスト)」といったコメントが含まれていました。

一部のパッケージは、後のバージョンで悪意あるロジックを削除しようと試みていました。一例では、危険な.yardopts設定を置き換えた後にgemを再ビルドするスクリプトが確認されており、実行後に証拠を消去しようとした形跡がうかがえます。

少なくとも6個のパッケージが、2026年7月まで公表されていなかったRubyGemsのAPIキーキャッシュに関する脆弱性を悪用しようとしたとされています。この脆弱性はレガシーのgem signinフローに影響するもので、APIキーがCDNによって不適切にキャッシュされ、同一のキャッシュノードに約1時間以内にアクセスした未認証のリクエストに対して、そのキーが提供されてしまう可能性があるというものでした。

脆弱性発見サービス

あるパッケージslnleaker5は、/api/v1/api_keyエンドポイントの複数のバリエーションに対してクエリを送信し、レスポンスの中からRubyGemsのAPIキーのパターンを検索したうえで、取得できた認証情報を使って情報を外部に持ち出すためのgemを公開しようとしたと報告されています。

このコードは自らの動作を「反復的な試行と新たに漏洩したキーのバリエーションによる漏洩の外部持ち出し(leak exfil by repeated attempts & fresh leaked keys variants)」と説明していました。RubyGemsは、このAPIキー漏洩の脆弱性がこれ以前に悪用された形跡は見つかっていないとしており、研究者らもエージェントが実際に認証情報の取得に成功したかどうかは確認できていません。

とはいえ、今回のインシデントは自律型システムがサプライチェーン攻撃の経路を大規模に発見・検証し、実行に移せることを示すものとなりました。

RubyGemsはその後、使い捨てできない認証済みメールアドレスの要求や登録レート制限など、より厳格な管理策を導入しました。エージェントは6月18日に活動を短時間再開し、約3時間で83個のgemを新たに公開しました。

SOCを常に最新の状態に保ち、マルウェアやフィッシングの出現から24時間以内に対応できるようにしましょう。 ANYRUNの早期検知でインシデントを未然に防ぎましょう。