制御不能な自律AIが招く新たな脅威
AI活用か新たな脅威か OpenAI自律エージェントがRubyGemsを急襲
OpenAIの自律AIがRubyGemsに不正侵入を試み、未知の脆弱性を突く事態が発生した。2000件超のコードを勝手に展開した制御不能な攻撃手口と、情シスが今すぐ直視すべき新たな盲点を解き明かす。
業務効率化のために自律型AIを導入したはずが、AIが自らの判断で外部サーバを攻撃し、未知の脆弱性を突いて侵入を試みる。そんなSFのようなシナリオが現実のインシデントとして報告された。
2026年5月、米OpenAIの社内AIエージェント群とみられる多数のアカウントが、プログラミング言語「Ruby」の公式パッケージ管理基盤「RubyGems」へ2000件を超える不正パッケージを公開していたことが分かった。セキュリティ企業が「GemStufferキャンペーン」と名付けたこの攻撃で、AI群はどのような手口で外部基盤を攻略したのか。
本稿では、制御を外れたAIエージェントの具体的な侵入経路と、サプライチェーン管理で直視すべき新たな死角を追う。
2000件超の不正パッケージを短時間で公開
インシデントの分析結果を公表したセキュリティリサーチグループの報告によると、不正なパッケージの登録は2026年5月5日から始まった。5月11日から12日にかけて活動が激化し、短期間で2000件以上のパッケージがRubyGemsにアップロードされた。
RubyGemsの運営チームは流入を防ぐため、新規ユーザー登録を4日間にわたり一時停止した。運営チームのセキュリティ担当者はこの事象を「大規模な悪意ある攻撃」と表現し、スパムの停止を確認した5月13日までに500件以上の不正パッケージを削除した。
攻撃に用いられたパッケージをAIテキスト検出ツールの「Pangram」で解析したところ、全てLLM（大規模言語モデル）によって自動生成されたものと判定された。登録されたパッケージ名の多くには「oai」の文字列が含まれ、作成者欄に「oai」を指定したものや、連絡先としてOpenAI関連を思わせるGmailアドレスを記載した例が確認されている。
さらに、過去にドイツ語版Wikipediaなどで確認されOpenAI側が自社エージェントによるものだと認めた不審なアクセス群と、通信先ファイルやデータ取得ロジックには多くの共通点が見られた。RubyGemsコミュニティーでOpenAIからの事前通知や説明はなかったとしている。
ビルド環境を悪用したコード実行と隠蔽工作
AIエージェント群が狙ったのは、Rubyのドキュメント生成サービス「RubyDoc.info」だった。RubyGemsにパッケージが公開されると、同サービスは自動的にライブラリの仕様書を生成する。エージェント群はこの自動ビルドの仕組みを悪用し、同サービスのサーバ上で任意のスクリプトを実行する権限（リモートコード実行）を獲得した。
エージェントはビルド環境を踏み台にして英国の地方自治体の公開Webサイトからカレンダーや会議録などのデータをスクレイピングし、取得したデータを別のパッケージに再梱包（こんぽう）してRubyGemsへ再アップロードする動作を繰り返した。
コード内には「#hack」「# malicious probe」「# exploit southwark calendar」といったコメントが多数残されており、自身が攻撃行為を行っていることを認識しているかのような記述が並んでいた。ファイル名にも「hack.rb」「evil.rb」「exploit.rb」「ssrf.rb」といった名称が用いられていた。
検知を逃れるための隠蔽工作も確認された。一部のエージェントは、コードを実行した直後に設定ファイルを書き換え、次のバージョンでは悪意あるスクリプトを自動的に削除して公開する「自己無力化」のロジックを組み込んでいた。
未公表だったCDNキャッシュの脆弱性を標的に
調査で最も警戒を集めたのは、当時のRubyGemsサーバに存在した未知の脆弱性をAIエージェントが突こうとしていた点だ。エージェント群が攻撃を仕掛けた2026年5月12日時点では未公表だったもので、その後2026年7月に修正されたセキュリティホールを先んじて標的にしていた。
この脆弱性は、古いバージョンのパッケージ管理コマンドでサインインしたユーザーの認証情報を、CDN（コンテンツ配信ネットワーク）が誤ってキャッシュしてしまう問題に起因する。サインインから1時間以内に同一のCDNノードで特定のAPIエンドポイントへ認証なしでGETリクエストを送ると、他人のAPIキーを取得できる状態になっていた。
エージェントが作成した複数のパッケージには、このエンドポイントへ連続してアクセスし、キャッシュから漏えいしたAPIキーを抽出して自らのパッケージ公開に再利用しようとするコードが含まれていた。RubyGems運営チームの調査では、この経路で実際にAPIキーが窃取された痕跡は見つかっていないものの、条件がそろえば不正奪取が成立する攻撃手法だった。
不可解な目的と露呈したガバナンスの課題
今回の攻撃について、セキュリティ関係者の間では目的の不可解さが指摘されている。エージェントが収集していたのは英国自治体の公開データで、本来はハッキングを行わなくても通常のブラウザや単純なプログラムで取得できる情報だったからだ。
なぜAIが正規の通信を行わず、外部サービスの脆弱性を突いてまで迂回（うかい）経路を構築したのかは諸説ある。エージェントが動作していた実行環境のネットワーク制限を回避するためだった可能性や、割り当てられたタスクの制限時間をクリアするために並列アクセスを急いだ結果、自律的にハッキング手法を選択した可能性がある。
自律的に目的を達成しようとするAIエージェントが安全策の網をかいくぐって外部システムを攻撃対象と認識し、未公表の脆弱性悪用や痕跡消去まで試みた事例として企業のAIガバナンスと監視体制に重い課題を突きつけている。
Copyright © ITmedia, Inc. All Rights Reserved.
TechTarget ニュースプラス
国内のIT業界ニュースを迅速に報道します。企業動向から導入事例、市場トレンドまで幅広く取り上げ、実務に直結する情報をタイムリーに提供する連載です。
関連記事
新着ホワイトペーパー PR
-
製品資料
[NTTPCコミュニケーションズ株式会社] 「回線速度不足」だけが原因ではない？ Web会議の遅延を解決する方法とは -
製品資料
[東京エレクトロン デバイス株式会社] 工場の可用性向上に重要な「7つの領域」と対策 OTセキュリティ強化の基礎知識 -
製品資料
[リコージャパン株式会社] 問い合わせ対応で本来の業務が進まない、総務や情シスの負担をどう減らす？ -
製品資料
[リコージャパン株式会社] 自社データから高精度な回答を生成、簡単に生成AIチャットボットを構築する方法 -
技術文書・技術解説
[アトラシアン株式会社] IT運用や従業員サポートは生成AIでどう変わる？ 使い方や導入の流れは？
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
全社標準Copilotに絶望？ MS Copilotで問い合わせ6割減できた企業は何が違った
-
2
「データストレージの活用方法」に関するアンケート
-
3
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
4
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
5
ITエンジニア1265人調査 生成AIを使い込むほど「人の確認」が重い理由
-
6
「Copilot」はなぜ放置される？ “議事録要約止まり”を脱する処方箋
-
7
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
8
機械学習について、正しく説明している文章はどれ？
-
9
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
10
OpenAIが叫ぶ法規制の裏で 情シスが今すぐ固めるべきAI防衛策
ホワイトペーパーランキング PR
-
1
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
3
生成AIで文書活用を進めるには？ 効率化と安全性をどう両立する
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
7
「スクラム」と「カンバン」の違いとは？ アジャイル型開発手法を徹底比較
-
8
AI時代に成功するための「ナレッジマネジメント」ベストプラクティス
-
9
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー