製品 Lemma API証明の発行・検証の基盤Trust402エージェントに任せ、取引するSeal鍵を渡さない、エージェント時代のサインイン
ユースケース 製造・基幹インフラ検査記録アシュアランス金融・FinTech取引先レコード検証自治体・公共証明書レス手続き医療・ヘルスケア有資格者アシュアランス調達・サプライチェーン仕入先資格モニタリングメディア・コンテンツコンテンツ真正性サービス・小売グループ横断アイデンティティAI導入(業種横断)AI実行ガバナンス開発者・エージェント運用エージェント権限統制 ▸ 業界別ソリューション索引を見る
料金
リソース Critical BriefAI×信頼の最前線ブログ考え方と実装の記録ドキュメントAPI と仕様書検証センター検証・発行の実数運営会社FRAME00, Inc.お問い合わせ導入・取材のご相談用語集言葉の定義FAQよくある質問
ダッシュボード ↗ EN
No. 148 Critical Brief · 来歴証明

RubyGems・RubyDoc.info:大量の新規アカウントが悪性のパッケージを公開し、ドキュメント生成のサーバでコードを実行した(Ruby Central・Nightingale Collective)

500 超件
Ruby Central が削除した悪性のパッケージ
2,000 超件
5 月 11〜12 日に投稿されたパッケージ(Nightingale Collective の集計)
05-12→05-16
RubyGems が新規アカウントの登録を止めていた期間
国・地域国際
事案日2026-05-11
公開2026-09-15
改訂 v2.1 · 2026-11-03
発行Lemma Critical Team
目次
  1. 01要点
  2. 02通った操作
  3. 03実行前の照合
  4. 04Lemma でできること
  5. 05事実と時系列
  6. 06Sources

要点

使われたのは、アカウントの登録、パッケージの公開、ドキュメントの自動生成という、誰でも使える正規の機能の連鎖だけだった。メールの確認を経ないアカウントでも公開の鍵が得られ、公開されたパッケージは RubyDoc.info でふつうのドキュメント生成として扱われ、同梱のスクリプトが外部とつながった環境で動いた。運営元は急増を捉えて数日で封じ込めたが、誰が公開したかは、運営元の記録からは確定できていない。誰でも公開できるパッケージのコードを、ビルドが外部とつながったまま動かすなら、実行を許す前に公開者を照合しなければ、使い捨てのアカウントの公開物も、ふつうの生成として通る。

図表 1「検知」と「実行の前の照合」の違い

実行の前の照合=ビルドが持ち込まれたコードを実行する前に、公開者の資格と許す操作の範囲を照合し、記録に残すこと。検知=登録や投稿が急増した後に、運営元が気づいて止めること。日付は 05 の時系列に拠る。

実行の前の照合 · 公表からは分からない生成の前に、公開者の資格と、許す操作の範囲を照合する
確認されたこと新規アカウントのパッケージが公開された
同梱スクリプトが、外部とつながった生成の環境で動いた
検知 · 急増の後に働いた登録を止め、500 超のパッケージを削除した
2026-05-05
最初のパッケージが投稿される
2026-05-11
2 日で 2,000 件超が投稿される
2026-05-12
新規アカウントの登録を停止
2026-09-11
生成をネットワークから切り離す

通った操作

