Researchers have identified a new campaign focused on Typosquatting op RubyGems. It involves deceptive Ruby packages that look like popular dependencies. The true intent is different, however: the so-called StubMaker collects login and browser data, and also targets crypto wallets and Telegram information.
The packages have since been removed from RubyGems, but the technique behind the attack shows how vulnerable a software supply chain can be—especially when there is name reuse, install automation, and insufficient validation of package metadata.
What is StubMaker, and why is it dangerous?
The malware behind this campaign is labeled by researchers as StubMaker. It is a Windows-based information stealer. According to OpenSourceMalware, the threat collects, among other things:
- Browser credentials and data from Chromium-based browsers
- Cryptocurrency wallets and seed phrases
- Telegram Desktop data
- additional information such as extension data, browsing history, and also payment card numbers
The key point is that the attacker does not deliver a “normal” Ruby implementation that you would expect to find directly in the package code. Instead, during installation a chain of steps is triggered that ultimately enables the real theft.
Typosquatting on RubyGems: 16 packages with confusing names
The campaign consisted of 16 RubyGems packages. They were published with names that closely resemble existing, commonly used Ruby dependencies—except for small typos. This means developers who type “quickly,” or who do not double-check which gem they install, can still end up installing the malicious version.
The gem names included in the campaign were, among others: ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler, and brundlef.
At the time of publication, the packages were quickly flagged on RubyGems, after which they were withdrawn. Still, it’s important to note: once such a package has gone through a build or install process, the damage may already have been done.
How do attackers get it executed? Install hooks and a “fake build” phase
A notable element is the way the attack is triggered. StubMaker takes advantage of RubyGems behavior involving extconf.rb. During installation, this file can be automatically executed to configure native extensions. On its own, that is legitimate—Ruby often uses this mechanism for components in C/C++/Rust.
In this campaign, however, that “normal” hook is turned into a delivery vehicle. StubMaker generates a Makefile and stub scripts that make it look like everything is being built properly. As a result, the installation can appear “clean” from the outside, while the real payload is not fetched and started until later—through the installer hook.
Specifically, a loader of approximately 22 MB is downloaded from a GitHub release. This GitHub source is no longer accessible. Next, the loader starts a Go-based stealer (named wincfg) that contains the theft logic.
What data is stolen from browsers and crypto wallets?
The stealer includes an additional DLL (named abe_payload.dll) that targets Chromium-like browsers, including Google Chrome, Microsoft Edge, Brave, and Opera. Other browsers with similar mechanisms are also mentioned, such as Vivaldi, Yandex, Avast/AVG Browser, and CCleaner Browser.
The theft focuses on browser information where the attacker bypasses protections around app-bound encryption. It is not only account data or cookies that are targeted, but also items such as:
- Extension data
- Browsing history
- Payment card numbers
In addition, StubMaker explicitly looks for crypto wallets and seed phrases, and it collects data from Telegram Desktop. It also requests the victim’s public IP address via an external service.
After collecting the data, it is packaged into a password-protected ZIP file. Then the file is uploaded to a storage service (Gofile), and the resulting download link is sent to the attacker over a non-encrypted HTTP connection.
Why could this stay “working” for so long? Reuse of package names
According to researchers, the campaign was not only disruptive because it contains malware, but also because it benefits from RubyGems behavioral choices. In at least two cases (involving the packages brumdler and brundlef), the attacker abused a situation where a namespace can be claimed again once all versions of a gem have been yanked.
The packages were originally published by another user (named “gemlewqqhu1”), and then reclaimed by two accounts that appeared in the campaign (“mod8rz41mje” and “rbq95bwt6q”). As a result, what should have been “dead” could still be reused for attacks.
It is also notable that for each gem, the attacker used a different Author name to make the packages less obviously connected. That could suggest a way to obscure central ownership, but the Author field is, according to the researchers involved, an unvalidated plaintext that does not necessarily match the actual owner.
Impact on teams: what does this mean for your Ruby software supply chain?
Even if a malicious package is removed quickly, the risk remains as long as developers and CI/CD processes can pull it in. This type of campaign highlights that you cannot rely solely on “vendor patches” or only on runtime monitoring.
For Ruby environments, these are practical points to consider:
- Check gem names for typos in requirements and scripts (especially when code has been reused).
- Use version pinning and follow consistent dependency locks where possible.
- Limit who can publish and where your organization automatically accepts updates.
- Review install hooks in dependencies and watch for files that are executed automatically.
If you regularly add new gems into your chain, it’s worth adding a lightweight check that flags suspicious naming or unexpected install behavior right away.
More supply chain signals: npm also gets typosquatting variants
The publication of StubMaker coincides with other findings in the broader domain of software supply chain attacks. npm campaigns were also reported in which typosquatting played into executables via the bin field. In those cases, naming conflicts are handled differently than with classic package-name squatting, which means standard mitigation measures are not always sufficient.
There are also signs related to malicious forks of popular npm modules. These show varying behaviors that abuse the installation process to target accounts or inject ad content into delivered media.
The common pattern is clear: attackers look for the weakest link in how packages are installed, configured, and automatically executed.
Related points of interest on this site
If you’ve come across similar mechanisms before, you’ll recognize the overlap with other supply chain and install-hook-related risks. For example, read:
- AI-assisted SharePoint exploit chain with unauthenticated RCE to understand how one mistake in a chain can escalate.
- LiteLLM supply chain attack that impacted 2,500 organizations to see how widespread the impact can be in dependency-related incidents.
- Why patching is not enough for AI-driven vulnerabilities as a complement to the idea that prevention must look beyond fixes alone.
Conclusion: Typosquatting on RubyGems calls for stricter dependency discipline
Typosquatting op RubyGems with StubMaker shows how attackers abuse what appears to be a normal package installation process. The combination of misleading gem names, install hooks, and a “fake build” phase makes the technique hard to detect before the harm is done.
Even though the specific packages have been withdrawn, this is primarily a warning for teams: keep dependency intake tightly controlled, pin versions, verify installation behavior, and ensure CI/CD does not blindly pull in new or suspicious packages. This reduces the chance that a typo—or an apparently harmless update—turns into data theft.
Source: https://thehackernews.com/2026/08/16-typosquatted-rubygems-packages-steal.html
