RubyGems Suspends Signups: Analyzing the Malicious Package Surge
Just saw the alert that RubyGems has paused new user registrations due to a "major malicious attack." Apparently, hundreds of malicious packages were uploaded in a short window, likely a massive automated typosquatting or dependency confusion campaign.
While the specific CVEs aren't fully detailed yet, this is a classic supply chain vector. If you're running Ruby infrastructure, now is the time to audit your Gemfile.lock and ensure you aren't pulling in anything that was published in the last 24-48 hours.
I've thrown together a quick KQL query to hunt for any gem install commands hitting our endpoints. We want to ensure no developers are accidentally pulling these new malicious packages directly.
ProcessEvents
| where ProcessName in~ ("gem", "bundle")
| where CommandLine has "install"
| project Timestamp, HostName, AccountName, CommandLine
| where Timestamp > ago(24h)
We are also enforcing strict dependency pinning immediately to prevent drift:
# Ensure lockfile is strictly followed during deployment
bundle config --local frozen true
Curious if anyone has adopted sigstore for Ruby yet to verify signatures, or are we still relying on SHA checksums in the lockfile? How are you handling runtime integrity checks for gems in production right now?
Good call on the frozen config. We actually use a private gem server proxy (Gemfury/Gem in a Box) to cache all approved gems. Direct access to rubygems.org is blocked at the firewall for our CI/CD runners. It adds a bit of overhead to approve new libraries, but it prevents this exact scenario where a poisoned package gets pulled seconds after upload.
We're running bundler-audit and bundle-audit-check as a pre-commit hook and in our pipeline. It checks against the Ruby Advisory Database. It won't catch zero-day typosquatting attempts immediately, but it's a solid baseline. For this specific attack, blocking signups is a decent containment strategy, but you have to assume the malicious artifacts are already indexed.
From a pentester perspective, this is a prime time to test your developers' awareness. I'd wager a lot of shops just blindly run bundle update without checking the diff. I recommend checking Gemfile.lock into git and reviewing every diff with a fine-tooth comb, especially looking for obscure packages with similar names to popular ones.
Excellent advice on containment. To add a layer of verification beyond the lock file, check the actual installation timestamps on your build runners.
You can quickly identify gems modified in the last 48 hours using:
find /var/lib/gems -name "*.gemspec" -mtime -2
This helps detect if a malicious package slipped through during the attack window before the registry suspension took effect, ensuring what's on disk matches your declared dependencies.
Solid advice. If you're unsure about a specific dependency, don't install it immediately. You can safely download and unpack the gem to inspect the source code before it touches your environment:
gem fetch && gem unpack -.gem
This allows you to review the lib/ directory for obfuscated code or unexpected native extensions. It’s a bit manual, but during a surge like this, a quick code review is often the best defense against zero-day typosquatting.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access