GitHub, npm, and SSH keys
The malware could search for various GitHub and npm tokens, the contents of .npmrc files, and private SSH keys.
Processing…
Web & cybersecurity
84 malicious versions of 42 TanStack packages were published on npm. CrowdSec links the attack to the cloning of approximately 170 private repositories.
A software supply chain attack led to 84 malicious versions of 42 TanStack packages being published on npm. A few days later, a compromised GitHub account was used to clone approximately 170 private CrowdSec repositories. The incident shows how a JavaScript dependency can expose far more than the contents of node_modules.
The malicious code could search for GitHub and npm tokens, SSH keys, and secrets linked in particular to AWS, Google Cloud, Kubernetes, or HashiCorp Vault. CrowdSec links the incident to the cloning of approximately 170 private repositories.
The incident was not caused by the simple theft of an npm password. TanStack used GitHub Actions and the OIDC Trusted Publishing mechanism, designed to avoid storing a permanent npm token in repository secrets.
During a release, the authorized workflow obtains a short-lived token to communicate with npm. This architecture reduces the risks associated with persistent credentials, but it does not automatically protect against the compromise of the process requesting the token.
According to TanStack’s post-mortem, a GitHub Actions workflow using pull_request_target could execute code from an external pull request while interacting with a shared cache. The attacker reportedly exploited this configuration to poison a cache that was later restored by a legitimate release workflow.
The injected code could then execute in the release environment and retrieve the OIDC token intended for npm from memory. This token was used to publish the malicious versions under the project’s legitimate identity.
The packages were distributed from the official registry, but their publication was authenticated through the identity associated with TanStack. The release workflow had not been modified, and no permanent npm token was reportedly stolen.
On May 11, 2026, two malicious versions were published for each of the 42 affected @tanstack/* packages, for a total of 84 versions. TanStack says it quickly deprecated and then removed them from the registry.
The compromised versions contained an obfuscated JavaScript file of approximately 2.3MB, executed during installation. According to the security advisory published by TanStack and GitHub, it searched for several categories of secrets accessible from the workstation or continuous integration environment.
The malware could search for various GitHub and npm tokens, the contents of .npmrc files, and private SSH keys.
Information available in environment variables or local files could also be targeted and exfiltrated.
The code also had a propagation mechanism. When it found a package maintainer’s npm credentials, it could search for the other packages associated with that account and attempt to republish them with the same malicious content.
The risk therefore does not depend on the data contained in the package itself. It primarily depends on the resources accessible to the process executing its installation script. On a development workstation or in CI, this scope may include private repositories, cloud services, and deployment environments.
On September 16, 2026, CrowdSec discovered that an archive containing code from its GitHub organization had been published on a forum. The company launched an investigation with GitHub to trace the OAuth token used to download the repositories.
According to CrowdSec, the token belonged to the account of a developer who had recently left the company. Some access had already been revoked, but the account remained in the GitHub organization to complete work in progress. The developer’s workstation was reportedly compromised by the attack targeting the TanStack packages.
On May 22, this account was reportedly used to clone approximately 170 private GitHub repositories. Its access was removed on May 25, before CrowdSec became aware of the cloning. The archive only became public several months later.
CrowdSec says it found no modification to its repositories or alteration of its build pipelines or code. The company also states that its databases and infrastructure were not compromised: the account was reportedly used only to clone the repositories.
However, the leak included private code, some email addresses, and several secrets present in the repositories. CrowdSec specifically mentions an AWS token linked to the SNS service that remained usable, but whose limited permissions reportedly prevented it from exceeding its intended scope.
Preventing an identity from having excessive rights does not always stop the initial compromise. However, this separation can prevent an exposed token from modifying infrastructure, repositories, or the most sensitive data.
A token intended to publish notifications should not be able to administer infrastructure, read databases, or modify code repositories.
Read access can already cause a significant leak, but the absence of write permissions reduces the risk of sabotage, code injection, or propagation.
Short-lived tokens, permissions limited to a resource, and rapid revocation reduce the period during which an exposed secret remains usable.
Least privilege does not replace workstation protection or identity monitoring. It provides a containment layer: when a first barrier fails, the remaining permissions determine how far the attacker can go.
A development workstation often concentrates numerous privileges. It may be connected simultaneously to GitHub, npm, a hosting provider, several cloud services, SSH servers, databases, and pre-production environments.
At the same time, this workstation regularly installs code from hundreds or even thousands of direct and indirect dependencies. Some packages have scripts that run automatically during installation.
An npm install command therefore does not merely download JavaScript files. It can execute code with the permissions of the user or CI process that launched it. An attack on npm can thus become a GitHub, cloud, or CI/CD incident.
The attack took place on May 11, 2026. TanStack says the malicious versions were detected, deprecated, and then removed, and that the versions currently available are considered safe. A team using TanStack must nevertheless check whether an affected version was resolved and executed during the relevant period.
The package.json file is not always sufficient. You must examine package-lock.json, pnpm-lock.yaml, or yarn.lock, then compare the versions with the list published in advisory GHSA-g7cv-rxg3-hmpx.
If a compromised version was executed, deleting the package is not enough. GitHub, npm, or cloud tokens, SSH keys, and CI/CD secrets accessible to the environment must be considered potentially exposed.
Secret rotation should ideally be performed from a workstation considered trustworthy, so that the new credentials are not immediately exposed.
GitHub, AWS, Google Cloud, and other platform logs should be analyzed beyond the time of installation. In the CrowdSec case, the cloning reportedly occurred eleven days after the malicious packages were published.
TanStack’s advisory states that an installation with npm, pnpm, or Yarn could trigger the payload when an affected version was resolved. Any environment that executed one of these versions should therefore be treated as potentially compromised.
pull_request_target.TanStack says it strengthened its workflows, their permissions, cache management, and the pinning of certain GitHub Actions after the incident. The case shows that files located in .github/workflows are fully part of a project’s security infrastructure.
Temporarily retaining access may address an operational constraint, but this exception should remain explicit, time-limited, and monitored. An identity that is rarely used remains exploitable if its workstation, session, or tokens are compromised.
No. TanStack published a post-mortem, removed the affected versions, and implemented several security changes. As of May 15, the project stated that the versions then available were safe to install.
The incident also does not mean that npm is inherently dangerous. JavaScript applications necessarily rely on third-party libraries. Rewriting every component would not eliminate the risk and could introduce other vulnerabilities.
The response is instead to treat dependencies, installation scripts, and the pipelines that handle them as a complete part of the attack surface.
Common practices often focus on known vulnerabilities and regularly updating packages. Supply chain attacks add another question: what happens if the new version itself becomes the attack vector?
In this scenario, installing the latest version is no longer automatically protective. Security relies on several layers: version control, analysis of new dependencies, permission separation, workstation protection, publication monitoring, and the ability to renew secrets quickly.
node_modulesThe incident was not limited to the 42 packages published on npm. A compromised dependency could search for information in a development environment. According to CrowdSec’s investigation, one of the access credentials exposed in this way was then reportedly used to clone approximately 170 private GitHub repositories.
The malicious file may be located in node_modules, but its actual target may be GitHub, the cloud, CI/CD, or any other service accessible from the developer’s workstation.
Before installing a dependency, the question is therefore no longer simply whether it works. You must also determine what it could access if it became malicious. This scope determines the real impact of a compromise.
This summary is based on the official post-mortem published by TanStack, GitHub security advisory GHSA-g7cv-rxg3-hmpx, and the incident report published by CrowdSec on September 18, 2026.
WEB & CYBERSECURITY
Code, dependency and sensitive-path audits turn a technical alert into a controlled action plan.
Enter at least 2 characters to start searching.