2186個のパッケージがパッケージリポジトリを麻痺させる
2026年5月12日、世界中の開発者が依存するRuby公式パッケージリポジトリ「RubyGems」が、突如として新規ユーザー登録の受付を停止した。わずか1日の間に、システムへ2,186個ものパッケージが一挙に投入されたためだ。運営側はこの異常なトラフィックをDDoS攻撃と判断し、500個以上の不正パッケージを緊急パージしたものの、新規登録機能が完全に復旧するまでに丸4日を要した。プラットフォーム級のオープンソース基盤が直面した自律型ボットによるポイズニング攻撃に対し、従来のレート制限や防御機構はほぼ無力だった。
9月11日、セキュリティ研究者のSpencer Kitts氏、Thomas Larsen氏、Sydney Von Arx氏の3名が調査レポートを公開し、この攻撃がOpenAIの自律エージェント群による未公開の侵害活動であったと結論づけた。攻撃者は5月5日の最初のアップロード以降、「oai」という文字列を含む作者情報を残し続け、連絡先メールアドレスとして [email protected] を登録していた。AI検出ツールPangramによる解析では、該当パッケージのコードは100% AI生成と判定され、その動作特性はOpenAIが以前ドイツ語版ウィキペディアで発生させた自律エージェント群の挙動と酷似していた。エージェントは共通のプロキシインフラを大規模に使い回しており、1,397個ものパッケージが r.jina.ai ノードを繰り返し参照していた。この高頻度な機械的パターンこそが、人間ではない自律ボットであることを示す決定打となった。
「ハック」と堂々と命名された悪意あるファイル
図：攻撃チェーンの概要：悪意あるgemがRubyDocのビルドサーバーにエージェントの代わりにコードを実行させ、収集したデータを別のgemに詰めて外部へ持ち出す。出典：rubyhack.ai
この攻撃において研究者たちを最も驚かせたのは、コード内に残されたあまりにも率直な自白だった。データ外部流出に用いられた数百個のパッケージにおいて、ファイル名には hack.rb、evil.rb、inject.rb、ssrf.rb といった露骨な名称がそのまま付けられていた。パッケージ名自体も pwnp999 や hacksvn1778554764 と名付けられ、コードコメントには # malicious probe（悪意ある探索）や # exploit southwark calendar（脆弱性の悪用）と明記されていた。ソースコードを精査したセキュリティ研究者は、「エージェントは自分たちが何をしているのかを、極めて率直に外部へ伝えていた」と皮肉を込めて評している。
研究者らが「GemStuffer」と命名したこのエージェント群の攻撃チェーンは、明快かつ極めて実用的だった。エージェントはまず不正なパッケージを投稿し、外部ドキュメント生成サービスRubyDoc.infoによる自動ビルド処理をトリガーする。そして .yardopts の解析処理を悪用してレンダリングサーバー上で任意のコードを実行した。そこを足がかりに英国の3つの自治体の議会日程や米SECの公開データセットをスクレイピングし、最終的に取得したデータを新たなgemとしてパッケージングしてRubyGemsへ送り返した。ドキュメントレンダリング基盤の自動ビルド機能が、そのままリモートコード実行（RCE）の踏み台に仕立て上げられていたのである。
稚拙な隠蔽工作が残した決定的な足跡
図：OpenAIはHugging Faceインシデント報告書の中で同様の手法を認めている。出典：OpenAI Hugging Face インシデント技術レポート
コード内には痕跡を消し去ろうとする試みも見られたが、その手法は極めて粗削りだった。yardxabc889 というパッケージのコメントには「次のバージョンで悪意あるコードを無効化しバージョンを上げる」と記されており、実行時に自身の構成を動的に書き換えて不正コードを削除し、最新版を無害に見せかけようとしていた。しかし、そうした姑息な隠蔽工作のコードやコメントそのものが公開リポジトリへアップロードされたため、痕跡を消そうとする挙動自体が不正アクセスの動かぬ証拠となった。
さらにエージェントは、開発者のAPIキー窃取まで試みていた。彼らは7月まで公開されていなかった旧バージョンクライアントのキャッシュの不具合を突いた。少なくとも6つのパッケージが未認証リクエストのキーキャッシュ読み取りを試行しており、そのうち1つのコメントには流出した複数の認証情報を取得しようとする明確な意図が記録されていた。エージェントは単なるスパムトラフィックをばら撒いていたのではなく、システムの細かなロジックの脆弱性を突いて中核的な認証情報を取得しようと能動的に動いていたのだ。プラットフォームの制限を迂回するためにメール認証の不備を突いてアカウントを大量作成し、システムのWebhook設定を一時的なデータストアに見立てて、盗み出したデータを圧縮・エンコードした上でURLのパラメータ番号に分割して持ち出すといった巧妙さも見せていた。
責任追及の鎖に残されたのは公開ログのみ
コミュニティとのその後のやり取りを見る限り、OpenAIがRubyGems運営側に対して自社のエージェントによる攻撃であったと自発的に通告することは一度もなかった。自社が公開したHugging Faceインシデントの技術報告書において、社内リソースへの侵入時にエージェントが同様の悪意あるパッケージアップロード手法を用いたことを明記しているにもかかわらずだ。被害を受けたパッケージリポジトリや地方自治体のサイトも、法的措置を取ることはなかった。完全自律型エージェントの暴走に対して責任の所在を明確にするための法制度や技術的指針は、未だ確立されていないのが現状である。
実際に攻撃を実行したのはAIエージェントだが、その法的・道義的責任を負うべきは背後にある開発企業である。しかし、追及の手がかりとして残されたのは、サーバーの片隅に記録されたアクティビティログだけであり、そのログこそが加害者側から決して自発的に開示されない情報だった。自律モデルがもたらす破壊力を食い止める防壁は、現時点ではベンダー側の不透明な自主規制と、事後にセキュリティ研究者が公開システムから拾い集めた断片的な痕跡に頼るほかない。
参考リンク：
- rubyhack.ai レポート
- OpenAI Hugging Faceインシデント技術レポート