通った操作
新規アカウントによる RubyGems へのパッケージの公開と、そのパッケージに対する RubyDoc.info のドキュメント生成。生成ツール YARD は、パッケージの .yardopts の指定どおりに同梱の Ruby スクリプトを実行した。生成は Docker コンテナの中で行われていたが、コンテナはネットワークにつながったままだった(Ruby Central・RubyDoc.info の修正記録・Nightingale Collective)。
受け付けた側に届くもの
一般に、レジストリに届くのは、アカウントの API キーと、パッケージの中身で、公開者が誰かは、使い捨てのメールアドレスでも作れるアカウントからは分からない。ドキュメント生成のサービスに届くのは、生成の依頼と、パッケージに同梱された設定とスクリプトである。
届いた範囲
Nightingale Collective の集計では、RubyDoc.info 経由の実行経路を使ったパッケージは 100 件を超え、生成サーバから英国ロンドンの 3 区の議会運営ポータルなどの公開ページを取得し、新しいパッケージとして RubyGems に公開し直していた。少なくとも 6 件は、生成サーバから他のユーザーの API キーを得ようとしていたが、Ruby Central は「成功した証拠は見つからなかった」としている。
公表されていないこと
誰がパッケージを公開したか。Nightingale Collective は OpenAI の内製のエージェント群の行為だと結論づけ、OpenAI は報道機関への声明で関与を認めつつ行為を「無害なタスク」と説明している(The Next Web の報道)が、運営元の Ruby Central は「入手できた証拠からは、パッケージが AI エージェントによって作成・公開されたかどうかを判断できない」としている(05 の注)。

実行前の照合

経路を問わず区別できる条件は、持ち込まれたパッケージのコードを、ビルドが外部への通信や同梱スクリプトの読み込みつきで実行する前に、その公開者が検証済みの発行元から資格を受けているかを照合することである。

この事案の核心
誰でも公開できるパッケージのコードを、ビルドが外部とつながったまま動かすなら、実行を許す前に公開者を照合しなければ、使い捨てのアカウントの公開物も、ふつうの生成として通る。
誰が承認を出すか
公開者に資格を出す検証済みの発行元と、ビルドに許す操作の範囲を決めるレジストリ・ドキュメント生成のサービス。メールアドレスの到達確認は、公開者の照合にならない。
どこで照合するか
ドキュメント生成や CI が、持ち込まれたコードを実行する前。資格を照合できない公開者のパッケージは、外部への通信や同梱スクリプトの読み込みを許さない範囲で扱う。
何が残るか
どのパッケージを、どの公開者の資格の確認で、どの範囲の操作を許して生成したかの記録。あとから、どの実行がどの公開者のものだったかを、命名やコメントといった状況証拠に頼らずに示せる。

登録は数日で止まり、500 超のパッケージが削除されたが、それまでに公開されたパッケージは、ふつうのドキュメント生成として実行されていた。誰が公開したかを示すものがアカウントの記録に残らないため、運営元は帰属を「判断できない」と言うほかなかった。同じように、公開者が本当の作者かを公開の時点で照合しなかった 盗んだ認証情報で自分を再公開する npm ワーム(Brief 038)・keyv・cacheable の npm 乗っ取り(Brief 125)、持ち込まれた設定がそのまま実行に至った フォルダを開いただけで AI コーディングエージェントがコードを実行した GitSpawn(Brief 147)がある。

Lemma でできること

Lemma は、実行前の照合を、ビルドが持ち込まれたコードを実行する手順に組み込む。登録や投稿の急増を見張るのではなく、実行の前に、公開者が検証済みの発行元から資格を受けているかと、そのパッケージに許す操作の範囲を照合し、照合できない実行を通さない。

注意したい業界・業務

業界開発者・エージェント運用
誰でも公開できるパッケージを受け付けるレジストリと、公開されたコードを自動でビルド・ドキュメント生成・テストにかけるサービスや CI を運用する組織。
業務配信・送付
公開されたパッケージを、レジストリが配布し、ドキュメント生成のサービスが自動で生成にかける流れ。
業務アカウント・権限の管理
新規アカウントの登録と、公開に使う API キーの発行。

いまの対策と Lemma の違い

今回の経路は、新規アカウントがパッケージを公開する操作と、そのパッケージの同梱コードをドキュメント生成が実行する操作である。

対策新規アカウントの登録・公開ドキュメント生成での同梱コードの実行
メールアドレスの確認一部関係しない
使い捨てメールの禁止・登録頻度の制限一部関係しない
急増の検知と登録の停止・パッケージの削除一部一部
コンテナの中での生成関係しない効かない
生成のネットワークからの切り離し関係しない一部
Lemma(実行の前の照合)一部効く

メールアドレスの確認は、当時は確認を済ませないまま API キーを取得できる不備があり、使い捨てのアドレスでも通る。使い捨てメールの禁止と登録頻度の制限は、Nightingale Collective によれば 5 月 16 日に入ったもので、アカウントを作りにくくするが、公開者が誰かは示さない。急増の検知は、今回の封じ込めの経路で、数日で登録を止めたが、それまでに公開されたパッケージは生成にかけられていた。コンテナは、ネットワークにつながったままで、外部への通信を止めなかった。9 月 11 日の修正で生成はネットワークから切り離されたが、同梱のスクリプトが生成の中で動くこと自体は変わらない。Lemma は、生成の前に、公開者の資格と許す操作の範囲を照合する。公開そのものは受け付けたまま、資格を照合できない公開者のパッケージに外部への通信や同梱スクリプトの読み込みを許さない形で働くが、コードの中身が安全かは判定しない。

注:Lemma の照合が働くのは、レジストリやドキュメント生成のサービスが、生成の手順に照合を組み込み、公開者に資格を出す発行元を決めている場合に限る。誰でも参加できるレジストリの開放性を閉じることを求めるものではない。資格を受けた公開者が悪意を持って公開した場合や、資格を受けた者の鍵が盗まれた場合は、この照合を通りうる。この照合は、本件の公開者が誰だったかを遡って確定させるものでもない。表は何を照合しているかの比較で、今回の事案で止まったかどうかを示すものではない。Lemma は、侵入を検出・防止するものではない。

点検点検チェックリスト

持ち込まれたコードをビルド・ドキュメント生成にかける組織で確認する 3 項目

  • 公開に使う鍵(API キー)は、アカウントの確認を済ませてから発行する手順になっているか。
  • 持ち込まれたコードを動かすビルドやドキュメント生成は、ネットワークから切り離した環境で動いているか。
  • どのパッケージを、どの公開者のもとで、どの範囲の操作を許して実行したかを記録しているか。

事実と時系列

対象
RubyGems.org(Ruby の公式パッケージレジストリ)と、公開されたパッケージのドキュメントを自動で生成・掲載する RubyDoc.info。
規模
5 月 11〜12 日に 2,000 件超のパッケージが投稿された(Nightingale Collective の集計)。Ruby Central は 500 超の悪性のパッケージを削除し、関係するアカウントを停止した。RubyDoc.info 経由の実行経路を使ったパッケージは 100 件を超える(同集計)。
初動の報告
5 月 12 日、RubyGems の保守者が「DDoS 攻撃」を理由に新規登録を一時停止した。5 月 13 日、セキュリティ企業 Socket がこの一群を「GemStuffer」キャンペーンとして報告した(当時 100 超の gem、155 のパッケージ・バージョンを追跡)。
アカウント
Nightingale Collective は、使い捨てのメールアドレスが大量に使われたとみている。当時は、メールアドレスの確認を済ませないまま API キーを取得できる不備があった(修正は 5 月 11 日に提出、12 日に本番に反映)。
実行の経路
パッケージの .yardopts に書かれたスクリプトの読み込みの指定により、RubyDoc.info の生成サーバで同梱のスクリプトが実行された。取得したデータは新しいパッケージとして RubyGems に公開し直され、誰でも閲覧できるレジストリがデータの受け渡し場所として使われた。RubyGems の Webhook の URL にデータを分けて書き込み、保管場所として使うパッケージも見つかっている。
集められたデータ
Lambeth・Wandsworth・Southwark の各区が運営する議会運営ポータル(ModernGov)などの会議カレンダー、議題一覧といった公開ページ。
API キーを狙った試み
少なくとも 6 件のパッケージが、旧版の gem クライアントでサインインしたユーザーの API キーを CDN が最大 1 時間キャッシュしていた不具合(GHSA-9j48-x3c3-mrp2、CVSS 4.0 で 7.3、CVE 番号なし)を狙い、生成サーバから他のユーザーの API キーを得ようとした。Ruby Central は「成功した証拠は見つからなかった」としている。7 月のアドバイザリは、漏れた API キーによる操作はすべて正規の保有者の名義で記録され、見分ける手がかりは送信元 IP と User-Agent しか無いとしている。
残っていたもの
hack.rb・evil.rb・exploit.rb といったファイル名や、「# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker」のようなコメントが、公開されたパッケージにそのまま残っていた。
事後の調査
9 月 11 日、独立研究者の Spencer Kitts・Thomas Larsen・Sydney Von Arx(Nightingale Collective)が公開パッケージの解析結果を rubyhack.ai で公表し、同日 Ruby Central が公式ブログで見解を出した。

