SOLUTIONSQuick answer
In October 2026 attackers published malicious versions of trusted packages, including @subql/common 5.8.3 and tensorlake 0.5.144 on npm and litellm 1.107.0 on PyPI and Docker, and pushed credential-stealing GitHub Actions workflows to hundreds of repositories. If any of these ran on your machines or CI, rebuild from clean images and rotate every secret they could reach.
Key takeaways
- Each attack started with stolen developer or maintainer credentials, then used the project's own release pipeline to publish malware.
- The payloads target secrets: npm and GitHub tokens, cloud keys, SSH keys, Kubernetes configs and AI provider API keys.
- Uninstalling is not enough. The vendors recommend rebuilding affected machines and runners and rotating credentials.
- npm 12 blocks dependency install scripts by default, but @subql/common 5.8.3 also ran when imported, so that default alone would not have stopped it.
- Pin exact versions with a lockfile, limit who can override branch protection, and keep secrets out of logs.
Which packages were compromised in October 2026?
| Date (2026) | What | Bad version | Safe version |
|---|---|---|---|
| 5 October | @subql/common on npm (SubQuery) | 5.8.3 | 5.8.2 |
| From 7 October | GhostAction: malicious GitHub Actions workflows pushed with stolen tokens | security-audit.yml or github_actions_security.yml | Delete the workflow, rotate secrets |
| 8 October | tensorlake on npm | 0.5.144 | Earlier versions; PyPI and Cargo packages showed no compromise |
| 21 October | litellm on PyPI, Docker Hub and GHCR | 1.107.0 and the latest, main-latest, main-stable image tags during the incident | 1.106.2 |
These are not bugs in the code. In each case someone obtained a maintainer's credentials and used them to publish malware under the project's real name, so the packages looked legitimate to anyone installing them.
How did attackers get into trusted release pipelines?
- @subql/common: according to StepSecurity, a temporary branch changed the release workflow to download a tarball from
ci-artifacts.devand publish it in place of the real package, with no hash or signature check. The workflow still had trusted publishing permissions, so the release carried npm provenance. Provenance shows which workflow published a package, not whether that run was authorised. - tensorlake: Aikido reports that the GitHub repository was compromised for about 20 hours before the attacker triggered the npm publish, using commits made under a maintainer's identity.
- LiteLLM: the LiteLLM team says the attacker held GitHub CLI credentials for three developers. When branch protection rejected a change to the release workflow, an organisation owner's credential was used to override it, and the workflow built and published artifacts from a lookalike repository. The team believes the tokens were taken from logs on an internal deployment exposed to the internet.
- GhostAction: The Hacker News, citing StepSecurity, Socket and GitGuardian, reports that leaked personal access tokens were used to commit a fake "security audit" workflow that sends repository secrets and credentials found in the code and git history to the attacker.
What does the malware steal?
The common goal is credentials, which let attackers move on to cloud accounts and to more packages. Reported behaviour includes:
- Reading
.npmrc,.env, AWS, SSH and Kubernetes files and the full process environment, and tryinggh auth token(@subql/common). - Reading secrets from GitHub Actions runner memory and from AWS Secrets Manager, SSM and Vault (@subql/common).
- Stealing CI, cloud and browser credentials, and wiping the machine if an embedded GitHub token is revoked (tensorlake, a Shai-Hulud variant according to Aikido). Plan token revocation on infected hosts carefully.
- Running on every Python start in the environment, including
pip, throughcook.pthandsitecustomize.pyfiles, and loading remote-code tools (litellm 1.107.0).
How do I check whether my projects are affected?
- Search lockfiles (
package-lock.json,pnpm-lock.yaml,yarn.lock,requirements*.txt,poetry.lock) for the bad versions above, including as indirect dependencies. StepSecurity notes that@subql/cli,@subql/node-coreand@subql/querycould pull in 5.8.3 through version ranges. - For LiteLLM, run
pip show litellmand look forlitellm-1.107.0.dist-info,cook.pthandsitecustomize.py. The LiteLLM team advises not runningpipfirst in a suspect environment, and says finding nothing does not prove it is clean. - Check Docker images built or pulled on 21 October that used
litellm:latestor themain-*tags. - Search your GitHub organisation for
security-audit.ymlorgithub_actions_security.ymladded since 31 August 2026, including in forks. - Review CI logs from the affected dates for installs of these versions.
What should I do if a compromised package ran?
- Isolate and rebuild: treat the laptop, server or CI runner as compromised. Rebuild containers, virtual environments and runners from clean images rather than just uninstalling.
- Rotate secrets: npm and PyPI tokens, GitHub tokens, cloud keys and instance roles, SSH keys, Kubernetes and Vault credentials, database passwords and AI provider API keys that the process could read.
- Audit use: review cloud logs (for example AWS CloudTrail) and GitHub audit logs for activity from unfamiliar locations after the install time.
- Pin a safe version:
@subql/common@5.8.2,litellm==1.106.2, and removetensorlake@0.5.144.
How can teams protect their software supply chain?
No single setting would have stopped all four attacks, but each step removes an easy path:
- Commit lockfiles and install with `npm ci` (or the equivalent) so builds use reviewed versions rather than whatever was published that morning.
- Upgrade to npm 12. GitHub made dependency install scripts, Git dependencies and remote tarball dependencies opt-in, and you approve trusted scripts with
npm approve-scripts. Remember that code can still run when a package is imported. - Protect release pipelines: require signed commits and reviews on release workflows, keep the number of organisation owners who can bypass branch protection small, and avoid temporarily widening release permissions.
- Prefer trusted publishing (OIDC) over long-lived publish tokens. GitHub is restricting npm granular tokens that bypass two-factor authentication.
- Keep secrets out of logs and do not expose internal tools such as AI gateways to the internet without authentication.
- Limit what CI can reach: give each job only the secrets it needs and restrict outbound network access from build runners where you can.
If you run a website rather than a codebase, the same pattern hit WordPress this month; see our post on the Rank Math PRO and UpdraftPlus breaches. For background on why attacks are speeding up, read how AI agents hacked 100+ websites.
Naarvix builds and maintains web and mobile products for clients worldwide, with locked-down CI, pinned dependencies and documented secret rotation as part of the handover. If you would like a review of your pipeline, see our custom software development service or get in touch.
Sources
- LiteLLM: security incident, 21 October 2026
- StepSecurity: SubQuery ecosystem compromised
- Aikido: tensorlake npm package compromised
- The Hacker News: credential-stealing GitHub Actions workflows (GhostAction)
- GitHub Changelog: upcoming breaking changes for npm v12
- The Hacker News: npm 12 disables install scripts by default
Frequently asked questions
What is a software supply chain attack?
It is an attack on something your software depends on, such as an open source package, a build tool or a vendor's update system, instead of on your own code. Malware published through a trusted package reaches everyone who installs that version.
Does npm 12 stop malicious packages?
It removes one common route. npm 12 blocks dependency install scripts unless you approve them, but malware can also run when a package is imported, as with @subql/common 5.8.3. Lockfiles, reviewed upgrades and limited secrets are still needed.
Which LiteLLM version is safe?
The LiteLLM team says to pin litellm==1.106.2 or another version published before the incident. Only 1.107.0 and the Docker tags pointed at it on 21 October 2026 were compromised; the official GitHub source tag did not contain the malicious files.