Last updated: 26 October 2026. Sources are listed at the end.

October 2026 brought four separate attacks on developers through npm packages and GitHub workflows. Each one is an npm supply chain attack or a close cousin of it: SubQuery’s @subql/common 5.8.3, the GhostAction workflow wave, tensorlake 0.5.144 and the fake “Apex Accelerator” AI copilot packages. In every case, the goal was the same. The attackers wanted tokens, cloud keys and AI API keys from laptops and CI runners.

If your team builds with Node.js or keeps code on GitHub, this guide is for you. We read the primary research for each incident and separate confirmed facts from roundup claims. Then we give tested, read-only commands for your lockfiles and GitHub organisation.

The short answer

  • Search every lockfile for @subql/common 5.8.3, tensorlake 0.5.144 and any @apexacc/ package. If you find one, treat that machine or runner as compromised.
  • Audit your GitHub repos for workflows named security-audit.yml, github_actions_security.yml or security-check.yml that nobody on your team added.
  • Rotate every secret that an affected machine, runner or workflow could read. That includes npm, PyPI, GitHub, cloud and AI provider keys.
  • Then harden: npm trusted publishing, actions pinned by commit SHA, read-only GITHUB_TOKEN, and branch protection on .github/workflows/.

What happened: four attacks in one month

1. SubQuery @subql/common 5.8.3 (5 October)

This was the first npm supply chain attack of the month. StepSecurity reports that on 5 October, the ianhe8x maintainer account pushed two short-lived branches to the SubQuery repo. First, one commit swapped the release workflow for a short manual one. Next, a second commit replaced the built package with a tarball from ci-artifacts.dev. As a result, the published 5.8.3 carried a legitimate-looking provenance record, but its contents came from outside the repository.

The payload is a loader called manifest-cache.js. It runs on postinstall and also when the package is imported. That second trigger matters, because --ignore-scripts alone would not stop it. According to StepSecurity, it reads .npmrc, .env files, SSH keys, cloud credentials and AI tool configs such as .claude.json. On Linux GitHub runners, it also tries to read secrets from runner memory. Finally, it can open a remote shell through ci-artifacts.dev.

StepSecurity notes the account activity does not prove who controlled it, and it has not confirmed any victim installs. When we queried npm on 26 October, 5.8.3 no longer appeared in the version list, and latest pointed to 5.8.2.

2. GhostAction returns (wave peaked 8–9 October)

GhostAction is not strictly an npm supply chain attack, yet it hunts for the same publishing keys. It first appeared in September 2025. In the new wave, attackers used stolen GitHub credentials to commit fake “Security Audit” workflows straight to default branches. However, the dates in roundups differ from the primary reports. StepSecurity documented automated sweeps on 8 October across 345 repositories. Meanwhile, GitGuardian, quoted by The Hacker News, saw the spike on 8 and 9 October.

The workflow reads named Actions secrets, such as PYPI_PASSWORD and CARGO_REGISTRY_TOKEN. It also scans the full git history for AWS, GitHub, GitLab, Anthropic, OpenAI and OpenRouter keys. So a key deleted years ago can still leak. StepSecurity reports exfiltration by plain HTTP POST to 193.32.204.199.

The two sources give very different numbers. StepSecurity counted 378 live malicious workflows on 9 October. In contrast, GitGuardian reported about 1,900 compromised accounts and more than 30,000 targeted repositories. GitGuardian also says GitHub began blocking the workflow on 9 October.

3. Tensorlake npm 0.5.144 (7–8 October)

Endor Labs reports that the first malicious commit landed in the tensorlakeai/tensorlake repository on 7 October. Then the project’s normal release pipeline published tensorlake 0.5.144 at 01:12 UTC on 8 October. Six tensorlake-native-* packages at the same version shipped in the same run.

This is a Shai-Hulud variant, and the only self-spreading npm supply chain attack of the four. A preinstall hook runs lib/setup.mjs, which fetches the Bun runtime and runs a large obfuscated payload. It steals npm, GitHub, cloud, Vault and Kubernetes credentials. It also tries to republish itself into packages the victim controls. Aikido also reports a dead-man’s switch that wipes the machine if an embedded GitHub token is revoked. Endor’s write-up does not mention the wipe, so treat that detail as reported by Aikido.

Endor names 0.5.143 as the last clean release. Newer versions exist on npm, but neither report we read confirms them, so check the maintainers’ notice before upgrading.

4. Apex Accelerator fake AI copilot packages (reported 12–19 October)

Elastic Security Labs published this research on 12 October; The Hacker News covered it on 19 October. A fake Web3 accelerator, “Apex Arena”, lured crypto founders with free AI credits. It shipped two npm packages: @apexacc/cli and @apexacc/audit.

The CLI is a near-copy of an open-source coding agent. However, its bootstrap overwrites OPENROUTER_BASE_URL so that prompts, code and tool output flow to arena.apexaccs[.]org. It also writes an attacker-controlled MCP server into ~/.apex/agent/mcp.json. Elastic also found Windows and macOS stealers that grab browser data and AI client configs.

On 26 October, npm returned “not found” for @apexacc/audit, but @apexacc/cli was still listed. Do not install it.

Am I affected?

The quickest way to check for an npm supply chain attack is to read your lockfiles, not your package.json.

Package or campaignBad version / signLast clean version named by researchers
@subql/common5.8.3 (also avoid 5.8.3-onf-rt1)5.8.2
tensorlake and tensorlake-native-*0.5.1440.5.143
@apexacc/cli, @apexacc/auditany versionnone, remove
GhostActionunknown security-audit.yml or github_actions_security.ymlnot a package

Note that @subql/cli, @subql/node-core, @subql/query and other parent packages use ranges such as ~5.8.2. Therefore a fresh install in early October could pull 5.8.3 without any change on your side.

Check your lockfiles

First, run this from the top of your code folder. It lists every matching entry in every package-lock.json, including nested copies. It only reads files.

find . -name package-lock.json -not -path '*/node_modules/*' -exec jq -r '
  .packages | to_entries[]
  | select(.key | test("node_modules/(@subql/common|tensorlake|tensorlake-native-[^/]+|@apexacc/[^/]+)$"))
  | "\(input_filename): \(.key) \(.value.version)"' {} \;

For Yarn and pnpm projects, a simple grep works:

grep -rnE '@subql/common@|tensorlake@|@apexacc/' --include=yarn.lock --include=pnpm-lock.yaml .

Next, check what is actually installed in a project:

npm ls @subql/common tensorlake --all

Also check your global installs, because the Apex CLI was meant to be installed globally:

npm ls -g --depth=0 | grep -E 'apexacc|tensorlake|subql'

Audit your GitHub organisation

These commands need the gh CLI, signed in with a token that can read your repos. Replace your-org with your organisation name. This script lists suspicious workflow file names across all repos:

ORG="your-org"
gh repo list "$ORG" --limit 1000 --json nameWithOwner -q '.[].nameWithOwner' |
while read -r repo; do
  gh api "repos/$repo/contents/.github/workflows" -q '.[].name' 2>/dev/null |
    sed "s|^|$repo: |"
done | grep -Ei 'security-audit|github_actions_security|security-check|codeql_analysis'

A codeql_analysis.yml file is normal in many repos. It is a SubQuery IOC only if someone outside your team added it, so open any hit.

Then search for the GhostAction markers that StepSecurity published:

gh search code "193.32.204.199" --owner your-org
gh search code "AKIA_CTX_START" --owner your-org
gh search code "c=monami" --owner your-org

Finally, list workflow runs for a suspicious file in one repo:

gh run list -R your-org/your-repo --workflow security-audit.yml --limit 50

How to fix it, step by step

  1. Isolate first. If a machine or self-hosted runner installed one of these packages, disconnect it from the network. Because of the reported tensorlake wipe switch, copy any evidence you need before you revoke tokens from that machine.
  2. Rotate from a clean device. Revoke and reissue npm tokens, GitHub PATs, SSH keys, cloud keys, Vault and Kubernetes tokens, and AI provider keys. List your Actions secrets with gh secret list -R your-org/your-repo and gh secret list --org your-org, then rotate each one.
  3. Rotate old secrets too. GhostAction scans the whole git history, so any key ever committed is exposed.
  4. Remove the bad workflow from every branch and fork. Next, delete the bad version from lockfiles and caches, pin the clean version and reinstall.
  5. Rebuild affected laptops and runners from a trusted image. Cleaning in place is not enough for these payloads.
  6. For Apex, delete the apex-copilot entry from ~/.apex/agent/mcp.json, uninstall the package and rotate AI tool credentials.