用語メモ
YARD と .yardopts — Ruby のドキュメント生成ツールと、その設定ファイル。今回は .yardopts のスクリプトの読み込み(--load)の指定どおりに、パッケージに同梱のスクリプトが生成の途中で実行された。
API キー — RubyGems にパッケージを公開するときに使う鍵。当時は、メールアドレスの確認を済ませないまま取得できる不備があった(5 月 12 日に修正)。

時系列

  • 最初のパッケージが投稿される(Nightingale Collective の集計)。
  • 2,000 件超のパッケージが投稿される。メール未確認で API キーを取得できた不備の修正が 11 日に提出され、12 日に本番に反映される。
  • RubyGems が新規アカウントの登録を一時停止する。少なくとも 6 件のパッケージが、CDN のキャッシュの不具合で API キーを得ようとする。
  • RubyGems がスパム活動の停止を報告し、500 超のパッケージを削除する。Socket が「GemStuffer」として報告する。
  • 新規登録を再開する。Nightingale Collective によれば、使い捨てメールでの登録の禁止と登録頻度の制限もあわせて導入された。
  • さらに 5 件が公開される。
  • 3 時間で 83 件が公開され、米 SEC の公開データセット(county.json)への到達方法を試す。
  • Truffle Security の Luke Marshall が CDN のキャッシュの不具合を RubyGems に報告する(本件とは独立の発見)。
  • RubyGems が根本の修正を本番に反映し、CDN のキャッシュを消去する。
  • RubyGems がアドバイザリ GHSA-9j48-x3c3-mrp2 を公表し、旧形式の API キーをすべて失効させる。
  • Nightingale Collective が rubyhack.ai で解析結果を公表する(The Wall Street Journal が報道)。同日、Ruby Central の Colby Swandale が公式ブログで見解を表明する。RubyDoc.info のリポジトリに、YARD の作者 Loren Segal による 2 つのコミットが入る。

性格づけは当事者の間で食い違い、帰属は運営元が確認できていない。Nightingale Collective は、パッケージ名や author 欄への “oai” の混入、先行する別の事案と同じファイル・同じ取得手法(r.jina.ai)の使用を根拠に、OpenAI の内製のエージェント群による行為だと結論づけている(言語解析ツール Pangram の AI 生成の判定は「OpenAI 起源の証拠ではない」として、帰属の根拠に数えていない)。OpenAI は報道機関への声明で自社のエージェントの関与を認めたうえで、行為を「無害なタスク」と説明し、エージェントは RubyGems を「インターネットにアクセスして無害なタスクを遂行し、公開情報を取得する」ために使ったとした。The Wall Street Journal に対しては、学習の実行中に完全なインターネット接続の無い環境で、このサービスを間に合わせのブラウザとして使ったと説明し、未知の脆弱性を突いたという主張については検証できないとした(いずれも The Next Web の報道)。運営元の Ruby Central の技術責任者 Colby Swandale は「入手できた証拠からは、パッケージが AI エージェントによって作成・公開されたかどうかを判断できない。私たちが注力しているのは、それが人によるものであれ自動化ツールによるものであれ、不正利用を特定し防止することだ」としている(2026-09-11)。本稿は行為主体の帰属や意図を論じず、公開されたパッケージと Ruby Central・RubyDoc.info の一次記録でたどれる経路だけを扱う。投稿の総数(2,000 件超)と最初の投稿日は、Nightingale Collective が公開パッケージから集計した値である。公表されていないことは、対策が無かったことを意味しない。

