Cybersecurity researchers have flagged a new typosquatting campaign targeting RubyGems users with a Windows-based information stealer.
OpenSourceMalware, which discovered the activity on August 15, 2026, is tracking the threat under the moniker StubMaker. The complete list of packages published as part of the campaign is below –
- ubnuler
- ubnlder
- ri18nr
- reaker
- rakier
- orakw
- joxn
- ise18n
- ioe18n
- ie18u
- iai8n
- i1l8n
- i18om
- activesupmport
- brumdler
- brundlef
“This new malware harvests browser credentials, cryptocurrency wallets, seed phrases, and Telegram data,” security researcher Paul McCarty (aka 6mile) said. “All of the malicious RubyGems packages appear to be typosquats of popular Ruby dependencies, but rather than the clever SEO-fueled typosquats we’ve seen from other threat actors (e.g., events-channel imitating the popular Node.js events module), they’re all clumsy typos.”
The 16 gems have been published by users named “mod8rz41mje” (aka Riley Miller) and “rbq95bwt6q” (aka Alex Davis). As of writing, the packages have been yanked from RubyGems.
In at least two cases – brumdler and brundlef – the threat actor has been found to take advantage of a known RubyGems behavior that makes a namespace available for anyone to claim once all versions of a gem have been yanked. In both instances, the packages were originally published by “gemlewqqhu1” (aka Taylor Moore) before they were reclaimed by the aforementioned two accounts.
Jenn Gile, co-founder of OpenSourceMalware, told The Hacker News that although the campaign was disrupted fairly early, it became more effective because of Ruby’s “poor design choices” via package name reuse and an unvalidated author field.
“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,” Gile said. “What should have been forever dead was revived to compromise more people.”
“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 attack chain, at a high level, makes use of an “extconf.rb” hook to trigger the execution hook. Similar to npm’s lifecycle hooks, “extconf.rb” is run automatically when a user installs a gem. The file is typically used to configure native extensions written in C, C++, or Rust that are bundled inside a Ruby package within the “ext/” directory and compiled during installation of the gem.
In the case of StubMaker, the Ruby hook acts as a conduit to fetch a 22 MB Rust-based loader from a GitHub release, which, in turn, launches a Go-based stealer (“wincfg”) payload embedded into it. The GitHub account (“github[.]com/bebraz1”) is no longer accessible.
The stealer, for its part, incorporates a DLL payload (“abe_payload.dll”) that’s used to extract credentials from Chromium-based web browsers (i.e., Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, Yandex, Avast, AVG, and CCleaner Browser) by circumventing app-bound encryption (ABE) protections added by Google.
It also collects extension data, browsing history, and 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.
Once the relevant data is captured, it’s uploaded to Gofile in the form of a password-protected ZIP archive and the resulting download link is sent to the threat actor (“dresslee.com”) over an unencrypted HTTP channel.
“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,” McCarty explained.
“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.”
The disclosure coincides with the discovery of two software supply chain campaigns targeting npm –
- A cluster of 21 npm packages that typosquatted CLI binary names exposed by Google’s scoped packages to deliver a minimal postinstall beacon. “The packages did not squat package names,” SafeDep said. “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 cluster of Baileys npm forks that engage in a variety of malicious behaviors: covertly make the installer’s WhatsApp account follow channels the package author controls and inject the author’s advertising URL into every image and video the bot sends.
“Continuous monitoring of the npm registry records 4,250 package names that contain baileys and another 112 that contain libsignal-node,” SafeDep said, adding the malicious behavior has been observed in 70 package names built on Baileys across 343 versions and 15 libsignal-node impersonators across 38 versions.
Update
The StubMaker campaign has also been observed targeting npm with a set of 37 packages that make use of a postinstall hook to retrieve the same GitHub-hosted Windows loader, which then unpacks a Go infostealer targeting browser credentials and sessions, payment-card data, cryptocurrency wallets and seed phrases, Telegram data, and host information.
“This was one threat actor running two typosquatting fronts against two package ecosystems, sharing a single payload and a single C2 backend,” Gile said.
As with the malicious RubyGems, the npm packages are typosquats of popular packages such as axios, chalk, commander, lodash, typescript, and react. None of the packages are available for download as of writing. The names of the typosquats are below –
- axois-http, axious-core
- chalk-core, chalk-lib, chalk-util, chalk-es
- comand, comander-cli, comanderjs, commandorjs, commandor-cli, commandor-core, comander-lib, commandor-lib, commander-lib
- loadashjs, lodash-lib, ladash-cli, lodahsjs, lodsh-cli, lodahs-cli, lodhash-cli
- typescirpt-cli, typscript-cli, typesript-cli, typscript-core, typescriptt-cli, typescrip-cli, typescipt-cli, tyepescript-cli, typescirpt-core, tyepescript-core, typesript-core, typescipt-core, typescriptt-core
- raectjs
- testingsmthb1g
OpenHack, which also published details of the activity, said the packages were published on August 16, 2026. If any one of the packages was installed on a Windows machine during the time it was live, it’s recommended to isolate the host, rotate credentials, and remove the malicious libraries.
OpenSourceMalware has also flagged some key differences between the two campaigns –
- The gems use “extconf.rb,” whereas the npm packages employ a postinstall hook to trigger the execution of the loader
- The Ruby installer decodes its loader URL from Base64, whereas the npm installer uses repeated-key XOR with a hard-coded key
- The gems were published during a two-day period, whereas the npm packages were uploaded to npm in an eight-minute window across five accounts
“RubyGems’ pattern was sequential and single-point-of-failure,” Gile added. “One account gets caught, the operator adapts and returns. npm’s pattern spread the same burst across multiple burner accounts simultaneously, so losing any one account wouldn’t have taken down the whole batch. However, in spite of the different approach, the npm packages were rapidly discovered and removed as a cohort.”
(The story was updated after publication on August 19, 2026, to include the campaign’s targeting of npm.)
