RubyGems — the canonical package registry for the Ruby ecosystem — suspended new account registrations late on May 12 after fielding what Mend.io described as a “major malicious attack” that uploaded hundreds of malicious gems over a 36-hour window beginning Monday, May 11. Unlike most package-registry abuse, the campaign appears to target the registry’s own engineers and staff rather than downstream Ruby developers.

The freeze is immediate. Visitors to rubygems.org/sign_up are met with: “New account registration has been temporarily disabled.” Existing accounts and gem installs are unaffected.

What’s known

Maciej Mensfeld, senior product manager for software supply chain security at Mend.io (the firm contracted to secure RubyGems), confirmed the attack on X early on May 12:

“We’re dealing with a major malicious attack on Ruby Gems right now. Signups are paused for the time being. Hundreds of packages involved – mostly targeting us, but some carrying exploits.”

The phrase “mostly targeting us” is the unusual part. The packages were not designed to be installed by victims at scale via typosquats or dependency confusion — the dominant pattern in npm/PyPI compromises this year. Instead, the malicious code aimed to fire when a RubyGems engineer triaged or rendered the packages: cross-site scripting payloads against RubyGems’ own moderation and review surfaces, plus data-exfil exploits intended to land on RubyGems infrastructure. Hundreds of variations were uploaded across two consecutive days, suggesting either rapid iteration against detection rules or an attempt to overwhelm manual review.

Mend.io has not named a threat actor and says it will publish details once the incident is contained.

Context: this is the second Ruby-side campaign in two weeks

The RubyGems freeze lands less than two weeks after Socket researchers disclosed the BufferZoneCorp campaign on May 1 — a sleeper-package operation that published seemingly clean gems under the knot-* prefix (mimicking activesupport-logger, devise-jwt, rack-session-store, and similar trusted names) and later updated them with credential-stealing payloads. The Ruby half of BufferZoneCorp scraped environment variables, SSH keys, AWS credentials, .npmrc, .netrc, GitHub CLI configuration, and RubyGems API keys, exfiltrating to a Webhook[.]site endpoint. A parallel Go-modules cluster planted fake go wrapper binaries and pushed an attacker SSH key into ~/.ssh/authorized_keys on CI runners.

The two campaigns are not currently linked publicly, but the timing and the shift in attacker attention toward Ruby — historically the quieter ecosystem compared with npm and PyPI — is the bigger pattern. Ruby has roughly an order of magnitude fewer maintainers than npm; that scarcity is now being treated as a target-rich rather than target-poor environment.

Affected and not affected

  • Affected: New RubyGems account creation. Disabled until further notice.
  • Affected (potentially): RubyGems staff endpoints, moderation tooling, and any internal browser sessions used to triage the malicious uploads. The XSS angle is the part that distinguishes this from a typical registry-abuse story.
  • Not affected: gem install, existing accounts, existing gems, RubyGems API for publishing from established accounts.

What to do now

For application teams running Ruby in production, the immediate downstream risk is low — no widely-installed gem has been reported as backdoored in this campaign. The medium-term risk is higher: if RubyGems’ own moderation or build infrastructure was compromised via the XSS or exploit payloads, future malicious uploads may bypass the controls that caught this round.

Concrete steps:

  1. Pin your Gemfile.lock and verify checksums on next bundle install. Treat any unexpected version bump for a gem you depend on as suspicious until RubyGems publishes a post-mortem.
  2. Audit BufferZoneCorp-prefixed gems if you haven’t yet. Search your Gemfile.lock for knot-activesupport-logger, knot-devise-jwt-helper, knot-rack-session-store, knot-rails-assets-pipeline, knot-rspec-formatter-json, knot-date-utils-rb, and knot-simple-formatter. All have been yanked, but install-time payloads from the gap may have already run.
  3. Rotate any RubyGems API keys stored in CI if they were used to publish during the May 11-12 window — out of caution, not because a compromise has been confirmed.
  4. Watch for the post-mortem. Mend.io has committed to publishing details. The interesting forensic question is whether any of the XSS payloads actually landed inside the RubyGems admin surface, and whether the attacker pivoted from there.

Risky.biz characterized this as “an attack on staff” rather than a typical registry-spam wave, and that framing matches what’s visible from the outside: this is closer to a phishing-and-XSS campaign against a registry’s defenders than a mass-poisoning of its consumers. The signup freeze is the appropriate immediate response — it shuts off the channel the attacker was using to upload new variants while triage continues — but it does not by itself remediate whatever may have already been clicked or rendered.

This is a developing story. Expect more detail once RubyGems and Mend.io confirm scope.