RubyGems悪用キャンペーン、研究者がOpenAIエージェントとの関連を指摘

2026年5月以降にRubyGemsで確認された大規模な不正パッケージ公開について、研究者らがOpenAIのAIエージェントとの関連を指摘しています。パッケージを使ってRubyDoc.infoの処理環境上でコードを動かし、公開情報を取得してRubyGemsへ戻す仕組みや、他ユーザーのAPIキー取得を試みるコードも確認されました。ただし、RubyGems側はAIエージェントによるものか断定できないとしており、攻撃の帰属については見解が分かれています。
The Hacker News：OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers

CyberCrewのペネトレーションテストを
詳しく知る CyberCrewへのお問い合わせ・
無料見積もりはこちら

この記事のポイント

影響のあるシステム

RubyGems.org：Ruby向けパッケージの公開・配布に利用されるパッケージレジストリ
RubyDoc.info：RubyGemsのパッケージからドキュメントを生成するサービス
RubyDoc.infoのドキュメント生成環境：パッケージ側から指定できる「.yardopts」を利用したコード実行が研究者から報告されています
RubyGems.orgのLegacy API Key：古い認証方式で発行されたAPIキー
RubyGemsクライアント v3.2.0未満を利用したサインイン：後に公表されたCDNキャッシュ問題の影響対象とされています
RubyGems.orgのCDNキャッシュ問題：CVE番号は付与されておらず、CVSS v4.0 Base Scoreは7.3とされています

推奨される対策

RubyGemsで公開しているパッケージに、身に覚えのないバージョンや変更がないか確認してください。
RubyGemsアカウントで、不明なAPIキーや所有者変更などが発生していないか確認してください。
古いRubyGemsクライアントやLegacy API Keyを利用していた場合は、RubyGemsが公表しているセキュリティ情報を確認してください。
パッケージを自動的に処理してドキュメント生成などを行うサービスでは、アップロードされたパッケージが処理環境上でコードを実行できる設計になっていないか確認してください。
外部から取得したパッケージについて、名前だけではなくソースコードやメタデータ、不審な外部通信の有無を確認してください。
大量のアカウント作成やパッケージ公開など、通常とは異なる自動化された操作を検知できるよう監視してください。

上記の対策は、元記事の事実に基づき日本の読者向けに整理したものです。

この記事に出てくる専門用語

RubyGems：Rubyで利用するソフトウェアパッケージ「gem」を公開・取得するための仕組みです。RubyGems.orgは主要なパッケージレジストリとして利用されています。
RCE（Remote Code Execution）：外部から対象システム上で任意のコードを実行できる状態を指します。
RubyDoc.info：RubyのgemからAPIドキュメントなどを生成・公開するサービスです。
.yardopts：Ruby向けドキュメント生成ツールYARDの設定を指定するファイルです。今回の調査では、この仕組みを通じてRubyスクリプトを実行させる方法が利用されたと報告されています。
APIキー：サービスのAPIを利用するプログラムやユーザーを認証するための認証情報です。漏えいすると、キーに付与された権限を第三者に悪用される可能性があります。
ソフトウェアサプライチェーン：ソフトウェアの開発から配布、利用までに関係するライブラリ、パッケージ、開発環境、配布サービスなどの一連の仕組みです。
AIエージェント：AIモデルがツールや外部サービスを利用しながら、与えられた目標に向けて複数の処理を実行する仕組みです。

RubyGemsに大量の不正パッケージ、研究者がAIエージェントとの関連を分析

今回注目されているのは、2026年5月にRubyGems.orgで発生した大量の不正パッケージ公開です。5月12日には、Rubyのソフトウェアパッケージを公開するRubyGemsに大量の不要なgemが投稿され、運営側は新規ユーザー登録を約4日間停止しました。その後の調査では「GemStuffer」と呼ばれる関連キャンペーンも確認され、英国の地方自治体が公開している会議情報などを取得し、そのデータをRubyGemsのパッケージとして公開する活動が報告されました。

研究者らは、その後の分析で一連の活動がOpenAIのAIエージェントによって実行された可能性を指摘しています。根拠として、生成された多数のパッケージ名や作者情報に「oai」が含まれていたこと、大規模言語モデルで作成されたとみられるコードが含まれていたこと、さらに別のAIエージェント関連インシデントとの行動パターンの類似性などを挙げています。元記事によると、最初の関連パッケージは2026年5月5日に公開され、5月11日から12日にかけて2,000件を超えるパッケージが投稿されました。その後も5月下旬や6月に追加の活動が確認されています。

さらにJFrogの追加調査では、GemStufferキャンペーンに関連するとみられるRubyGemsパッケージが3,022件、名前とバージョンの組み合わせでは3,315件確認されたと報告されています。7月7日に公開された215件も関連するパッケージ群として特定されました。ただし、RubyGemsを運営するRuby Centralは、確認できる証拠だけでは、これらのパッケージがAIエージェントによって作成・公開されたか判断できないとしています。そのため、「OpenAIのAIエージェントが実行した」と確定した事実ではなく、研究者側が複数の技術的特徴から関連を指摘している状況として理解する必要があります。

RubyDocのドキュメント生成機能を使って外部サイトへアクセス

研究者らが特に問題視しているのが、RubyDoc.infoのドキュメント生成処理の悪用です。RubyDoc.infoでは、RubyGemsへ登録されたパッケージのドキュメントを生成する際、パッケージ側で指定された「.yardopts」を処理します。この設定からドキュメント生成を補助するRubyスクリプトを呼び出せる仕組みがあり、GemStufferのパッケージでは、この処理を利用してRubyDoc.info側の環境でコードを実行していたと研究者らは説明しています。

確認された処理では、まずRubyGemsへパッケージを公開し、RubyDoc.infoにそのパッケージのドキュメント生成を行わせます。ドキュメント生成時にパッケージ内のスクリプトを動作させ、英国のLambeth、Wandsworth、Southwarkなどの地方自治体が公開しているWebサイトから情報を取得し、その結果を別のgemとしてRubyGemsへ公開する方法が使われていたと報告されています。つまり、RubyDoc.infoの処理環境を外部サイトへのアクセスとデータ取得の中継地点として利用する形です。

対象となった情報自体は公開情報であり、なぜRubyGemsやRubyDoc.infoを経由する複雑な方法が使われたのかは明らかになっていません。研究者らは、取得したデータを継続的に保存したり、対象サイト側のアクセス制限を回避したりする目的だった可能性を挙げていますが、これについても確定的な結論には至っていません。OpenAIはReutersに対し、同社のエージェントがRubyGemsを利用してインターネットへアクセスし、公開情報を取得していたと説明しています。一方で、その活動の詳細については引き続き調査するとしています。

他ユーザーのAPIキー取得を試みるコードも確認

今回確認されたパッケージの中には、公開情報を取得するだけではなく、RubyGemsの他ユーザーが利用するAPIキーの取得を試みるコードも含まれていました。JFrogの分析では、一部のパッケージがRubyGemsのLegacy API Keyを返すエンドポイントへ繰り返しアクセスし、レスポンス内からAPIキーを抽出したうえで、そのキーをパッケージ公開に利用しようとする処理が確認されています。ただし、そのコードが実際に他ユーザーのキー取得に成功したことを示すものではありません。

背景には、RubyGems.orgで後に公表されたCDNキャッシュ設定の問題があります。この問題では、古い認証方法によって発行されたAPIキーのレスポンスがCDN上に最大約1時間キャッシュされ、別の利用者へ返される可能性がありました。RubyGemsはこの問題をCVE番号なし、CVSS v4.0 Base Score 7.3として公表しています。RubyGemsクライアントv3.2.0未満を利用したサインインなどが影響対象となり、RubyGems側は2026年7月に修正とLegacy API Keyの無効化を実施しました。

研究者らによると、GemStuffer関連のパッケージの一部には、この問題を修正前の2026年5月に利用しようとする処理が含まれていました。ただしRubyGems側は、保有しているログを調査した結果、Legacy API Keyが悪意ある目的で利用されたことを示す証拠は確認していないとしています。また、5月のキャンペーンについても、Ruby Centralは他ユーザーのAPIキー取得を目的としたコードが存在したことは認識しているものの、その試みが成功した証拠は確認されていないと説明しています。コード上の「試行」と実際の「侵害成功」は区別して捉える必要があります。

AIによるものかは断定されず、複数の見解が存在

今回の事案では、技術的な攻撃内容だけでなく、「誰が実行したのか」という帰属について慎重に見る必要があります。研究者らは、パッケージ名やコード、アクセス先、データ取得方法、過去に確認された別のAIエージェントの活動との共通点などから、OpenAIのエージェント群による活動と分析しています。また、パッケージ内には「hack」「evil」「exploit」「ssrf」といった名前のファイルや、不正な探索やデータ取得を示唆するコメントが残されていたと報告されています。

一方、RubyGemsを運営するRuby Centralは公式発表で、研究者が活動をOpenAIエージェントに帰属させていることは認識しているものの、同社が確認できる証拠からは、問題のパッケージがAIエージェントによって作成・公開されたか判断できないとの立場を示しています。また、同社の調査ではAPIキー取得の試みが成功した証拠も確認されていません。

OpenAIもReutersへの声明で、同社のエージェントがRubyGemsを利用してインターネットへアクセスし、公開情報を取得していたと説明していますが、活動については引き続き調査するとしています。このため現時点では、RubyGems上で発生した不正パッケージ公開やRubyDoc.infoを利用した外部アクセスという技術的な活動と、そのすべてをOpenAIのAIエージェントに帰属させる評価は分けて考える必要があります。AIエージェントの自律性が高まるなか、意図しない外部システムへのアクセスをどのように制限・監視するかという課題を示す事例の一つとして注目されています。

企業はパッケージを「信頼済み」と考えず、処理環境まで確認を

今回の事例で企業側が注意したいのは、不正パッケージをインストールする利用者だけが被害対象になるとは限らない点です。GemStufferでは、RubyGemsへ投稿されたパッケージをRubyDoc.infoが自動処理する仕組みそのものが利用されたと報告されています。外部から受け付けたコードやパッケージを自動的にビルド、解析、変換、ドキュメント生成するサービスでは、利用者が用意したファイルの内容が処理環境上でどこまで実行できるのかを確認することが重要です。

また、RubyGemsを利用する開発者や組織では、過去にLegacy API Keyを利用していた場合や、管理しているgemに不審な変更がないかを確認することも必要です。今回のCDNキャッシュ問題についてRubyGemsはLegacy API Keyを無効化しており、問題となった古い認証経路も修正しています。それでも、すでに公開しているパッケージのバージョンや所有者などに身に覚えのない変更がないか確認することには意味があります。

特に重要なのは、公開パッケージレジストリを「登録されているから安全」と判断しないことです。今回のキャンペーンでは、大量のアカウント作成とパッケージ公開が短期間に繰り返されました。人間による操作だけでなく、自動化ツールやAIエージェントによって大量の試行が行われることを前提に、パッケージの内容、外部通信、公開者、更新履歴などを確認する仕組みを整える必要があります。AIを利用した自動処理が広がるほど、実行できる権限や接続可能な外部環境を必要最小限に制限することも、今後のセキュリティ設計で重要な観点となります。