- What happened to npm packages in October 2026
- Why simply installing a package can leak your keys
- How settings files for editors and AI tools were used to stay on a machine
- Five things to ask your contractor or developers
Short answer
Apps and websites are built by pulling in parts (packages) that people around the world publish, and combining them. In October 2026, malicious versions that steal developers' keys and passwords as soon as they are installed appeared one after another on a package registry. The machines at risk are the developers' computers and the automated build systems that install those packages. Even if you do not develop in-house, your server and cloud keys can leak from a contractor's environment. Ask your contractor whether they have a rule against installing versions that were only just published.
What happened
The main cases, from GMO Flatt Security's analyses (both are early reports, and the company notes they may contain inaccuracies):
| Package (date) | Malicious version | Safe version | How it happened |
|---|---|---|---|
| @subql/common (Oct 5) | 5.8.3 | 5.8.2 | An unsigned change altered the publishing workflow, and the version went out through the legitimate automated publishing setup |
| tensorlake (Oct 8) | 0.5.144 | 0.5.143 | A change was pushed directly, without review, from an account with administrator rights |
Both were removed from the registry in about an hour. The people behind both packages were the victims of these attacks.
For @subql/common, the analysis points out that the registry's records made the release look as if it came from the legitimate publishing setup, so the record of where a version was published from could not, on its own, reveal the malicious one. On October 21 a malicious version of LiteLLM, an AI component, also appeared; we covered it in our column on the October fixes to foundation software.
Three safeguards when installing packages
- Settings that skip very recent versions
- Pin versions, upgrade after checking
- Before opening someone else's repository
- Automatic commands in editors and AI tools
- No production keys on dev machines
- If in doubt, stop it before rotating keys
Why simply installing can leak your keys
A package can include commands that run automatically when it is installed. According to GMO Flatt Security's analysis, the malicious tensorlake version ran as soon as someone ran `npm install`, and was built to steal cloud and GitHub credentials, SSH keys, `.env` files, passwords saved in the browser and more, and send them out. The malicious @subql/common version also ran when a program loaded the package, not only at install time, so a setting that stops install-time commands is not enough on its own.
The analysis also says tensorlake left behind a program that watched the stolen token and was built to delete the home folder if it detected the token had been revoked. It advises stopping that program before replacing keys, and backing up data first. If you suspect you were affected, do not act alone; confirm the steps, including their order, with a specialist.
Settings files for editors and AI tools used to stay on the machine
Editors and AI coding tools can be set to run certain commands automatically when you open a folder or start working. This is a useful feature, but according to the analysis the malicious tensorlake version wrote commands into `.vscode/tasks.json` and `.claude/settings.json` so that they would run again the next time the folder was opened.
These settings files can be shared inside a repository (where source code is kept). Before opening someone else's repository, read the settings files in it, and do not trust the folder too readily when your editor asks whether you trust it. The analysis also recommends checking for unfamiliar commits made under an address that imitates an AI tool's name (`claude@users.noreply.github.com`).
What to ask your contractor or developers
Asking these five questions, for example, shows whether they are prepared.
Checklist
- Do you have a setting that blocks versions published only recently (such as min-release-age in npm or minimumReleaseAge in pnpm)?
- Do you use a setting that stops package commands from running at install time (such as ignore-scripts in npm), together with other measures?
- Have you checked that you did not install the malicious versions named in October?
- Is there a rule to check editor and AI tool settings files before opening someone else's repository?
- How many of our cloud and server keys are stored on development computers?
One thing to check today
Send one message to your contractor or developers: "Do you have a setting that stops you from installing package versions that were only just published?"