Fake TanStack npm package caught stealing developer secrets through postinstall script

A malicious npm package named tanstack was used to steal developer secrets by impersonating the real TanStack project. Security researchers found that the unscoped package pushed several poisoned versions that searched for environment files during installation and sent them to an attacker-controlled endpoint.

The attack targeted developers who may have installed tanstack instead of legitimate scoped packages from the official @tanstack organization. That small naming difference matters because real TanStack packages use the @tanstack/* format, while the malicious package used the bare tanstack name.

Socket reported that versions 2.0.4 through 2.0.7 were malicious. Aikido said those four versions were published between 17:08 UTC and 17:35 UTC on April 29, 2026, giving developers only a narrow window to notice the behavior before the package changed again.

At a glance

Item	Details
Malicious package	tanstack
Platform	npm
Legitimate project	TanStack, published under @tanstack/* packages
Confirmed malicious versions	2.0.4, 2.0.5, 2.0.6, 2.0.7
Main technique	Postinstall script abuse
Targeted data	.env files, local secrets, project metadata, and selected project files
Exfiltration service	Svix webhook endpoint controlled by the attacker

Why this npm attack is serious

TanStack is a well-known open-source project behind popular JavaScript tools such as TanStack Query, TanStack Router, TanStack Table, and TanStack Form. Developers often search for these tools by name, which makes lookalike package names more dangerous.

The malicious package used brand-squatting rather than a complex technical exploit. It relied on developers, tutorials, or coding tools choosing the wrong package name. Once installed, the package could run code automatically through npm’s postinstall lifecycle hook.

That makes the incident especially risky for local development machines and CI/CD environments. Environment files often contain API keys, database passwords, cloud tokens, OAuth secrets, and credentials for production or staging systems.

How the malicious package worked

The attack used a postinstall script, which npm can execute automatically after a package installation. In this case, the script searched the installation directory for sensitive files and sent their contents outside the developer’s environment.

Socket said the package used an innocent-looking function name, sendReadme(), to hide its real purpose. Instead of only handling documentation, the code collected environment files and sent them in a JSON payload to a Svix ingest URL.

Aikido’s analysis found that version 2.0.6 was the most aggressive release. It scanned for .env and all .env.* variants, including common files such as .env.local, .env.production, .env.staging, and .env.development.

What attackers may have stolen

• API keys for cloud, payment, email, and AI services
• Database connection strings
• GitHub personal access tokens
• npm publish tokens
• OAuth client secrets
• Session secrets and signing keys
• Project configuration stored in local dotenv files

Developers should treat any exposed .env file as compromised if they installed tanstack versions 2.0.4 through 2.0.7. Removing the package alone does not protect leaked secrets because the attacker may already have received the data.

The safest response is immediate credential rotation. Teams should replace affected secrets, revoke old tokens, check access logs, and review downstream services for suspicious activity.

Why the package name created confusion

The legitimate TanStack ecosystem uses scoped npm packages. That means developers should install packages such as @tanstack/react-query, @tanstack/router, or other packages under the official @tanstack scope.

The malicious package used the simpler tanstack name. That name can look natural to developers who expect a package to match the project brand directly. It can also appear believable when copied from unofficial tutorials or generated by coding assistants.

A GitHub security discussion opened before this incident warned that bare TanStack-like package names could become baitsquatting targets. The risk comes from attackers registering intuitive unscoped names and waiting for developers or AI tools to recommend them.

Recommended actions for developers

• Search package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, and CI files for tanstack.
• Remove the unscoped tanstack package from all projects.
• Use official @tanstack/* packages only.
• Rotate every secret stored in .env files present during installation.
• Revoke npm tokens, GitHub tokens, cloud keys, database passwords, and API credentials if they may have leaked.
• Check developer machines and CI logs for outbound traffic to api.svix.com.
• Add the unscoped tanstack package to internal deny lists.
• Block unknown postinstall scripts in high-risk build environments where possible.

What teams should check after exposure

Security teams should review all systems that used the affected package during the publication window or after it became available. This includes local machines, build runners, test environments, containers, and any automated dependency update jobs.

They should also inspect repository history for committed .env files. Even when teams avoid committing secrets, local install commands can still expose private environment files because postinstall scripts run on the developer’s machine.

If npm publish tokens were stored locally, teams should verify that no unauthorized package versions were released. If cloud keys were exposed, teams should check usage logs for unusual API calls, new users, changed permissions, or unexpected infrastructure activity.

Indicators of compromise

Indicator	Value
Package	tanstack
Malicious versions	2.0.4, 2.0.5, 2.0.6, 2.0.7
npm maintainer name reported by researchers	sh20raj
Execution method	postinstall hook
Targeted files	.env, .env.local, .env.production, and other .env.* files
Svix source ID	src_3387PLMB2uhXOBe3Q8sHu
Network domain	api.svix.com

FAQ