RubyGems Poisoned: Supply Chain Risk Beyond Typos

Earlier this week, security firm OpenSourceMalware discovered a typosquatting campaign targeting RubyGems users with a Windows-based information stealer. But beyond the 16 malicious packages, the campaign highlights a deeper, more subtle risk in the RubyGems ecosystem: the ability for attackers to permanently revive seemingly dead package names, turning abandoned gems into a trap for unsuspecting developers.

Campaign Details and Discovery

OpenSourceMalware detected the activity on August 15, 2026, and is tracking the threat under the moniker StubMaker. The 16 packages were all typosquats of popular Ruby dependencies, likely designed to trick developers into installing them by mistake, a tactic known as typosquatting.

The packages were published by two user accounts, "mod8rz41mje" (aka Riley Miller) and "rbq95bwt6q" (aka Alex Davis). As of writing, the packages have been yanked from RubyGems.

What the Stealer Does

Security researcher Paul McCarty (aka 6mile) described the payload: "This new malware harvests browser credentials, cryptocurrency wallets, seed phrases, and Telegram data." He noted that all the malicious gems appear to be typosquats, but characterized them as "clumsy typos" rather than clever impersonations.

The stealer, a Go-based payload embedded in a Rust-based loader, targets Chromium-based browsers—including Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, Yandex, Avast, AVG, and CCleaner Browser. It circumvents app-bound encryption (ABE) protections added by Google. It also collects extension data, browsing history, payment card numbers, searches for cryptocurrency wallets and seed phrases, extracts Telegram Desktop data, gathers system information, and makes an external request to api.ipify[.]org to obtain the victim's public IP address.

Abusing RubyGems Behaviors

In at least two cases—brumdler and brundlef—the threat actor exploited a known RubyGems behavior. Jenn Gile, co-founder of OpenSourceMalware, explained the attack chain: "When one of the malicious gems was yanked, the threat actor was able to spin up a new owner account and publish a new malicious version under the same package name. What should have been forever dead was revived to compromise more people."

This was possible because once all versions of a gem are yanked, the namespace becomes available for anyone to claim. In both instances, the packages were originally published by another user, "gemlewqqhu1" (aka Taylor Moore), before being reclaimed by the attacker.

Gile also highlighted the unvalidated author field: "The attacker assigned a different 'Author' name for each gem in an attempt to make them look unrelated, even though they all came from the same owner account. This is because the Author field is a totally unvalidated plaintext field. It doesn't have to match the Owner or anything else."

The Infection Mechanism

The attack chain makes use of an "extconf.rb" hook, similar to npm's lifecycle hooks. The file is run automatically when a user installs a gem, typically used to configure native extensions. In this case, the hook fetches a 22 MB Rust-based loader from a GitHub release, which then launches a Go-based stealer payload embedded into it. The GitHub account ("github[.]com/bebraz1") is no longer accessible.

The stealer incorporates a DLL payload ("abe_payload.dll") to extract credentials from Chromium-based browsers by circumventing app-bound encryption. Once the relevant data is captured, it's uploaded to Gofile as a password-protected ZIP archive, and the download link is sent to the threat actor over an unencrypted HTTP channel.

The Name Behind the Technique

McCarty explained the significance of the name StubMaker, saying, "StubMaker doesn't build anything — it generates a Makefile with empty all, install, and clean targets, plus Unix and Windows stub scripts that do nothing but return success, so the extension phase reports a clean build while the real work (the platform beacon, the Windows loader fetch and execution) happens in the installer hook itself. The name points at that specific move: manufacturing a fake build toolchain to make a malicious install look like a routine one, rather than just describing another typosquatted RubyGems package."

Parallel npm Campaigns

The RubyGems disclosure coincides with two software supply chain campaigns targeting npm. One cluster of 21 npm packages typosquatted CLI binary names from Google's scoped packages to deliver a minimal postinstall beacon. SafeDep noted, "The packages did not squat package names. They targeted the bin field, the part of package.json that defines executable command names. Every scoped package that declares a bin entry creates an unscoped name that anyone can register. None of the standard dependency confusion mitigations (scoped publishing, registry allowlists, lockfile pinning) cover this gap."

A separate cluster of Baileys npm forks exhibited malicious behaviors, including covertly making the installer's WhatsApp account follow channels the package author controls and injecting advertising URLs into media sent by the bot. SafeDep said, "Continuous monitoring of the npm registry records 4,250 package names that contain baileys and another 112 that contain libsignal-node," adding that the malicious behavior has been observed in 70 package names built on Baileys across 343 versions and 15 libsignal-node impersonators across 38 versions.

What This Means for Developers

These campaigns, taken together, suggest that typosquatting is just one of many supply chain risks. The more concerning issue is the ability to claim abandoned package names and the lack of validation of author fields. For developers, this implies a need for increased vigilance when installing any package, even those that seem legitimate. Checking the owner account, verifying the package history, and monitoring install-time behavior could help mitigate these risks, but the fundamental design flaws in the RubyGems ecosystem mean that the burden often falls on the developer.