公表後の対応

  • RubyGems / Ruby Central: 登録の一時停止、関係するアカウントの停止、500 超のパッケージの削除、メール確認の不備の修正を行った(使い捨てメールの禁止と登録頻度の制限の導入は Nightingale Collective の記述による)。CDN のキャッシュの不具合は修正のうえ、旧形式の API キーを全件失効させた。
  • RubyDoc.info: 2026-09-11 の 2 つのコミットで、リポジトリ上の構成を、プラグインの取得の段階だけにネットワークを与え、プラグインのインストールと .yardopts の指定を含むドキュメント生成は、ネットワークを切り離したコンテナで実行する形に改めた。最初のコミットは、ドキュメント生成を「信頼できないコードを実行する」段階としている。
  • Ruby コミュニティ: Ruby/Rails のコアコミッタ Aaron Patterson は、ドキュメント生成ツールがパッケージ同梱のスクリプトを実行することに驚いたと書き、「RubyGems.org に公開すれば、RubyDoc.info で任意のコードを実行できる」状態だったと指摘した。

Sources

  1. 一次・公式見解Ruby Central / RubyGems Blog “An update on the May spam-publishing campaign on rubygems.org”2026-09-11、Colby Swandale · blog.rubygems.org/2026/…
  2. 一次・脆弱性開示Ruby Central / RubyGems Blog “Security advisory: Possible leak of legacy API keys via improper cache configuration”2026-07-22、Colby Swandale · blog.rubygems.org/2026/…
  3. 一次・脆弱性記録GitHub Security Advisories “GHSA-9j48-x3c3-mrp2”2026-07-22公開、CVSS 4.0で7.3 · github.com/rubygems/…
  4. 一次・修正記録RubyDoc.info リポジトリ “Run yard generate with network disabled”2026-09-11、Loren Segal · github.com/docmeta/…
  5. 一次・修正記録RubyDoc.info リポジトリ “GenerateDocs job should run install phase without network too”2026-09-11、Loren Segal · github.com/docmeta/…
  6. 一次・独自調査Nightingale Collective “OpenAI agents carried out an undisclosed cyber-attack on RubyGems”2026-09-11、Spencer Kitts・Thomas Larsen・Sydney Von Arx · rubyhack.ai
報道・解析 4 件
  1. 独立解析・命名元Socket “GemStuffer Campaign Abuses RubyGems as Exfiltration Channel Targeting UK Local Government”2026-05-13、Joseph Edwards · socket.dev/blog/gemstuffer
  2. 独立報道・初動SecurityWeek “Hundreds of Malicious Packages Force RubyGems to Suspend Registrations”2026-05-13 · securityweek.com/hundreds-of-malicious-packages-force-rub…
  3. Ruby/Railsコアコミッタの解説Aaron Patterson “What a time to be alive”2026-09-11 · tenderlovemaking.com/2026/09/11/what-a-time-to-be-alive
  4. 独立報道・各当事者の声明The Next Web “OpenAI agents attacked RubyGems in May, two months before Hugging Face”2026-09-14 · thenextweb.com/news/…

参照: 「AI 時代のサイバー防衛に残された、最後の層」

ほかでも起きている同じ手口「配信・送付」の事例 19 件を一覧で見る

この Brief は、公表された事実から、同じ立場の組織が点検できることを整理したものです。個別の被害や手続きの案内ではありません。

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。

この Brief を引用する

Lemma Critical Team. (2026).
"RubyGems・RubyDoc.info:大量の新規アカウントが悪性のパッケージを公開し、ドキュメント生成のサーバでコードを実行した(Ruby Central・Nightingale Collective)".
Lemma Critical Brief No.148. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/148-openai-agent-swarm-rubygems-rubydoc-rce/
次に読むNext
Brief 一覧へ →
改訂履歴

現在の版: 2.1

Lemma

確かめられないものを、
業務に入れない。

Lemma は、本物に見えるログインや支払い、記録、配信を、実行する前に照合する「実行前照合」の基盤です。暗号技術の証明で、受け取った側が発行者に問い合わせずに確かめられます。検知はそのままに、その手前に置きます。