The npm Infostealer That Hit Jscrambler Went Straight for Your AI Coding Tool Configs. Your MCP Secrets Are the New Loot. Here's the Saturday Audit.
On July 11, someone published malicious versions of the jscrambler npm package (8.14.0 through 8.20.0) straight to the registry under a legitimate maintainer account, bypassing the project's normal release flow. Socket flagged it about six minutes after publication. The package pulls roughly 15,800 downloads a week. Inside was a preinstall hook that drops and runs a native binary on Windows, macOS, and Linux: a Rust infostealer that sweeps the machine for secrets and ships them off over TLS.
Here's the part that should make you sit up. Alongside the usual targets (cloud credentials, CI tokens, browser sessions, crypto wallets, Bitwarden vaults), the malware specifically went looking for the config files of AI coding tools: Claude Desktop, Cursor, Windsurf, VS Code, Zed, and MCP server configurations. It knew where the new keys live.
The loot moved, and the attackers noticed before you did
Two years ago, an infostealer's shopping list was AWS keys and browser cookies. That list just grew a category, and it's the category you've been filling up all year. Every time you added an MCP server, wired an agent to an API, or let a coding tool remember a token so you'd stop pasting it, you created a new plaintext secret in a predictable location. Attackers read the same docs you did. They know that ~/.cursor, your Claude Desktop config, and your MCP server definitions are now as juicy as an .aws/credentials file, and often less guarded.
That's the real story here, and it's bigger than one bad package. Jscrambler is just the delivery truck. Even if you've never heard of it, the reason this attack is worth your Saturday is that it confirms your AI tooling's config files are now a named target, and most of us have been treating them as harmless.
You probably aren't exposed to jscrambler. You are exposed to the pattern.
Let me be fair about the specific incident: it was caught fast, jscrambler rotated its publishing credentials and deprecated the bad releases, and version 8.22.0 is clean. If you don't depend on it, you're likely fine on this one. Do the narrow check anyway, then do the broad one that actually matters.
The narrow check is thirty seconds: grep your lockfiles for jscrambler and confirm you're not on 8.14.0 through 8.20.0. If you somehow are, assume the machine that ran the install is compromised and rotate everything it could reach: this is not a "probably fine" situation.
The broad check is the point of this post. Ask yourself where your AI tool secrets actually sit right now. If the honest answer is "in plaintext, in a config file, in my home directory" (and for most people it is), then the next npm compromise, or the next malicious VS Code extension, or the next poisoned MCP server walks off with them.
The Saturday audit
Do these in order. None of it takes special tooling.
First, find your plaintext keys. Search your home directory and project trees for the obvious config locations (Claude Desktop's config, Cursor and Windsurf settings, Zed, and any mcp.json or MCP server definitions) and see how many contain live API keys or tokens in the clear. Be honest about the count; it's usually higher than you'd guess.
Second, get those secrets out of the files. Move them to environment variables or a real secret manager, and reference them from the config instead of embedding them. Where a tool supports OAuth or short-lived tokens instead of a long-lived key, switch. A secret that isn't sitting in a predictable plaintext path is a secret an infostealer can't grep for.
Third, harden the install path that delivered this. If you're on npm v12, the default block on install scripts already helps, but confirm it's on and understand that import-time payloads (like the AsyncAPI attack the week before this one) route around it, so script-blocking is necessary, not sufficient. Pin your dependencies, review lockfile changes in pull requests like they're code, and treat a new transitive dependency with the same suspicion you'd give a new employee with root.
Fourth, rotate anything you can't prove is clean. If you've been installing packages all year with secrets sitting in plaintext configs, the cheap insurance is to rotate the high-value keys now (the model-provider keys, the cloud creds, the CI tokens) rather than wait to find out whether one already walked.
The honest take
I don't think the answer is to stop using MCP or coding agents, and I'd push back on anyone who reads this as a reason to retreat to a plain text editor. These tools are why a solo operator can do the work of a team, and the secrets they hold are the price of that leverage. The realistic goal isn't zero risk. It's making sure that when (not if) the next malicious package lands on your machine, the thing it finds where your keys used to be is an environment variable reference, not the keys.
The attackers already updated their shopping list to include your AI stack. This weekend is a good time to make sure the shelf is empty when they come looking.
This is a security topic, and if you find something already exfiltrated, treat it as an incident, not an inconvenience: rotate first, investigate second.
Author
Lukas
@lukcombinator