StubMaker RubyGems Campaign Delivers a Windows Infostealer

What it is

The StubMaker campaign, discovered August 15, 2026, seeded RubyGems with clumsy (not SEO-clever) typosquats of bundler, i18n, rake, and activesupport. It began as two bundler typosquats — brumdler and brundlef — and grew to 16 gems, achieving hundreds of downloads before takedown. Concrete IoCs the summary omits: publisher accounts gemlewqqhu1 ("Taylor Moore"), mod8rz41mje ("Riley Miller"), and rbq95bwt6q ("Alex Davis"); each gem lists a different fabricated author.

How it works

The name refers to make_stub / make_stub.bat — fake compiler stand-ins the installer writes to disk. RubyGems expects extconf.rb to build a native C extension; StubMaker instead generates a Makefile with empty all, install, and clean targets plus stub scripts that just return success. The extension phase reports a clean build while the real work (platform beacon, loader fetch/execution) runs in the install hook. The hook makes exactly one network request — a 22 MB Rust loader from a GitHub release — and everything after decrypts in memory: the loader carries the 11 MB Go stealer in its own data section and never fetches it from a URL.

The detection point that matters

The page's core operational claim: after the first GitHub request, there is no second-stage download and no payload C2. If your detection waits to see a second payload fetch before treating this as full compromise, you are already too late. Alert on the install-time GitHub-release fetch itself, and on unencrypted HTTP to dresslee.com (which receives the Gofile link holding stolen data).

Why takedown didn't stop it

Exploiting a maintainer-acknowledged RubyGems.org behavior (issue rubygems/rubygems.org#1226, discussion #2787): once all versions of a gem are yanked, the namespace opens for any account to reclaim with no reservation period. A second account republished brumdler after takedown — its history shows two high build-number versions (1.0.44290, 1.0.86147) pushed and yanked August 15 before a 1.0.0 release landed August 16. brundlef now shows as unhosted under yet a third account. Practical effect: the campaign multiplied rather than stopped after the initial removal, so treat the gem names as durable IoCs, not the specific versions.

Caveats

The reclaim mechanism is inferred from behavior and version history ("whatever the exact mechanism"); the linkage to a parallel npm campaign is stated as a post-publication update.