A malicious Ruby gem ran a credential-stealing worm as soon as it was installed

A Ruby gem that described itself as a set of string helpers did much more than slugify text. Socket’s threat research team said installing strutil-core version 1.0.1 was enough to run a credential-stealing worm. The package was removed from RubyGems about five hours after the malicious version appeared. Socket has not confirmed any victims.

What Socket found

In a report published on November 6, 2026, Kush Pandya at Socket describes this sequence:

• A RubyGems account named jamnajiea published a clean strutil-core 1.0.0 on November 1, then published 1.0.1 less than two hours later.
• Socket’s scanner flagged the malicious file 70 seconds after 1.0.1 appeared. RubyGems later removed both versions, about five hours after the malicious release, according to a sandbox run Socket cites from Bitbison.
• The gem was a new package, not a hijacked existing project. Socket found no public projects that depended on it, and it has not confirmed that the worm infected any other packages from this gem.
• Installing the gem, or running bundle install against a lockfile that resolved to 1.0.1, was enough. An application did not have to require it.

The installer used a native-extension hook that RubyGems runs during gem install. Instead of building anything useful, that hook fetched a copy of the Bun JavaScript runtime and ran a large bundled script. Socket says the payload is a later build of the testmetest worm, itself part of the Miasma family that grew out of the publicly released Shai-Hulud toolkit. Shared code does not by itself prove the same person is behind every build, the report notes.

What the script is written to do, based on Socket’s static analysis and a sandbox run of the installer, includes:

• Collecting cloud, CI, package-registry, SSH, AI-tool and wallet credentials, then sending them to an attacker-controlled server, with GitHub and GitLab as fallbacks.
• Code that can republish poisoned packages to RubyGems, npm and PyPI if it obtains the right API keys, plus other spreading routines. Socket confirmed those routines are present. It did not confirm that this gem successfully published anything downstream.
• Installing persistence that can download and run further scripts, and writing configuration into local AI coding tools and repositories so that opening a project can run the payload again.
• A particularly nasty follow-up: if the worm obtained a GitHub token, it can install a monitor that deletes the user’s home directory when that token starts being rejected. Revoking the token, which is the usual first response, is what triggers the deletion.

Socket also documented a related PyPI package, pystr-codec, published on October 31, that used the same collection server.

What this means for you

If you never installed strutil-core 1.0.1, there is nothing to clean up from this specific package. Download counts are not victim counts, and Socket does not know how many systems installed 1.0.1 during the short window it was public.

If you did install it, uninstalling the gem is not enough. The payload is written to persist outside the gem folder and to hold on to long-lived credentials. Treat that computer, and every secret it could reach, as compromised.

What you can do

1. Search Gemfile.lock files, CI caches and container images for strutil-core. If 1.0.1 is there, isolate that host before you rotate anything.
2. On an infected Linux or macOS machine, stop and remove the persistence Socket names (net-health-checker and pkg-runtime) before you revoke a stolen GitHub token. The report is explicit: revoking the token first can cause the monitor to delete the home directory. Then rotate credentials from a clean device and rebuild the host.
3. Rotate RubyGems, npm, PyPI, GitHub, GitLab, cloud, SSH and AI-provider credentials that were available to any affected machine or CI runner.
4. Look through packages you maintain for unexpected patch releases, especially a gem that suddenly grew an installer script you did not add, and remove unrecognised AI-tool or editor hooks the report describes if you find them.

How Frame helps

This one is about a malicious package on a developer’s machine, not a published list of customer emails. The checks above are the useful part. If a later notice names leaked account addresses, Frame can also look up your verified emails in Have I Been Pwned’s breach database. Frame never collects or stores the leaked records themselves.

Related coverage

• A malicious LiteLLM release stole credentials for about two hours: another install-time credential stealer delivered through a language-model tooling package.
• OVHcloud CLI downloads were swapped for a secret-stealer: a trusted developer tool that delivered something other than what people thought they were installing.

Sources

• Socket, Shai-Hulud Descendant Surfaces in Malicious Ruby Gem That Steals Credentials and Poisons AI Tools, November 6, 2026