October's npm supply-chain attacks and the Node.js security release: a patch-and-rotate plan

October has been a rough month for anyone who ships JavaScript. Two npm packages were taken over and republished with credential-stealing code, and on October 21 the Node.js project shipped security releases for every supported line. None of this needs panic. It does need an afternoon, especially if your app was built quickly and nobody owns its dependencies.

This post explains what happened, using the maintainers' own advisories, and gives a plan small teams can actually finish.

What happened

SubQuery's @subql/common 5.8.3 (October 5)

According to GMO Flatt Security's analysis, malicious code was injected into @subql/common version 5.8.3. It ran through a postinstall hook, stole credentials for AWS, GitHub, Kubernetes, Vault and more, and opened a remote shell. The attacker tampered with the repository's CI workflow and published through GitHub Actions trusted publishing, which made the release hard to tell apart from a real one. The last known safe version is 5.8.2.

Tensorlake's npm package 0.5.144 (October 8)

Tensorlake's own advisory says version 0.5.144 was published from a compromised maintainer account. The attacker pushed code to the repository and released it through the project's real release workflow, so the package carried valid npm provenance. It was live for about an hour and forty minutes.

The payload ran in a preinstall hook. It harvested GitHub and npm tokens, cloud credentials, SSH keys, .env files and AI tool and MCP configuration. It then used those tokens to republish itself into other packages the victim could write to. It also installed a service called gh-token-monitor that deletes the user's home directory if the stolen GitHub token is revoked. The advisory says to remove that service before rotating any GitHub token, which reverses the usual instinct to revoke everything first.

Node.js security releases (October 21)

The Node.js project released 22.23.4 and 24.22.1 (both LTS) and 26.12.1 (Current). The fixes include a high-severity issue in the bundled Brotli decoder (CVE-2026-111497), a DNS flaw where dns.resolve*() silently truncated hostnames containing a NUL byte (CVE-2026-105482), and TLS hostname-verification bypasses. The releases also update dependencies including c-ares and Undici, and change the bundled CA certificates in response to the eMudhra intermediate CA compromise. Node.js notes that end-of-life versions remain affected.

Why AI-built apps are more exposed

Fast-built apps tend to share a few habits. Dependencies get added because an agent suggested them, and version ranges float. Install scripts run on laptops that also hold production keys. CI runs with long-lived tokens that can publish, deploy and read secrets. The Docker base image hasn't been rebuilt since launch. Nobody is wrong to work this way while finding product fit. Once customers rely on the app, though, each habit is a door.

The incidents also bust a comforting myth. Provenance and trusted publishing prove where a package was built. They don't prove the build was honest. In both cases the malicious version came out of the project's own pipeline.

The plan

Step 1: Find out if you installed a bad version

Search every lockfile, in every repository, for the two packages, then look at which versions resolved:

grep -rnE '@subql/common|tensorlake' \
  --include=package-lock.json --include=yarn.lock --include=pnpm-lock.yaml .
npm ls @subql/common tensorlake

Check CI logs too. A build that resolved a bad version while it was live counts even if your lockfile has moved on since.

If you find a hit, follow the maintainer's advisory before anything else. For Tensorlake, that means disconnecting the machine, removing gh-token-monitor, rotating credentials from a different, clean machine, and rebuilding from a trusted image. Then check packages and repositories your tokens could write to for releases or commits you don't recognize.

Step 2: Patch Node.js everywhere it runs

"Everywhere" is the hard part. Make a short list:

• Developer laptops (node -v).
• CI runners, including any setup-node step pinned to an exact version.
• Docker images. A FROM node:22 image gets the fix only when you rebuild and redeploy.
• Serverless and platform runtimes. Managed platforms roll out patches on their own schedule, so check their runtime notes, or log process.versions.node from a deployed function and look.
• Self-hosted servers running Node directly.

Move each one to 22.23.4, 24.22.1 or 26.12.1, or later. If something still runs an end-of-life line, this release is the reason to plan that upgrade now. Node.js doesn't patch those lines.

Step 3: Stop install scripts from running by default

Both malicious packages ran their code during installation. That's the single most useful habit to change.

• In CI, install with npm ci, which installs exactly what the lockfile says.
• Consider npm ci --ignore-scripts, then explicitly run the few build steps you need. Some packages with native code need their scripts, so test this on a branch first.
• If you use pnpm, recent versions don't run dependency build scripts unless you allow them, and the allowBuilds setting lists which packages may. pnpm's minimumReleaseAge setting can also hold back versions published only minutes ago, which is when a hijacked release usually gets caught.

Step 4: Shrink what a stolen token can do

Assume one day a laptop or runner will be compromised, and limit the damage in advance.

• Replace long-lived CI secrets with short-lived credentials where your cloud supports OIDC from your CI.
• Give each token one job. A deploy token shouldn't be able to publish packages, and a database migration token shouldn't reach other projects. Supabase's scoped personal access tokens, generally available since October 6, are a good example of this model.
• Keep production keys off developer laptops. Local development should run against a development database.
• Turn on secret scanning and push protection for your repositories.

Step 5: Make updates boring

Most teams fall behind because updating feels risky, not because they don't care. Pin versions with a lockfile, let a bot open dependency pull requests on a schedule, and make sure CI has enough tests to tell you whether an update broke something. A weekly update you review in ten minutes beats a yearly upgrade that takes a week.

A short checklist

• Lockfiles and CI logs searched for @subql/common@5.8.3 and tensorlake@0.5.144.
• Node.js on 22.23.4, 24.22.1, 26.12.1 or later on laptops, CI, images and servers.
• Docker images rebuilt and redeployed, not just the Dockerfile edited.
• CI installs with npm ci, with install scripts disabled or allowlisted.
• CI uses short-lived credentials, and each token has one job.
• No production secrets on developer machines.
• Dependency updates arrive as small, regular pull requests.

When to get help

If your app runs on a server or container you manage, patching and hardening it is ongoing work, not a one-off. That is what self-hosted Supabase and infrastructure care engagements cover for us: patched runtimes, rotated keys, monitored deploys, and a written record of what changed. If your cloud bill has grown alongside the risk, cloud cost reduction often goes hand in hand.

Not sure where your app stands after this month? Book a free technical assessment, and we'll review your dependencies, runtimes and credentials and tell you what to fix first.