The same operator, two package registries, one week
On August 18, 2026, security researcher Paul McCarty of OpenSourceMalware disclosed a set of 16 malicious RubyGems packages distributing a previously undocumented Windows infostealer he named StubMaker. Package names included ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler, and brundlef, each one engineered to look like a plausible typo of a legitimate, widely used gem that a developer would install without a second glance during a normal dependency update.
The timing is the part that should worry platform and application security teams more than the specific package names. Two days earlier, on August 16, researchers had already flagged 37 malicious npm packages using an identical payload and the same command-and-control backend. Two registries, one payload, one operator. That pattern rules out opportunistic typosquatting from a lone actor testing the waters, since a single person rarely maintains parallel infrastructure across two ecosystems this cleanly. It reads like an operator with working tooling who is systematically porting the same campaign across every package ecosystem their targets might touch, treating each registry as just another distribution channel for the same underlying malware.
What the malware actually takes
StubMaker is not a proof-of-concept. McCarty's disclosure describes a stealer that harvests browser credentials from Chromium-based browsers, extracts cryptocurrency wallets and seed phrases, pulls Telegram Desktop session data, collects system information and the victim's public IP address, and lifts stored payment card numbers and browsing history. Critically, it circumvents Chromium's app-bound encryption, the protection Google added specifically to stop exactly this kind of credential theft from local storage, which tells you the operators behind it built and tested against current browser defenses rather than reusing a stale toolkit.
For a developer machine, that combination is close to a full compromise of everything stored in the browser: session cookies for internal tools, saved passwords for cloud consoles, and any crypto wallet extensions used for testing or, increasingly, for legitimate business payments. A single infected developer laptop can hand an attacker working credentials into CI/CD systems, cloud consoles, and internal SaaS tools well beyond whatever the RubyGems package itself touched, turning one bad `gem install` into a foothold across your entire delivery pipeline.
Why typosquatting keeps working despite years of warnings
Names like activesupmport and brumdler are not accidents. They are engineered to survive a tired developer glancing at a Gemfile or copying an install command from a Stack Overflow answer or an AI coding assistant's suggestion. Visual similarity defeats human review precisely because human review was never designed to catch a single transposed or added character under time pressure, especially in a Gemfile with dozens of dependencies scrolling past on a routine update.
This is also where AI-assisted coding workflows quietly raise the risk. Coding agents and autocomplete tools trained on public code frequently suggest package names probabilistically, and a typosquatted package with enough surface plausibility can end up in a suggested import or install command without a human ever typing the name themselves. If your engineering org has adopted AI coding assistants without a corresponding tightening of dependency provenance checks, this is the exact failure mode that gap enables, and it scales faster than manual code review ever could because the assistant is generating install commands continuously across every repository your teams touch.
The registry-level detection gap
Both RubyGems and npm rely heavily on community researchers and automated scanners operating outside the registries themselves to catch campaigns like this one, rather than pre-publication vetting that would block malicious packages before they are ever downloadable. That model has held up reasonably well for catching campaigns after the fact, but 'after the fact' still means real developer machines got infected during the window between publication and takedown, a window that can run days or weeks depending on how quickly a researcher happens to notice the pattern.
Organizations that rely solely on the registries' own malware scanning are trusting a backstop that has already been shown, twice in one week, to lag behind operators moving packages across ecosystems. A dependency firewall or private registry proxy that checks packages against known typosquat and malware databases before they reach a developer's machine closes that window meaningfully, and it is a control most mid-sized engineering organizations still do not run by default.
What to do before the next wave lands
Audit your Gemfiles and package.json files now for the specific package names disclosed in this campaign, and extend that check to your CI pipelines and any container images built from cached dependency layers. A typosquatted gem installed once in a build image can persist far longer than the original compromise window if nobody rebuilds from a clean base, quietly reintroducing the stealer every time that image gets pulled for a new deployment.
Longer term, treat this as confirmation that supply chain scanning needs to run at install time, not just at audit time. Tools like Socket, Snyk's package security features, or a private registry proxy with typosquat detection catch this class of attack before code execution rather than after a postmortem. Given that the same operator hit two registries with the same payload inside a week, the operating assumption should be that a third registry, likely PyPI or a container registry, is next, and the organizations that already have install-time scanning in place will simply not notice when it lands.
