What happened
On August 18, 2026, Corgea and NEXSIGHT published technical analyses of StubMaker after the malicious gems were published and yanked during August 15-16, 2026. The validated sources explicitly name brumdler, brundlef, ri18nr, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, ubnuler, ubnlder and activesupmport. Snyk classifies brumdler as malicious and says all versions should be avoided.
The installer abused extconf.rb to execute attacker-controlled Ruby code and created an empty Makefile plus make_stub and make_stub.bat files so the extension build appeared to complete normally. One observed beacon was POST http://193.70.34.101:20099/vote with User-Agent Ruby and the platform value Windows. On Windows, the gem retrieved a 22 MB Rust loader from https://github.com/bebraz1/qPzM50V1AKG0rVlH/releases/download/null/main.exe and saved main.exe in the user’s Downloads directory.
The loader unpacked an embedded Go information stealer in memory. The reported collection functions targeted Chromium passwords, cookies and payment data, cryptocurrency wallet material, seed phrases and Telegram Desktop data before uploading encrypted archives and sending the resulting location to operator infrastructure. NEXSIGHT reports that the malicious gems accumulated more than 1,300 downloads before removal.
Attribution posture: No actor identity or sponsor has been established in the cited sources. The cited pages did not publish a SHA-256 hash for main.exe. The exact package, process, network and path artefacts nevertheless provide sufficient evidence for an immediate enterprise hunt, while any downstream repository, cloud or signing compromise remains unresolved until affected-host credentials and sessions are reviewed.
Why this matters now
Removal from RubyGems prevents new downloads but does not reverse code execution on developer systems that installed the packages. The observed chain used a legitimate native-extension build hook, made installation appear successful and then crossed from package management into browser, wallet and messaging data collection.
Developer workstations often hold repository tokens, cloud credentials, signing material and authenticated browser sessions. A commodity-looking infostealer on one such host can therefore become a software supply-chain or cloud-identity incident even when the malicious package never reaches production.
The exact IP address, path, executable name and package names support immediate hunting. The absence of a published file hash means teams should combine those indicators with process ancestry, package-install records, network telemetry and secret-use history rather than rely on a single signature.
The decision for security leaders
Assign application security and endpoint teams a joined investigation. Package inventory alone establishes exposure, while endpoint and network evidence determines whether installation executed, the loader ran and the stealer reached data or credentials.
Treat a positive developer-host finding as an identity incident. Revoke active sessions and rotate repository, cloud, signing, package-registry and browser-accessible secrets according to what the host could reach, rather than limiting remediation to deleting the gem.
Use the incident to enforce time as a supply-chain control. RubyGems’ Bundler documentation provides a cooldown option for excluding newly published versions during dependency resolution; enterprises should define an approval process for bypassing that delay.
Evidence of closure
- Package inventory confirms no named gems remain in repositories, caches or hosts.
- Endpoint hunt records installation, process, file and network results for each exposed host.
- Credential-rotation record covers every secret accessible from confirmed affected hosts.
- Dependency policy enforces cooldowns or documented approval for fresh releases.
The Security.io assessment
The strongest evidence is the convergence of exact package names, an installation path, a fixed beacon, a loader URL and documented collection functions. That is sufficient to support targeted hunting even though RubyGems has not published a complete incident report in the sources used here.
The campaign’s practical blast radius depends on where the packages were installed and what the workstation could access. A developer laptop with authenticated cloud consoles and signing credentials represents a materially different incident from an isolated analysis host, so asset context must drive escalation.
Attribution posture: No actor identity or sponsor has been established in the cited sources. Similar tooling or infrastructure discovered elsewhere should not be assigned to a named group without independent corroboration.
The cited pages did not publish a SHA-256 hash for main.exe. Teams should compensate by correlating extconf.rb execution, child processes from ruby.exe or gem.exe, the Downloads path, the GitHub Releases URL, the fixed IP endpoint and subsequent secret use.
Questions for the morning meeting
- Can we search developer endpoints and caches for every named package?
- Which credentials were accessible to affected development workstations?
- Do package installs generate retained process and network telemetry?
- Are new dependency versions delayed until they receive scrutiny?