On May 11, 2026, several TanStack packages on npm were briefly replaced with malicious versions, raising fresh concerns about how attackers can use trusted open-source software to reach developer systems and corporate environments.

TanStack is a popular open-source toolkit used by software teams building modern web applications. npm is the package registry that many developers use to download and install reusable code. So when malicious versions appeared under the trusted @tanstack package namespace, the incident drew attention quickly across the developer and security community.

The exposure window was short. TanStack said the affected package versions were deprecated within the hour and later removed with help from npm. But the issue was still serious because the malicious packages were designed to steal credentials from the systems that installed them. That could include cloud keys, GitHub tokens, npm credentials, SSH keys, Kubernetes tokens, Vault tokens, and other sensitive access material.

What Happened?

According to TanStack’s postmortem, only the Router/Start repository was affected. The compromise involved 42 monorepo packages, with two malicious versions each. TanStack said its other repositories and packages, including Query, Table, Form, Store, DB, AI, Devtools, and others, were not affected.

Security firm Snyk reported that 84 malicious npm package artifacts were published across 42 @tanstack/* packages between 19:20 and 19:26 UTC on May 11. The company said the packages were published through TanStack’s legitimate release pipeline after attacker-controlled code hijacked the runner during the workflow.

What Is a Software Supply Chain Attack?

A software supply chain attack happens when attackers target the tools, packages, vendors, or automated systems that organizations rely on to build and run software. In the software development space, developers often use trusted building blocks from open-source projects, cloud services, code libraries, and third-party tools.

That is normal and also efficient.

But if one of those building blocks is tampered with, the impact can travel downstream. A company may be affected not because an attacker broke directly into its systems, but because it installed software from a trusted source that had been compromised.

What Did the Malicious Packages Try to Do?

The malicious versions were designed to run during normal installation. In other words, a developer or build system could trigger the malicious code simply by installing the affected package during the compromise window.

Once running, the malware looked for credentials. These credentials are the digital keys that allow systems to access other systems. In business terms, they can open doors to cloud accounts, code repositories, deployment tools, and internal services.

This is why “removing the infection” is not enough. If the malicious code has already run on a computer or system, it may have already collected secrets before the package was removed.

Was TanStack the Only Organization Affected?

No. The TanStack compromise appears to have been part of a broader campaign known as Mini Shai-Hulud. Snyk reported that the malicious versions spread to Mistral AI, UiPath, and other maintainers within hours. Other security reports have described a wider campaign affecting more than 160 npm and PyPI packages.

OpenAI also disclosed that two employee devices in its corporate environment were affected through the TanStack supply chain attack. OpenAI said it found no evidence that user data was accessed, production systems were compromised, intellectual property was compromised, or its software was altered. The company said it isolated affected systems, revoked sessions, rotated credentials, restricted some deployment workflows, and reviewed related activity.

What Teams Should Do Now

Organizations that may have installed affected TanStack versions should review package lockfiles, build logs, CI/CD activity, and developer machines from the May 11 compromise window.

The practical response should include checking whether affected versions were installed, identifying where they ran, isolating suspicious systems, rotating exposed credentials, and reviewing CI/CD permissions. Teams should also look closely at whether build systems have access to more secrets than they need.

The post The TanStack Breach and the Fragility of Trusted Code appeared first on Centraleyes.

*** This is a Security Bloggers Network syndicated blog from Centraleyes authored by Rebecca Kappel. Read the original post at: https://www.centraleyes.com/the-tanstack-breach-and-the-fragility-of-trusted-code/