Published on gastropod.io on 08-27-2026

16 Typosquatted RubyGems Packages Delivered a Windows Infostealer Through the Native Build Process

Tags: vulnerability-intelligence, software-supply-chain-security, rubygems, ruby, credential-theft, typosquatting

Security researcher Paul McCarty at OpenSourceMalware found the first two malicious gems, brumdler and brundlef, on August 15. By the time The Hacker News covered the campaign, now called StubMaker, the count had grown to sixteen typosquatted packages published across two RubyGems accounts, gemlewqqhu1 and mod8rz41mje, with names like activesupmport, ubnuler, i1l8n, and rakier, close enough to real gem names to catch a mistyped gem install (The Hacker News).

The sixteen (and counting) malicious packages wait for anyone to require them. RubyGems runs a file called extconf.rb during native-extension builds, a step that happens automatically at install time for any gem claiming it needs to compile something. StubMaker abuses that step directly: on install, it beacons the platform details to a hardcoded server, pulls a Windows loader from GitHub, and generates dummy Makefile stubs so the build appears to complete normally rather than erroring out in a way that should theoretically draw attention if you are closely watching... the problem is people don't. (link: OpenSourceMalware).

What actually ends up happening is that two things are chained together to avoid writing anything obviously suspicious to disk. A 22MB Rust loader carries an 11MB Go-based stealer inside it, encrypted with a modified ChaCha20 variant layered with XOR, and maps the decrypted payload directly into memory rather than dropping it as a separate file. The stealer, internally named wincfg, targets more than a dozen Chromium-based browsers, extracting saved passwords, cookies, payment card data, and browsing history. It ships with its own module for defeating Chrome's Application-Bound Encryption protections specifically, on top of harvesting cryptocurrency wallets, seed phrases, and Telegram Desktop data. Stolen data goes out as a password-protected archive uploaded to a public file host, with a separate plaintext report sent to a second domain. After the initial GitHub download, the entire chain runs on what's already been delivered, no further outbound requests to fetch additional stages, which keeps the network footprint unusually small.... especially for something this capable.

Both publishing accounts used false author names in their .gemspec files, a field RubyGems.org has never validated against the identity of the account actually publishing. That gap is what allowed sixteen packages from two accounts look like ordinary, individually authored libraries instead of one coordinated campaign.

what should you do?

Machines that installed any of the sixteen while the campaign was live should be treated as compromised: isolate the host, revoke browser and Telegram sessions, rotate every credential that was stored locally, and treat any recovered seed phrases as burned rather than just exposed.

how gastropod.io could have helped here...

Gastropod tracks publisher account history alongside package identity for RubyGems the same way it does for the other ecosystems it supports, so a fabricated author name in a .gemspec doesn't stand in for a verified one on its own. A burst of near-identical, single-purpose gems from accounts with no prior publishing history reads as the anomaly it is, rather than sixteen unrelated coincidences. Check out the gastropod.io product page for more on how intake-level identity check works.

Sources: