Malicious Tanstack Package Steals Developer Environment Files

On April 29, 2026, a malicious npm package was identified, actively impersonating a component of the popular TanStack project. This fraudulent package was designed to silently exfiltrate developer environment files the moment it was installed.

The attacker registered the unscoped “tanstack” package name on npm, dressed it up as a legitimate video player SDK called “TanStackPlayer,” and embedded a credential-harvesting script inside it that ran without any visible warning.

The campaign lasted a brief but damaging 27-minute window. Between 17:08 and 17:35 UTC, four versions of the malicious package were pushed to npm in rapid succession: 2.0.4, 2.0.5, 2.0.6, and 2.0.7.

Each version carried a postinstall hook, a script that fires automatically whenever a developer runs npm install.

Prior to this wave, the previously available version 2.0.3 from March 2026 had no such hook and was clean.

The package had recorded roughly 19,830 downloads in the month before the attack began, giving the attacker a ready pool of unsuspecting targets.

Aikido researchers identified and analyzed the malicious campaign, noting that the attacker did not need to compromise an existing maintainer account, exploit a vulnerability, or phish a CI system.

The attacker simply registered a convincing package name, inserted a one-page postinstall script, and let npm installations do the rest.

The package README was polished with sponsorship badges, download shields, a feature comparison table, and code examples, making it look legitimate enough to pass a casual review.

The real TanStack organization, responsible for widely used libraries like TanStack Query (which receives around 8 million downloads per week), had no connection to this package. The attacker exploited the fact that the unscoped “tanstack” name had been sitting separately since December 2024.

A developer typing “npm install tanstack” instead of “npm install @tanstack/query” would silently install this malicious package and trigger credential theft instantly.

The stolen data was routed through Svix, a legitimate webhooks-as-a-service platform, to an attacker-controlled endpoint. By using a trusted third-party relay, the attacker avoided triggering standard network-level blocking.

The stolen payload included file contents alongside system metadata such as Node.js version, platform, and architecture, making the exfiltrated data immediately useful for targeted follow-on attacks.

Live Payload Iteration: How Version 2.0.6 Became the Most Dangerous

What makes this attack particularly notable is the visible live debugging pattern across all four versions. Version 2.0.4 targeted “.env” and “.env.local” directly, but the opt-out check was commented out, leaving developers with no escape hatch.

Version 2.0.5, pushed just three minutes later, briefly switched targets to README.md and AGENTS.md, likely to test whether the webhook receiver was working. Version 2.0.6, published at 17:26 UTC, became the most dangerous iteration.

It dropped specific file targeting entirely and replaced it with a directory sweep using a “collectEnvFiles()” function that gathered every file starting with “.env”, capturing “.env.local”, “.env.production”, “.env.staging”, and “.env.development” in a single POST request. Console output was fully suppressed.

Version 2.0.7 reverted to targeting only “.env” and “.env.local” but added a self-referential dependency on version 2.0.6 inside its own package.json. The attacker was actively present, watching results and refining their payload in real time while the package remained publicly installable.

The files targeted in these attacks typically hold AWS access keys, GitHub personal access tokens, npm publish tokens, database connection strings, API keys for services like Stripe, OpenAI, and Twilio, and OAuth client secrets.

Any of these credentials, once exfiltrated, can lead to full account takeover, data breaches, or unauthorized cloud resource consumption.

Developers should immediately check their lock files and install history for any version between 2.0.4 and 2.0.7 of the “tanstack” package using the following command:

grep -r "tanstack" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

If any affected version is found, treat all environment files present during the install as compromised and rotate the following credentials without delay:

• AWS access keys and secrets (audit CloudTrail for any unauthorized API calls)
• GitHub tokens with repository or organization scope
• npm tokens (revoke and reissue at npmjs.com/settings)
• All database credentials stored in .env files
• Third-party API keys across all affected environment files

For CI pipeline environments, note that the postinstall script also fires during “npm ci”. Developers should check CI provider job logs for the install step and rotate all secrets injected into that pipeline’s environment.

Monitoring outbound HTTPS traffic to “api.svix.com” in network logs around the time of install can also help confirm whether exfiltration occurred.

Indicators of Compromise (IOCs):-

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.