TanStack is the latest in a long pattern of software supply chain attacks. Most SMEs don’t write code, but the SaaS they pay for, the websites their agency builds, and the browser extensions their team installs all do. The four places to look first, and why doing nothing is no longer a defensible posture.
What just happened
In the second week of May 2026, a maintainer’s compromised npm token was used to publish malicious versions of several @tanstack packages. TanStack is one of those names most non-developers have never heard of. Its tools, including the data-fetching library TanStack Query, sit deep inside a long list of business software: customer-facing web apps, internal dashboards, admin tools, e-commerce front-ends. The malicious versions stayed in the npm registry for a number of hours before being pulled. In that window, anything that ran npm install against the affected packages pulled in the bad code. Build pipelines pushed it into production. Browser bundles served it to end users.
It was a small attack by tech-press standards; the wider pattern is what matters.
In late 2025 a worm dubbed “Shai-Hulud” propagated through npm, compromising hundreds of packages by stealing maintainer credentials and using them to publish poisoned updates. Earlier, the polyfill.io domain was sold to a new owner who promptly modified it to serve malware to every site that embedded its script, and many sites did, because polyfill.io had been a Stack Overflow-recommended way to support older browsers. Going back further, the ua-parser-js compromise in 2021 reached an estimated seven million weekly downloads before being caught. The names change, but the shape is the same. A trusted upstream (a package, a library, a CDN, a browser extension) becomes the delivery mechanism for an attacker who can’t reach the target directly. The defenders are doing nothing wrong by their own previous standards. The trust model itself has been weaponised.
“But we don’t write code”
The instinct for most SME owners reading this is reasonable: we don’t ship software, we don’t run npm, this isn’t our problem. The instinct is wrong, in three concrete ways.
First, the line-of-business SaaS you pay for is built on npm. When the project-management tool your team uses lists fifteen integrations on its website, any one of those is the way TanStack-style code can land inside the tool. The vendor’s secure-development discipline becomes your secure-development discipline, whether you knew that or not. The 2026 cyber-insurance questionnaire is starting to ask SaaS suppliers about exactly this, with the expectation that you’ll be able to ask the same questions of yours.
Second, the website your agency built pulls third-party scripts on every page load. Analytics tags, chat widgets, marketing-automation pixels, payment SDKs, recommendation engines, the cookie banner itself. Every one of these is JavaScript that runs in your visitor’s browser with the same access to your visitor’s data that your own site has. A compromised polyfill is a compromised checkout form.
Third, browser extensions auto-update across your fleet without anyone noticing. The PDF-editor extension a member of your finance team installed two years ago is on its forty-third version by now. If the developer has been bought out, breached, or simply changed direction, the extension can read every page your team views, including the Workspace tab they have open right now.
The exposure isn’t “you might get hacked by a developer”. The exposure is that the software you’ve trusted, by paying for it, embedding it, or installing it, is now the attack surface, and you have no direct relationship with the malicious party.
Four places to look first
There are four practical places to do this work, and most SMEs have done none of them.
1. Browser extensions across the org. Both Google Workspace and Microsoft Intune let an admin force an allowlist of approved extensions and block everything else. Most SMEs have neither configured. The starting work: enumerate what’s actually installed across your fleet (both admin consoles expose this), trim aggressively, lock the remainder. Treat new extension requests the same way you treat new SaaS requests: a small ticketed review, not a free choice. The founders have shipped this configuration at every IT-leadership posting we’ve held; the friction is one team conversation followed by a quiet estate.
2. SaaS OAuth scopes and audit logs. Every SaaS your team has connected to Workspace or Microsoft 365 has a set of scopes it can use: read calendar, send email, access Drive, modify files. Most SMEs granted these scopes once at sign-up and have never reviewed them since. Open the OAuth-applications list in Workspace or Entra, review what’s connected, revoke what’s no longer in use, and tighten anything with scopes wider than the job it does. Pair this with a quarterly review of the SaaS vendor list itself: what they hold, where they hold it, what their last security incident was.
3. Internal or agency-built apps: SBOM, version pinning, dependency scanning. This is the area most relevant to anyone running custom development work. SBOM (Software Bill of Materials, a structured list of every dependency a piece of software pulls in) is mandated under the EU Cyber Resilience Act, and increasingly expected under NIS2 supply-chain obligations, for anything sold or operated in the EU. For the apps your business runs or commissions: ask your developer or agency for an SBOM, for evidence of version pinning (specific versions in lockfiles, not floating ranges that resolve to whatever-is-latest at install time), and for dependency scanning in their build pipeline. If they can’t produce these, that’s the start of the conversation about their security posture, not the end of it.
4. Outbound DNS and network monitoring, the post-compromise tripwire. Supply chain attacks are designed to evade the perimeter, so the first signal that something has gone wrong is almost always traffic going somewhere it shouldn’t: a script calling home to a server you didn’t authorise, a laptop sending data to an attacker-controlled endpoint, a server beaconing on an hour-by-hour cycle. DNS-level filtering (Cisco Umbrella, NextDNS, Cloudflare Gateway) blocks known malicious destinations at the network layer and logs the rest. Add it to the SME tech stack, and review the alerts.
The honest take
You will not prevent every supply chain attack. The TanStack window was hours, and any team running automated builds during it ingested the bad code regardless of how careful their dependency hygiene was on every other day of the year. What changes between the SME that handles this well and the one that doesn’t is two things: how much blast radius the attack has when it lands, and how quickly anyone notices.
Blast radius shrinks with the inventory work. An attack that hits your project-management SaaS is a problem. An attack that has OAuth access to your entire Drive estate is a crisis. A compromised browser extension on one user’s laptop is recoverable; the same extension running across thirty users for six months is not.
Detection speed shrinks with the monitoring work. An SME that has DNS logs and reviews them weekly notices an anomaly in days. An SME that has neither notices it when a customer phones to ask why their card was charged twice.
Where this lands for the next ninety days
A reasonable first-ninety-days plan, drawing on the conversations we’ve been having with SME clients this month:
- Days 1-30. Inventory extensions across Workspace or Intune. Force an allowlist, block everything else. Open the OAuth list, revoke the obvious dead apps, document what survives.
- Days 30-60. Ask the SBOM question of any agency or in-house developer. Get version-pinning and scanning answers in writing. Add the question to the next supplier onboarding form.
- Days 60-90. Pilot DNS-level filtering on one office or one user group. Review the first month of alerts. Make a decision on rolling it across the estate.
None of this prevents the next TanStack, but all of it shrinks the day-after fallout.
If you’d like help working through any of it, that’s our Security Solutions practice. We’ll either run it for you or sit alongside whoever does. Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.