Harden for the next npm supply chain attack

These incidents share a pattern. Stolen maintainer access or a changed workflow produced a package that looked properly signed. Provenance only proves where a build ran, not that the source was clean. So layer several controls.

  • Use npm trusted publishing (npm CLI 11.5.1 or later). Then, in package settings, choose “Require two-factor authentication and disallow tokens”. npm’s docs also describe npm stage publish, which lets a maintainer approve each CI release.
  • Pin third-party actions to a full commit SHA, not a tag. Also set the default GITHUB_TOKEN to read-only and protect .github/workflows/ with required pull request reviews.
  • Set ignore-scripts=true in CI where your build allows it. However, remember that the SubQuery loader also ran on import, so this is one layer, not a cure.
  • Consider a release-age delay. npm 11 documents a min-release-age setting that skips versions newer than a set number of days. Most bad versions here were pulled within days.
  • Turn on GitHub secret scanning and push protection, so fewer live keys sit in history.
  • Restrict runner egress to known hosts. For example, a block on unknown IPs would have stopped the GhostAction POST.

None of these steps alone stops every npm supply chain attack, but together they shrink the damage.

Check if you were already compromised

After any npm supply chain attack, logs tell you more than package lists. Search proxy, DNS and firewall logs for these published indicators.

  • SubQuery (StepSecurity): ci-artifacts.dev, the file dist/project/readers/manifest-cache.js, a temp file tmp.ts018051808.lock, and a branch named dependabot/github_actions/format/setup-formatter.
  • GhostAction (StepSecurity): outbound traffic to 193.32.204.199 on ports 80 or 3000.
  • Tensorlake (Aikido, Endor Labs): iseekaigogo[.]com, files lib/setup.mjs and lib/Math_Symbol.js, and the string WORMTAG.
  • Apex (Elastic): any apexaccs[.]org subdomain, ccmihr[.]com, and ~/.local/share/cloudsync/ on macOS.

In addition, review npm and GitHub accounts for unknown publishes, repos, tokens or deploy keys.

The India angle

Many Indian product teams and agencies ship Node.js code daily with shared CI tokens. An npm supply chain attack that exposes your credentials may count as a reportable incident. Under the CERT-In Directions of April 2022, covered entities must report within six hours. That rule is in force today. By contrast, the DPDP Rule 7 breach notice applies only from May 2027, so it is not yet in force.

Quick checklist

  • ☐ Ran the lockfile check on every repo and on global installs
  • ☐ Searched the GitHub organisation for the fake workflow names and GhostAction markers
  • ☐ Isolated and rebuilt any affected laptop or runner
  • ☐ Rotated npm, GitHub, cloud, SSH and AI keys from a clean device
  • ☐ Rotated secrets that were ever committed to git history
  • ☐ Switched publishing to npm trusted publishing and disallowed tokens
  • ☐ Pinned actions by SHA and set GITHUB_TOKEN to read-only
  • ☐ Enabled secret scanning, push protection and runner egress limits

We covered similar developer-side compromises in our LiteLLM 1.107.0 compromise guide and the OVHcloud CLI and Railway secret rotation post. If your team uses AI coding agents, also read our AI agents and MCP servers checklist. For a review of your CI pipelines and build servers, see our VAPT services.

Sources

Want a second pair of eyes on your DevOps security? Our VAPT services cover CI/CD pipelines, self-hosted tools and how secrets are stored. For servers, see our Linux server hardening & security audit, or contact us.

Post author avatar

Bhaskar Soni

Bhaskar Soni is a Security Engineer and the founder of Youngster Company, based in Ahmedabad, Gujarat. He works hands-on with Linux server hardening, vulnerability assessment and penetration testing (VAPT), ISO 27001 compliance and OSINT investigations. He writes practical, tested guides for IT professionals and Indian businesses, and every article on this site is written or reviewed by him.

Leave a Reply