Malicious TanStack Package Steals Dev Files via Postinstall Script

Key Takeaways

• A malicious npm package, “tanstack,” was discovered impersonating components of the legitimate TanStack project.
• The package contained a “postinstall” script designed to silently exfiltrate sensitive developer environment files upon installation.
• Four malicious versions (2.0.4, 2.0.5, 2.0.6, 2.0.7) were published on April 29, 2026, over a 27-minute period, with version 2.0.6 being the most dangerous.
• The attack leveraged typosquatting, targeting developers who might mistakenly install “tanstack” instead of scoped packages like “@tanstack/query.”
• Developers who installed any of the malicious versions must immediately rotate all potentially compromised credentials, including AWS keys, GitHub tokens, and API keys.

Malicious npm Package “tanstack” Steals Developer Credentials

On April 29, 2026, a deceptive npm package masquerading as a component of the popular TanStack ecosystem was identified, actively engaged in stealing critical developer environment files. This fraudulent package was designed to automatically exfiltrate sensitive data the moment it was installed onto a developer’s system.

The attacker registered the unscoped “tanstack” package name on npm, crafting it to appear as a legitimate “TanStackPlayer” video player SDK. Crucially, a credential-harvesting script was embedded within the package, configured to execute silently via a postinstall hook, ensuring no visible warnings during installation. Further details of the campaign and its impact were analyzed by Aikido researchers.

The Attack Window and Modus Operandi

The malicious activity unfolded rapidly over a mere 27-minute interval on April 29, 2026. Between 17:08 and 17:35 UTC, four distinct malicious versions of the package—2.0.4, 2.0.5, 2.0.6, and 2.0.7—were pushed to the npm registry in quick succession. Each of these versions included a “postinstall” hook, a mechanism that automatically triggers a script when a developer executes an npm install command.

Prior to this incident, version 2.0.3, released in March 2026, was clean and did not contain any such malicious hook. The package had garnered approximately 19,830 downloads in the month preceding the attack, creating a substantial pool of potential targets for the attacker.

The attackers did not need to compromise existing accounts or exploit vulnerabilities. Instead, they relied on a sophisticated form of typosquatting and social engineering. By registering a convincing package name and enhancing its README with sponsorship badges, download shields, feature comparison tables, and code examples, the package appeared legitimate enough to bypass casual scrutiny. This allowed the attacker to simply upload the malicious package, and npm’s installation process handled the rest.

The real TanStack organization, known for widely adopted libraries like TanStack Query (which sees around 8 million weekly downloads), had no association with this malicious package. The attacker capitalized on the fact that the unscoped “tanstack” name had been available since December 2024. This allowed them to exploit common developer typos; for instance, a developer inadvertently typing npm install tanstack instead of npm install @tanstack/query would unknowingly install the malicious package, instantly triggering credential theft.

Exfiltrated data was routed through Svix, a legitimate webhooks-as-a-service platform, to an attacker-controlled endpoint. This tactic allowed the attacker to bypass conventional network-level blocking mechanisms by leveraging a trusted third-party relay. The stolen payload included not only file contents but also system metadata such as Node.js version, platform, and architecture, providing attackers with immediately actionable information for subsequent targeted attacks.

Live Payload Iteration: Version 2.0.6’s Enhanced Threat

A notable aspect of this campaign was the attacker’s apparent real-time debugging and refinement of the payload across the four malicious versions:

• Version 2.0.4: Initially targeted .env and .env.local files. A planned opt-out check was commented out, leaving no escape for compromised developers.
• Version 2.0.5: Released just three minutes later, this version briefly shifted its focus to README.md and AGENTS.md, likely a test to confirm the webhook receiver’s functionality.
• Version 2.0.6: Published at 17:26 UTC, this iteration proved to be the most dangerous. It abandoned specific file targeting in favor of a comprehensive directory sweep. A collectEnvFiles() function was implemented to gather every file starting with .env, encompassing critical files like .env.local, .env.production, .env.staging, and .env.development, consolidating them into a single POST request. All console output was suppressed, rendering the attack invisible to the victim.
• Version 2.0.7: This final version reverted to targeting only .env and .env.local but notably included a self-referential dependency on version 2.0.6 within its package.json. This indicated the attacker was actively monitoring results and refining their payload in real-time while the package remained publicly available for installation.

The files typically targeted in such attacks often contain highly sensitive credentials, including 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. The exfiltration of any of these credentials can lead to severe consequences, such as full account takeover, extensive data breaches, or unauthorized consumption of cloud resources.

What You Should Do

Developers must act immediately to determine if they have been affected and to mitigate potential damage.

• Check Lock Files: Promptly examine your project’s lock files (package-lock.json, yarn.lock, pnpm-lock.yaml) for any installation of the unscoped “tanstack” package, specifically versions 2.0.4 through 2.0.7. Use the following command:

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

• Assume Compromise and Rotate Credentials: If any affected version is found, assume all environment files present during the installation were compromised. Immediately rotate the following credentials:
  • 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 (e.g., Stripe, OpenAI, Twilio).
• CI/CD Environment Check: For CI pipeline environments, the postinstall script also executes during npm ci. Review CI provider job logs for the installation step. Rotate all secrets injected into that pipeline’s environment during the period of compromise.
• Network Monitoring: Monitor outbound HTTPS traffic to api.svix.com in your network logs around the time of installation to help confirm whether data 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.