# When a Yanked Package Isn't Gone: StubMaker Exploits RubyGems' Zombie Namespace Problem
Ruby developers installed a package. It was pulled. Then someone else published it again under the same name. And that second version stole their browser passwords, crypto wallets, and Telegram data.
That's not a hypothetical. That's what happened with at least two packages in the StubMaker campaign — and it's a problem that goes well beyond sixteen clumsy typosquats.
## The Campaign
Researchers at OpenSourceMalware flagged the activity on August 15, 2026, after spotting sixteen RubyGems packages designed to impersonate popular Ruby dependencies. The list includes things like brumdler (Bundler), activesupmport (ActiveSupport), ri18nr (i18n), and a dozen other variations that would catch a developer typing fast or relying on autocomplete.
The packages were published by two accounts — mod8rz41mje (listed as Riley Miller) and rbq95bwt6q (listed as Alex Davis) — neither of which is a real identity. The "Author" field in RubyGems, it turns out, is a free-text field with no validation whatsoever. It doesn't have to match the account that owns the package. The attacker used a different author name for every gem specifically to make the packages look unrelated. It worked because nobody checks.
As of writing, all sixteen gems have been pulled. But here's where the story gets more interesting.
## Zombie Packages: RubyGems' Structural Weakness
Two of the packages — brumdler and brundlef — weren't just cloned from legitimate gems. They were reclaimed.
When all versions of a RubyGems package are yanked, the namespace becomes available again. Anyone can register it. The attacker did exactly that: waited for the slot to open, created a new account, and republished a malicious version under an identical name. The original gem had been pulled. The new one was malware. To any developer who'd previously seen the package in their ecosystem, it would look fine.
Jenn Gile, co-founder of OpenSourceMalware, put it plainly: "What should have been forever dead was revived to compromise more people."
This is not an edge case. It's a documented behavior that RubyGems has not addressed. PyPI has grappled with similar namespace squatting issues. npm has its own lifecycle hook problems. But the specific combination here — yanked namespaces that resurrect, paired with unvalidated author metadata — creates a layered deception that's harder to catch than a simple new-package typosquat.
## How StubMaker Actually Works
The attack chain is technically more sophisticated than the typosquatting itself suggests.
When a developer installs one of the malicious gems, RubyGems automatically executes extconf.rb — a hook designed for compiling native extensions. StubMaker uses this not to build anything useful, but as a trigger to pull a 22 MB Rust-based loader from a GitHub release page (now taken down). That loader embeds a Go-based stealer called wincfg, which carries a DLL payload named abe_payload.dll.
That DLL is doing something notable: it's circumventing App-Bound Encryption, Google's attempt to harden credential storage in Chromium-based browsers. ABE was introduced specifically to stop info-stealers from trivially accessing saved passwords by tying encryption keys to the browser process. StubMaker's operators wrote a bypass for it. That's not something you build in an afternoon — it means whoever is behind this has real engineering resources and is keeping current with Google's defensive mitigations.
What the stealer collects:
Everything gets packaged into a password-protected ZIP and uploaded to Gofile — a legitimate file-sharing service — with the download link sent back to the operator over unencrypted HTTP. Exfiltrating through a trusted file host is a common evasion technique: network security tools see traffic to gofile.io and often don't flag it.
## Who's Actually at Risk
The most important thing to understand about this campaign is who writes Ruby.
Ruby's core user base is web developers, particularly those working with Rails. That community includes a lot of fintech, startup, and infrastructure tooling shops. The gems being typosquatted — Bundler, ActiveSupport, i18n — are not obscure libraries. They're dependencies that appear in virtually every Rails project. A developer who installs a typosquatted version of one of these doesn't know they've done it. They typed fast, the package installed, no errors appeared, and extconf.rb ran silently in the background.
The Windows targeting narrows the exposure somewhat — Ruby on Rails development skews Linux and macOS — but Windows developer machines exist in every shop, and the credentials being targeted (browser-stored passwords, crypto wallets, Telegram sessions) are platform-agnostic targets even when the malware is Windows-only.
## HackWire Analysis
The real story here isn't the typosquatting — clumsy name imitation is one of the oldest supply-chain tricks in the book. The story is what happens after a package gets pulled.
RubyGems' namespace reuse policy is a vestige of a simpler era when package registries weren't adversarial terrain. PyPI addressed this years ago by reserving yanked namespaces. npm has debated similar protections. RubyGems has not moved. The result is a category of attack that works specifically *because* defenders took the right action — the original malicious gem was yanked — and the platform converted that defensive action into a new attack surface.
The StubMaker operators weren't clever enough to build good typosquats (the researcher quoted in the original reporting literally described them as "clumsy"). But they were clever enough to write an ABE bypass and exploit a documented platform behavior. That combination — mediocre OPSEC paired with real technical depth on the payload side — is increasingly common. It suggests operation by a team with separate responsibilities: someone handles infrastructure and delivery (poorly), someone handles the malware engineering (well).
The unvalidated Author field deserves a separate flag. Every package registry that allows free-text metadata without validation is providing free cover to threat actors who want to fragment attribution. If RubyGems required Author to match Owner, this campaign's sixteen packages would have been trivially linked. Instead, investigators had to piece together account infrastructure to connect them. Small policy changes like this cost registries almost nothing to implement and meaningfully raise attacker costs.
For defenders: if your development environment includes Windows machines running Ruby tooling, audit your Gemfile.lock for any of the sixteen package names. Review your extconf.rb execution logs where available. If your organization uses Bundler (you do), confirm you're pinning dependencies and verifying checksums. The corporate risk here is specifically credential theft from developer machines — a developer's browser-stored credentials often include access to source control, cloud consoles, and internal tools that have nothing to do with their Ruby project.
The broader lesson is one the supply chain security community keeps relearning: package registries are infrastructure, not just indexes. When their design choices make attacks easier, developers pay the cost.
— HackWire Editorial
## Related Coverage