strutil-core Malware: Malicious Ruby Gem Steals Developer Credentials and Can Wipe Home Folders, and What to Check This Week

A Ruby package called strutil-core, version 1.0.1, ran a worm during installation that steals the cloud keys, access tokens and passwords stored on developers' computers and build servers. If anyone who writes or deploys code for your business installed it, treat that machine and every account it could reach as compromised. Respond in the right order, too: revoking one stolen GitHub token too early can set off a command that deletes the user's home folder.

What happened with strutil-core

Socket's Threat Research Team published its analysis on November 6, 2026. Here is the timeline from that report:

• Sunday, November 1, 2026, 02:19 UTC: RubyGems account jamnajiea published strutil-core 1.0.0, described as a string helper library.
• 04:05 UTC the same day: version 1.0.1 followed, less than two hours later.
• 70 seconds after that: Socket's scanner flagged the malicious file.
• About five hours after the malicious release: RubyGems removed both versions.

The gem's RubyGems page now says it is not currently hosted and lists no versions. This was not a hijacked popular package. Someone built a new gem to look harmless. Socket's analysis treats 1.0.0 as clean.

How the malicious Ruby gem runs

The attack runs at install time, so nobody has to use the gem. Ruby gems can include an extconf.rb script, normally used to compile native code. In strutil-core 1.0.1 that script contains no real build logic. On Linux and macOS it downloads the Bun JavaScript runtime (version 1.2.18) and uses it to run a bundled JavaScript file of 5,475,376 bytes (about 5.48 MB). It then writes an empty Makefile so the install looks successful.

Socket says a plain gem install strutil-core -v 1.0.1, or a bundle install that resolves to it, is enough. The application never has to load the gem.

What is confirmed and what comes from code reading

Socket separates the two, and so should anyone retelling this story.

Confirmed in a sandbox run by Bitbison: the code runs during installation and reads credential files. Bitbison recorded reads from 51 credential stores, including .aws/credentials, .npmrc, .pypirc, .gem/credentials, .docker/config.json, .kube/config, and the login files for the Claude and Codex AI coding tools.

Found by reading the code (static analysis), not seen on victims:

• Cloud theft: AWS Secrets Manager and SSM reads across 17 regions, plus separate routines for Azure, Google Cloud, Kubernetes and Vault.
• Exfiltration: stolen data is encrypted and sent to paleasbest[.]top. If that fails, the worm falls back to a public GitHub repository described as "project-utils", then to GitLab.
• Spreading: with a stolen RubyGems key, it injects itself into gems that key can publish and republishes them. It also contains republishing routines for npm and PyPI and creates fake "CodeQL" GitHub workflows. Socket says it has "not confirmed any successful downstream publication from this gem."
• AI tool poisoning: it adds an MCP server named workspace-tools to AI coding tool settings. With stolen Git credentials it can commit files such as .claude/settings.json, .cursor/mcp.json, AGENTS.md, CLAUDE.md and a .vscode/tasks.json task that runs when the folder opens. Depending on workspace trust settings, opening an affected repository in an AI tool or VS Code could run the worm again.
• Persistence: a Python backdoor at ~/.local/share/runtimes/sync.py, run as the pkg-runtime service on Linux or the com.user.pkg-runtime LaunchAgent on macOS. Every hour it checks public GitHub commits for signed instructions.

The home folder wiper: why order matters

The deletion threat applies only on some machines. It is installed when the worm's GitHub fallback successfully uses a stolen personal access token. On those hosts, a monitor called net-health-checker checks that token every 45 seconds for 48 hours. If GitHub rejects the token, the monitor runs rm -rf ~/.

In plain terms: the normal first step in incident response, revoking the stolen token, is exactly what triggers the deletion. Socket's advice is to stop and remove net-health-checker and pkg-runtime first, then revoke and rotate credentials from a clean device.

What is not known

• How many systems were infected. The public ruby-digger tracker records 89 total downloads: all 89 on the clean 1.0.0 and none on 1.0.1. Socket stresses that download counters are not victim counts and says it does not know how many systems installed 1.0.1.
• Whether the worm spread further. The spreading code exists. Socket has not confirmed any packages republished by it.
• Who is behind it. The gemspec names "Mark Tillman" and links a GitHub repository that Socket says does not exist. Socket also links a PyPI package, pystr-codec, that uses the same server.

Why this matters for a business

Developer laptops and build servers hold the keys to production: cloud accounts, code repositories, package publishing rights and customer databases. One install on one CI runner can expose all of them. The AI tool poisoning adds a newer risk: the worm turns trusted coding assistants and shared repositories into ways to reinfect machines. If an outside agency or contractor builds your software, their machines are part of your attack surface too.

What to do this week: strutil-core checklist

To lower the risk from the next malicious package:

• Commit Gemfile.lock and install from it in CI, so a new release cannot slip in unnoticed.
• Review any new dependency before adding it, especially young gems with one owner. Treat a new extconf.rb in a pure-Ruby helper as a warning sign.
• Use a dependency scanner that checks packages when they are published, not only for known CVEs.
• Keep long-lived secrets off developer laptops. Prefer short-lived, narrowly scoped tokens in CI.

strutil-core malware questions people are asking

What is strutil-core?

A RubyGems package that claimed to provide string helpers. Version 1.0.1 ran a credential-stealing worm at install time. RubyGems no longer hosts it.

Was strutil-core 1.0.0 malicious?

Socket's analysis treats 1.0.0 as clean. The malicious code arrived in 1.0.1, published less than two hours later.

Does uninstalling the gem remove the malware?

No. Socket's report states that "uninstalling the gem does not undo an infection," because the payload persists outside the gem directory and steals long-lived credentials.

Is Windows affected?

The install path Socket describes targets Linux and macOS. The bundle also contains a Windows component, but the report does not describe a Windows install path.

Is this the Shai-Hulud worm?

Socket calls it a Shai-Hulud descendant, meaning it shares that worm family's approach of stealing publishing tokens and spreading through package registries.

The bigger lesson

Installing a package means running its code with your access. Lockfiles, review of new dependencies and short-lived secrets turn one bad install from a company-wide breach into a contained cleanup.

For help locking down your development and build pipeline, see security hardening or request a quote.

Get security alerts by email, with the free checklist, at /security-alerts.

Sources: Socket Threat Research: Shai-Hulud Descendant Surfaces in Malicious Ruby Gem; RubyGems.org: strutil-core.