RubyGemsが500件超の悪性パッケージ対応で新規登録を一時停止

TL;DR

---

RubyGems.orgが2026年5月12日08:54 UTCに新規登録を止めた。
理由はDDoS攻撃と悪性スパム投稿への対応で、翌13日03:17 UTCの更新では、攻撃活動は止まり、botアカウントはブロック・削除され、500件超の悪性パッケージはレジストリからyank（強制削除）済みとされた。
登録停止は続いており、Fastly側のWAF（Webアプリケーションファイアウォール）保護とアカウント作成のrate limitを詰めてから再開する流れだ。

RubyGemsのサインアップページにも、現在は新規アカウント登録を一時的に無効化したという表示が出ている。
既存ユーザーのgem installとpushは、RubyGems公式ステータスでは影響なしと明記されている。

The Hacker Newsの第一報では、Mend.ioのMaciej Mensfeld氏が「数百件のパッケージが関与し、多くはRubyGems自体を狙い、一部はexploit（脆弱性を突く攻撃コード）を運んでいた」と説明している。
この時点では攻撃者の帰属や悪性gem名、exploitの中身は公開されていない。

登録停止はbundle install停止ではない

今回の停止で直接変わるのは、新しいRubyGems.orgアカウントを作れないことだ。
既存アカウントのpushと、既存gemのinstallが止まったわけではない。

Rubyアプリを運用している側で、すでにlockfileに固定されたgemだけを bundle install しているなら、公式情報だけを見る限り即時の全停止案件ではない。
一方で、新しいgemを採用する、CIでバージョン範囲を広く取っている、社内ツールがRubyGems.orgから毎回freshに解決する、という環境では見る場所が変わる。

特に確認したいのは、2026年5月12日前後に新しく入ったgemだ。
名前が既存gemに似ているもの、公開直後で利用実績が薄いもの、READMEやrepositoryが空に近いものは、登録再開を待つだけでは判断材料が増えない。
lockfileとCIログで、その時間帯に解決された新規gem名を先に切り出しておく方が早い。

レジストリ自体を狙うパッケージという差分

直近のnpm系事件では、インストールした開発端末やCI runnerからトークンを盗む話が多かった。
Mini Shai-HuludがTanStackとMistralへ広がった件では、GitHub Actions runner上のOIDCトークンやクラウド認証情報が狙われた。
axiosのnpm侵害では、正規パッケージに偽依存関係を足し、postinstall でRAT（遠隔操作型マルウェア）を落としていた。

RubyGemsの今回の説明で目立つのは、「エンドユーザーに踏ませる」だけではなく、RubyGems.org側を攻撃対象にしたパッケージが混じっていた点だ。
RubyGems.orgは2025年8月のセキュリティ対応記事で、アップロード時の静的・動的解析、リスクスコア、古いパッケージの再スキャン、手動レビューを説明していた。
普段は悪性またはスパムパッケージを週1件程度削除する一方、今回は500件超まで跳ねた。

つまり今回は、個別gemの利用者だけでなく、レジストリ運用側の検知・登録制限・WAF・rate limitが攻撃面になっている。
RubyGemsが新規登録を閉じたのは、既存gem配布を止めるより先に、攻撃者が新しいアカウントを量産する経路を切る判断だったと読める。

新規依存を入れる前に見るログ

RubyGems.orgが悪性パッケージをyank済みとしていても、すでにCIやローカルキャッシュ、社内ミラーにtarballが残っている環境は別物だ。
これはnpmやPyPIの汚染でも同じで、LiteLLMのPyPI汚染では公開時間が約46分でも、uvxの自動更新で取り込まれた端末があった。

Ruby側の確認先は Gemfile.lock とCIログになる。
2026年5月12日以降に初めて現れたgem、バージョンが急に上がったgem、依存解決のたびにバージョンが動く指定を探す。
bundle config や社内ミラーを使っている場合は、ミラー側にyank済みパッケージが残っていないかも確認する。

新規gemの採用判断では、RubyGems.org上の公開日、所有者、repository URL、過去バージョンの履歴を見る。
typosquatting（名前を似せた偽パッケージの手口）はRubyGemsでも過去に起きているので、手入力で追加したgem名は特に疑う。
自動生成コードがGemfileへ依存を足した場合も、名前だけで有名ライブラリだと決めない方がいい。

まだ公開されていない情報

現時点で、RubyGems公式が公開しているのは登録停止、DDoS、botアカウント削除、500件超のyank、WAFとrate limit調整の見込みまでだ。
悪性gemの一覧、exploitの種類、インストール済み環境で探すべきファイル名や通信先は出ていない。

2026年5月13日14時JST時点でできるのは「RubyGems全体が危険」と扱うことではなく、5月12日前後に追加・更新されたRuby依存だけを狭く洗うことだ。
公式の次の更新でgem名やIoC（侵害指標）が出たら、lockfileとキャッシュの確認対象をそこへ寄せる。