Malicious Tanstack Package Uses Postinstall Script to Steal Developer Environment Files

A malicious npm package impersonating the widely trusted TanStack project was discovered on April 29, 2026, silently stealing 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):-

Version	SHA256 Hash
tanstack@2.0.4	72ec4571e27c06f1d48737477c2b38a4f90d699950dab8946b48591133dc4f90
tanstack@2.0.5	04ee5325c8900c9d644ed81c9012525b6fc19f21c65cef85b6ba98b6a0a23566
tanstack@2.0.6	abc164807947b102164488a08161adb4ee08be6b78a371350a6b156eed0d97d9
tanstack@2.0.7	7bb84e6ba893248814cd3bac70b7bdc115740fba9e13419940c73460cbcd7b6f

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.

The post Malicious Tanstack Package Uses Postinstall Script to Steal Developer Environment Files appeared first on Cyber Security News.