The Tensorlake npm Compromise Targeted Your AI Tool Configs

On October 8, 2026, a malicious release of the tensorlake npm package, version 0.5.144, shipped a preinstall hook that ran attacker code the moment the package was installed, no import or agent execution required. Socket.dev flagged it within about 11 minutes and it was pulled and replaced, so the exposure window was short. The part worth paying attention to isn't the speed of the takedown. It's the target list: alongside the usual cloud and source-control credentials, this one reportedly went after local configuration and session files belonging to AI coding assistants. That's a category of file most teams have never once thought to protect, and it's sitting on every laptop running Claude, Cursor, or similar tools.

What actually happened#

The compromised version added a preinstall script that launched a loader, which then ran an obfuscated payload via Bun. Because preinstall hooks execute automatically on npm install, no one had to run the SDK, import it, or do anything beyond pulling the dependency into a project. Socket's writeup describes the payload as a credential-harvesting, self-propagating worm in the same family as the Shai-Hulud and ChainDrop campaigns that hit other npm packages back in August 2026. The package carries roughly 12,000 weekly downloads, which gives a sense of the blast radius if detection had taken hours instead of minutes.

Why the target list matters more than the mechanism#

Every npm supply-chain post for the last several years has told you to worry about cloud provider credentials and CI tokens. That's still correct, and still the biggest line item on anyone's exposure sheet. What's new here is credential-stealing malware explicitly reaching for AI tool configuration and session data too, the kind of file that stores an API key or an authenticated session for a coding assistant running locally on a developer's machine. Most teams don't rotate those, don't scope them, and in a lot of cases don't even know where they live on disk. A worm that treats them as just another secret to exfiltrate is a signal that your threat model needs an update, not a one-time incident response.

The install-script problem isn't new, but it's not optional anymore#

npm has allowed packages to run arbitrary code on install since forever, and "just disable install scripts" has been standard advice for years that most teams still don't follow by default, because plenty of legitimate packages (native bindings, browser installs) genuinely need them. The practical fix isn't a blanket ban, it's making script execution an explicit, reviewed exception instead of the default:

# .npmrc — scripts off by default for this project
ignore-scripts=true

# .github/workflows/ci.yml — install without running arbitrary scripts,
# then explicitly rebuild only the packages you've reviewed and trust
- name: Install dependencies without executing scripts
  run: npm ci --ignore-scripts

- name: Rebuild only vetted native dependencies
  run: npm rebuild better-sqlite3 node-pty

If a dependency needs a postinstall step, that's a decision someone makes on purpose, not a default every transitive dependency gets for free.

Treat AI tool config files like credentials, because they are#

Most teams have a secrets inventory for cloud keys, database passwords, and API tokens. Almost none have "the local session file my editor's AI assistant uses to stay authenticated" on that list, and this incident is a direct argument for adding it. A quick audit worth running on developer machines:

#!/usr/bin/env bash
# List local AI-tool config/session paths worth treating as secrets.
# Review contents manually before deciding what to rotate or restrict.
for path in \
  "$HOME/.config/claude" \
  "$HOME/.cursor" \
  "$HOME/.config/github-copilot" \
  "$HOME/.claude.json"; do
  [ -e "$path" ] && echo "FOUND: $path"
done

The goal isn't to delete these files. It's to know they exist, know what they grant access to, and include them explicitly when you write an incident-response runbook for "a dependency may have run arbitrary code on this machine."

Rotation after a worm has to be broader than one token#

The instinct after a compromised install is to rotate the npm token and move on. That's the wrong scope for a worm designed to harvest whatever it can reach. If a credential-stealing payload ran on a machine, the honest response is to rotate everything that machine had access to: cloud credentials, Git and CI tokens, SSH keys, and now AI tool sessions too, not just the one secret that feels most obviously connected to npm. Scoping the rotation to "the thing that seems related" is how a second incident starts three weeks later from a token nobody thought to touch.

The decision, concretely#

• Do your CI pipelines still run npm install with scripts enabled by default? Switch to --ignore-scripts and explicitly allow only the packages that genuinely need a build step, reviewed once, not every time a transitive dependency updates.
• Do you know where your team's AI coding assistants store local config and session data? If not, that's the actual gap this incident exposes, not the specific package name.
• If a dependency on a given machine turns out to have been compromised, does your runbook rotate only the obvious token, or everything reachable from that machine? Write the broader version down before you need it, not during the incident.
• Are you tracking advisories from the package registries you depend on, or finding out about compromises secondhand? A few minutes of lag is the difference between catching this and inheriting it, as the 11-minute Socket detection window shows.

The call we'd make#

Disable install scripts by default in CI and treat any exception as a reviewed decision, not a default every dependency inherits. Separately, go find out where your team's AI coding tools actually store their local credentials and session state, because this incident specifically targeted that category and most security checklists still don't mention it. Our npm supply-chain CI hardening guide covers the pipeline side in more depth, software supply-chain attacks covers the broader pattern this fits into, and our AI agent security piece is the place to start on treating AI tool configuration as the credential it actually is.