Researchers found 16 look‑alike (typosquatted) RubyGems packages that trick developers into installing a Windows information stealer. The malicious gems run code automatically during installation, pull down additional malware, and then steal browser logins and crypto wallet data before uploading it to attacker-controlled infrastructure.
How the attack worked
Researchers identified 16 typosquatted RubyGems packages designed to look like popular Ruby dependencies. Developers who installed one of these look-alike gems, often due to a simple misspelling, triggered malicious code automatically through Ruby's extconf.rb install hook. This hook acted as a conduit to fetch a 22 MB Rust-based loader from a GitHub release, which in turn launched a Go-based stealer payload on the victim's Windows machine. The stealer harvested browser credentials, cryptocurrency wallet and seed phrase data, and Telegram data, then packaged it into a password-protected ZIP uploaded to Gofile. The resulting download link was sent to the attacker over unencrypted HTTP.
Why it succeeded
The campaign relied on a combination of naming deception and platform behavior that developers may not fully anticipate. Because gem names were near-matches of well-known dependencies, they were easy to overlook during quick installs. The install-time code execution behavior, similar to lifecycle hooks in other package ecosystems, meant that simply installing a package (not even running it) was enough to trigger compromise. In at least two cases, the attacker also took advantage of a RubyGems platform behavior that makes a namespace available for reclaiming once all versions of a gem have been yanked, allowing a malicious actor to republish under a name that looked familiar and previously legitimate.
What to watch for
- Package names that are near-identical misspellings of popular dependencies
- Installations that unexpectedly download large external binaries or loaders
- Gem names that were previously yanked and have since reappeared under new ownership
- Author metadata that varies gem to gem or does not match the listed owner, since this field is unvalidated plaintext
Building resistance
Security and engineering teams can reduce exposure by training developers to verify exact package names before installing and treating look-alike names as a high-risk signal. Because install-time execution can run without any additional user action, download and build steps triggered during package installation should be reviewed and monitored. Teams should also add governance checks around package ownership changes and republished or previously yanked names before allowing them into builds. Finally, developers should be reminded that package metadata, including the Author field, is not validated and cannot be used alone to confirm a package's legitimacy.
Key findings
- A typosquatting campaign published 16 malicious RubyGems packages that installed a Windows info stealer.
- The malware steals browser credentials, crypto wallets/seed phrases, and Telegram data.
- The malicious behavior triggers automatically during gem installation via Ruby’s extconf.rb hook.
- The installer pulls a Rust-based loader from a GitHub release, which launches a Go-based stealer payload.
- Stolen data is uploaded as a password-protected ZIP to Gofile; the resulting link is sent to the actor via unencrypted HTTP.
Who’s being targeted
- Commonly targeted roles: Developers, DevOps, Build/Release engineers, Open-source program office (OSPO), Security engineering (AppSec).
- Affected industries: Software development, Technology, Open-source maintainers and users.
- Attack channels: website.
- Impersonated: A legitimate Ruby dependency on RubyGems (look-alike/typosquat of a popular gem), A previously legitimate gem that was yanked and later reclaimed.
Red flags to watch for
- Package name is a misspelling/near-match of a well-known dependency
- Package ownership/author details look inconsistent or recently changed
- Install unexpectedly downloads large external binaries during installation
- Gem name was previously yanked but later republished by a different owner
- Author field varies and does not match the owner (can be unvalidated text)
- Registry history shows unusual churn in ownership/versions
Frequently asked questions
How did the malicious RubyGems packages infect developer machines?
The malicious behavior triggered automatically during gem installation via Ruby's extconf.rb hook, which pulled a Rust-based loader from a GitHub release that then launched a Go-based stealer payload.
What data did the RubyGems stealer campaign steal?
The malware stole browser credentials, cryptocurrency wallets and seed phrases, and Telegram data, then uploaded it as a password-protected ZIP to Gofile.
Can a previously deleted (yanked) gem name be reused by attackers?
Yes. RubyGems allows a namespace to be claimed by anyone once all versions of a gem have been yanked, and the threat actor exploited this to republish malicious versions under familiar package names.
Can developers trust the Author field on a RubyGems package?
No, the Author field is an unvalidated plaintext field that does not have to match the actual package Owner, so it should not be treated as proof of legitimacy.
Read the video transcript
You typo one gem name, boom, your dev box is leaking browser logins and crypto wallets. These typosquatted RubyGems run extconf dot rb during install, quietly pulling a 22 meg Rust loader from GitHub that launches a Go info stealer. The stealer zips up your browser passwords, seed phrases, and Telegram data, uploads it to Gofile, then sends a plain HTTP link out, no alerts, just gone. Your move: before installing or updating a gem, pause and verify the exact name and owner in RubyGems, if it’s a near‑match or newly owned, don’t ship it.