RubyGems — the standard package manager for the Ruby programming language — has temporarily blocked new account registration after an incident that is being described as a large-scale malicious attack. According to available information, hundreds of packages are involved in the attack. Everyone who uses Ruby dependencies in their projects should audit recently added packages and freeze dependency updates until the situation becomes clear.

What happened

The RubyGems registration page displays the message: “New account registration has been temporarily disabled”. Maciej Mensfeld, representing Mend.io, reported on social network X that the platform had faced a “large malicious attack” involving, in his words, hundreds of packages.

It is important to emphasize the context: at the time of publication, no official incident report from RubyGems or Ruby Central has been released. Information about the nature and scale of the attack is based on a single post on social media. The fact of registration being suspended is confirmed and directly observable, but the causes and details of the attack have not yet received independent confirmation.

Analysis of the attack vector

Suspending new account registrations is a typical response to typosquatting-style attacks or mass uploads of malicious packages via newly created accounts. This tactic is well known from incidents in the npm and PyPI ecosystems: attackers register numerous accounts and publish packages with names similar to popular libraries, or with attractive names, relying on developers’ inattention when installing dependencies.

The technical details of the attack — the specific names of malicious packages, types of exploits, and indicators of compromise — have not yet been disclosed. No CVE identifiers have been assigned. The attribution of the attack is unknown.

Context: supply chain attacks

The incident fits into a persistent trend of increasing attacks on software supply chains through open package ecosystems. Package registries are an attractive target: compromising a single popular library can cascade to affect thousands of projects. However, it is important not to conflate this incident with other campaigns — there is no direct evidence linking it to any known groups.

Impact assessment

The following are at greatest risk:

• Developers and teams that have added new Ruby dependencies in recent days — especially little-known or newly published packages
• CI/CD pipelines that automatically resolve dependencies without version pinning (no strict Gemfile.lock in place)
• New projects initialized during the attack period with dependencies pulled from the public registry

The registration block also temporarily affects legitimate users who cannot create an account to publish their own packages.

Recommendations

1. Dependency audit: review Gemfile.lock for packages that were added or updated over the past few days. Pay attention to unfamiliar names, packages with a minimal number of downloads, and very recent publication dates.
2. Freeze updates: temporarily refrain from running bundle update without first reviewing the changes in the dependency tree.
3. Version pinning: make sure Gemfile.lock is committed to version control and that CI/CD pipelines use bundle install --frozen to prevent unexpected updates.
4. Monitoring: follow the official RubyGems and Ruby Central channels for an incident report with specific names of compromised packages and indicators of compromise.
5. Use of private mirrors: for critical projects, consider using a private registry or proxy (for example, Gemstash) that caches vetted package versions.

Until RubyGems publishes an official report with a list of affected packages, the main actions are to review Ruby dependencies added in recent days, pin Gemfile.lock, and avoid automatic dependency updates. Once specific indicators of compromise become available, they should be checked against your dependency tree immediately.