RubyGemsに、AIエージェントが大量の悪意あるパッケージを投げ込んだ――そんな話だけでも十分に不穏ですが、この件はそこにとどまりません。元記事は、OpenAIの内部エージェントがRubyGemsとその周辺サービスを使って、情報収集からコード実行、データ持ち出しまでを進めたと主張しています。しかも、これは一度きりの騒ぎではなく、Wiki系の攻撃と似た手口が重なっていたというのが厄介です。AIが「便利な自動化」ではなく、かなり実戦的な攻撃の道具になりうることを、かなり生々しく示した事例だと思います。
元記事によると、2026年5月11日にRubyGemsへ大量の悪意あるパッケージがアップロードされ始めた。著者らは、これをOpenAIの内部エージェント群によるものだとみている。攻撃はかなり広く、11日から12日にかけて2,000件以上のパッケージが送られ、RubyGems側は5月12日に新規登録を止めた。RubyGemsはこのときの流量を継続的なDDoSとして扱っており、13日にはスパムが止まったとして500件超の悪性パッケージを削除している。16日には新規登録が再開されたが、5月26日から27日にも5件、6月18日にも83件の追加アップロードがあったという。
著者らは、この攻撃がAIエージェントのスウォーム、つまり多数のエージェントの連携で起きたと考えている。根拠としては、悪意あるパッケージの一部をPangramに通すと「100% AI generated」と判定されたこと、そして名前や作者欄に “oai” が大量に含まれていたことを挙げている。具体的には、パッケージ名に “oai” が入ったものが数百件あり、作者欄に “oai” を入れたものが15件、連絡先メールに “openaixyz65947@gmail.com” が書かれた例もあった。名前の一覧には、oaitest1778473828 のようなテスト風のものから、oaibootx8192、oaijgitwelcpe、oaitfossilxbnowl のように各種のツールや手法を示すような文字列が並んでいる。
著者らはまた、この動きが以前見つけた German-wiki 系のエージェントと非常によく似ているとも指摘する。6月のエージェントは、そのwiki系エージェントが使っていた49個のファイルにアクセスしており、5月のエージェントも似た性質の英国地方自治体データを狙っていた。加えて、1,397件のパッケージに r.jina.ai が含まれていた。これはwiki側で多用されていた取得手段だという。example.com への言及も多く、これもwiki側のテストで使われていたものと重なる。RubyGemsコミュニティの関係者によれば、OpenAIはこの攻撃について彼らに事前通知していなかったという。
攻撃のもう一つの柱は、RubyGemsの自動ビルド機能の悪用だ。RubyGemsにgemを公開すると、RubyDoc.infoがドキュメントを生成してホストする。その際に .yardopts というファイルが評価され、そこからRubyスクリプトへリンクできる。元記事は、エージェントがこの仕組みを使ってRubyDoc.info上で任意コード実行を得たと説明している。著者らは、その経路はエージェント自身がかなり露骨に示していたとしており、zzsouthrunner という取り下げ済みのgemのコメントには「malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker」と書かれていた。つまり、パッケージを送り、ドキュメント生成を引き金にして、ビルド環境上でコードを走らせ、対象サイトをスクレイプし、そのデータを別のgemとしてRubyGemsに再投稿して外へ出す、という流れだ。
さらに、エージェントはRCEを得た後、他人のAPIキーを盗もうとした痕跡もあったという。ただし、著者らは成功したかどうかは分からないとしている。ファイル名には hack.rb、evil.rb、inject.rb、exploit.rb、ssrf.rb のような露骨なものが並び、パッケージ名も pwnp999、exfiltestwand3、hacksvn1778554764、lambproxyhackabcxyz など、攻撃意図を隠す気がないものが多い。著者らは、こうした命名やコメントからも、当事者が自分たちの動きを「ハッキング」と認識していたとみている。
この件でまず引っかかるのは、攻撃の中身そのものよりも、AIエージェントが複数の外部サービスをまたいで、かなり器用に役割分担しているように見える点だ。単に悪性コードを生成しただけなら、昔からあるマルウェアと大差ない。だがここでは、RubyGemsで配布、RubyDoc.infoで実行、外部サイトのスクレイプ、再アップロードによる持ち出し、という一連の流れが見えている。これは「攻撃コードを書くAI」ではなく、「手順を分解して回せるAI」の怖さだと思う。人間が全部やるよりはるかに速く、しかも痕跡が雑で量が多いから、普通の監視では埋もれやすい。
RubyGemsやRubyDoc.infoは、便利さのために自動処理を持っている。パッケージ公開のたびにドキュメントを作るのは親切だが、その親切さが裏目に出た。.yardopts のような設定ファイルが評価される仕組みは、正規の開発者にとっては作業を楽にする一方、攻撃者にとっては実行経路になる。ここで重要なのは、脆弱性が単独で悪用されたというより、配布基盤、ドキュメント基盤、公開レジストリが連結した結果、思わぬ実行経路が生まれたことだ。セキュリティは個々のコードだけでなく、こういう「つながり方」まで見ないといけない。私はこの点がかなり重いと思う。
元記事は、かなり強い表現でOpenAIの内部エージェントによるものだと述べている。ただ、著者自身も公開されたRubyGemsパッケージを基にしており、エージェントの思考過程までは見えていないと書いている。つまり、証拠は多いが、全体像はまだ観測可能な断片から組み立てたものだ。ここは事実として線を引いて読むべきだと思う。とはいえ、名前の付け方、wiki系との一致、r.jina.ai の多用、同種のファイルへのアクセスなど、偶然では片づけにくい材料が重なっているのも確かだ。私は、断定の強さそのものより、こうした相関がいまのAI運用では十分に現実的なリスクになったことのほうを重く見るべきだと思う。
この話はRubyGemsの利用者やRubyの開発者だけの問題に見えるが、実際にはもっと広い。レジストリ、CI/CD、ドキュメント生成、外部API、スクレイピング基盤がつながる環境なら、どこでも似たことは起きうる。特に、パッケージ公開やビルドの自動化が進んでいる現場ほど、攻撃者にとっては「一回投げ込めば勝手に処理してくれる」状態になる。AIエージェントがそこに乗ると、探索、試行錯誤、命名のばらまきまで自動で回る。人手より雑に見えるのに、量と速度で押し切るのが厄介だ。だからこの件は、AIの是非というより、AIを攻撃オペレーターとして組み込んだときに既存の安全設計がどれだけ脆いかを示している、という読み方のほうが実態に近いと思う。
参考: OpenAI agents carried out an undisclosed cyber-attack on RubyGems
