Fake TanStack npm package stole developer .env files through postinstall script

A malicious npm package named tanstack was used to steal developer environment files by impersonating the real TanStack ecosystem. The attack hit the unscoped tanstack package, not the legitimate @tanstack packages used by developers.

The malicious versions were published on April 29, 2026, and stayed active during a short 27-minute window. Versions 2.0.4, 2.0.5, 2.0.6, and 2.0.7 all included postinstall behavior that could run automatically during npm installation.

The risk is serious because .env files often store cloud keys, database passwords, GitHub tokens, npm publish tokens, API keys, OAuth secrets, and production credentials. If a developer or CI job installed the affected package, those secrets should be treated as compromised.

What happened

The attacker registered the unscoped tanstack package name and presented it as a video player SDK called TanStack Player. The package used a polished README, badges, code examples, and comparison tables to look legitimate during a quick review.

The real TanStack project, which publishes official packages under the @tanstack scope, had no connection to this package. Official packages include tools such as TanStack Query, TanStack Router, and TanStack Table.

A developer who typed npm install tanstack instead of installing an official scoped package could receive the malicious package. Once installed, the postinstall script could read local environment files and send their contents to an attacker-controlled endpoint.

At a glance

Item	Details
Package name	tanstack
Ecosystem	npm
Attack type	Brand-squatting and postinstall credential theft
Malicious versions	2.0.4, 2.0.5, 2.0.6, 2.0.7
Published window	April 29, 2026, from 17:08 to 17:35 UTC
Main target	.env files and related developer secrets
Exfiltration service	Svix webhook infrastructure
Legitimate project affected	No direct compromise of the official @tanstack packages

How the postinstall attack worked

The malicious code ran through npm’s postinstall lifecycle script. This matters because postinstall scripts can execute automatically after a package is installed, before a developer imports or uses the package in application code.

The payload looked for sensitive files in the install environment, then sent the contents as JSON to an attacker-controlled Svix ingest endpoint. Svix is a legitimate webhook platform, which made the traffic less obvious than a direct connection to a suspicious server.

The exfiltrated payload also included metadata such as Node.js version, operating system platform, CPU architecture, package name, version, and timestamp. That information could help attackers decide which stolen secrets were most useful.

Why version 2.0.6 was the most dangerous

The attacker changed the payload several times during the 27-minute window. That pattern suggests live testing and quick adjustment while the package remained publicly installable.

Version 2.0.4 targeted .env and .env.local. Version 2.0.5 temporarily switched to README.md and AGENTS.md, likely to test delivery or disguise activity. Version 2.0.6 expanded the attack by collecting every file named .env or starting with .env.

That made version 2.0.6 the most damaging release. It could collect .env.production, .env.staging, .env.development, .env.local, and other environment-specific files in one run.

Affected versions

Version	Behavior	Risk level
2.0.4	Targeted .env and .env.local files	High
2.0.5	Targeted README.md and AGENTS.md	Medium
2.0.6	Collected .env and all .env.* files	Critical
2.0.7	Returned to .env and .env.local targeting and referenced 2.0.6	High

What data may have been exposed

• AWS access keys and secret keys
• GitHub personal access tokens
• npm publish tokens
• Database usernames, passwords, and connection strings
• Stripe, Twilio, SendGrid, Resend, and similar API keys
• OpenAI, Anthropic, and other AI service keys
• OAuth client IDs and client secrets
• Production, staging, and development environment secrets

Why this attack matters

The attacker did not need to compromise the official TanStack maintainers. They did not need to break into GitHub, npm, or a CI provider. They only needed a convincing package name and a script that npm would run during installation.

That makes the incident a useful warning for JavaScript teams. Package names that look familiar can still be unrelated to the project developers expect.

The attack also shows why .env files are high-value targets. They often sit in project folders, and build tools can access them easily. If a malicious dependency runs during installation, it can read those files before the developer notices anything unusual.

How developers can check for exposure

Developers should inspect lock files and node_modules folders for tanstack versions 2.0.4 through 2.0.7. This check should cover local machines, CI runners, build containers, and any shared development environments.

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

If any affected version appears, treat every .env file present during installation as exposed. Teams should also review CI job logs because postinstall scripts can run during npm install and npm ci.

What to rotate first

• Rotate AWS keys and review CloudTrail for unusual API calls.
• Revoke and recreate GitHub personal access tokens.
• Revoke npm tokens and issue new tokens with limited scope.
• Change database passwords stored in affected .env files.
• Rotate third-party API keys used by payments, email, SMS, AI, and analytics services.
• Replace OAuth client secrets exposed in local or CI environment files.
• Invalidate any production secrets found in .env.production or similar files.

What CI teams should do

CI environments need special attention because they often inject secrets during the build process. If the malicious package ran inside a CI job, secrets may have been present even when no .env file existed in the repository.

Security teams should review install logs around April 29, 2026, especially jobs that ran npm install, npm ci, yarn install, or pnpm install with the tanstack package in scope.

They should also inspect outbound HTTPS logs for traffic to api.svix.com during the install window. A connection does not prove that secrets were stolen by itself, but it can help confirm whether the payload reached its relay endpoint.

How to reduce this risk in the future

• Install official TanStack packages only from the @tanstack scope.
• Block or review dependencies with unexpected postinstall scripts.
• Pin dependencies and review lock-file changes before merging.
• Use package allowlists for production and CI environments.
• Run installs with reduced privileges where possible.
• Keep production secrets out of local developer .env files.
• Use short-lived credentials in CI instead of long-lived static tokens.
• Monitor for network calls during package installation.

What this means for software supply chain security

The fake tanstack package shows how brand-squatting can become a real credential theft incident. A package can look polished, stay clean for a while, then turn malicious in one update.

The 27-minute publishing window also shows how quickly attackers can test and refine payloads. Short-lived malicious versions can still affect developers and CI jobs if installs happen at the wrong time.

For organizations, the lesson is straightforward. Dependency trust should depend on package identity, maintainer history, install-time behavior, and secret exposure controls, not only on a familiar-looking name.

FAQ1