Last updated: June 15
# How we responded to an npm supply-chain attack
#### Kevin van Zonneveld
Co-founder · Amsterdam, The Netherlands · Show bio
[](https://x.com/kvz)[](https://github.com/kvz)
On May 12, 2026, we reviewed our exposure to the ongoing Mini Shai-Hulud supply-chain campaign, after public reports described compromised packages in the npm and PyPI ecosystems. These included TanStack packages and `intercom-client`.
We found no evidence that Transloadit's production systems, customer data, or published packages were affected. We did, however, use the incident as a forcing function to tighten dependency installs and GitHub Actions release paths across our repositories.
## What happened
The short version is that attackers are no longer relying only on stolen package manager tokens or typosquatted package names. In the TanStack incident, the maintainers'[postmortem](https://tanstack.com/blog/npm-supply-chain-compromise-postmortem) describes a chain that combined a `pull_request_target` workflow, GitHub Actions cache poisoning, and trusted publishing/OIDC token access. As a result, malicious packages were allowed to be published through official release infrastructure.
Socket's [Mini Shai-Hulud tracker](https://socket.dev/supply-chain-attacks/mini-shai-hulud) also links the campaign to compromised packages, such as `intercom-client@7.0.4` on npm and `lightning`2.6.2/2.6.3 on PyPI. The reported payloads target developer and CI environments, looking for credentials such as GitHub tokens, npm tokens, cloud keys, SSH keys, and AI-tool configuration.
This matters because CI systems often sit close to source code, deployment credentials, package publishing permissions, and cloud infrastructure. A malicious dependency install in the wrong place can become much more than a local development problem.
## Impact to Transloadit
We found no evidence of impact to Transloadit services or customer data.
Our review included:
* Checking repositories that use `intercom-client`. We found these in the Website repo, API, and other internal repositories. However, each of these was pinned and resolved to`intercom-client@5.0.0`, not the reported malicious 7.0.4 or 7.0.5 versions.
* Checking for known suspicious files and indicators from the campaign, including `router_init.js`,`router_runtime.js`, `execution.js`, suspicious `shai-hulud` workflow files, and the reported TanStack malicious git reference.
* Checking for the reported GitHub token monitor persistence mechanism on developer machines used in this review.
* Reviewing our GitHub Actions workflows for the specific risky pattern highlighted by the TanStack postmortem: untrusted pull request code crossing into a trusted cache or release workflow.
The affected package versions we checked were not present in the reviewed lockfiles or installed copies. We also did not find the known persistence or payload indicators in the reviewed working trees.
## What we changed
We opened and updated a set of hardening pull requests across our repositories. These changes are small on purpose: they reduce supply-chain exposure, without changing product behavior.
The main changes are:
* **Dependency age gates.** For Yarn repositories that did not already have one, we added`npmMinimalAgeGate: 2880`, which prevents newly published package versions from being installed for 48 hours. This gives the ecosystem time to detect and remove many compromised releases before they can enter our builds.
* **Immutable installs.** We changed eligible CI installs to use immutable or frozen lockfile behavior, so CI does not opportunistically resolve new dependency versions.
* **Release cache boundaries.** We removed shared dependency cache restore from release or publish-capable paths where it could bridge trust boundaries. In particular, we updated release or CDN upload paths in `monolib`, `locutus`, and `uppy`.
* **Public-repo CI review.** We reviewed public repositories for `pull_request_target` and secret-bearing workflows. Where public repos need secrets for CI, our preferred pattern is environment-protected approval tied to the specific code being tested, rather than a label-only "safe to test" flow.
* **Verified, append-only Git history.** We enabled organization-wide GitHub rules that require verified commits and block force-pushes across Transloadit repositories. Follow-up investigation reinforced that non-default branches and stale refs are part of the attack surface: if an attacker can rewrite a shared branch with forged author metadata, the malicious history can look more familiar than it is.
## Why this helps
No single setting prevents all supply-chain attacks. The goal is layered friction:
* A package age gate reduces the chance that we install a freshly compromised version during the first few hours of an attack.
* Immutable installs make CI and deploys reproduce the reviewed lockfile instead of discovering new versions during the run.
* Avoiding shared caches in release paths reduces the chance that untrusted or lower-trust jobs can leave behind artifacts that a later trusted publish job will restore.
* Explicit GitHub Actions permissions and environment approvals keep secret-bearing jobs from running against unreviewed fork code.
* Verified commits make impersonation harder, and blocking non-fast-forward updates preserves the reviewable history of shared branches.
The TanStack incident was a useful reminder that build caches and release jobs are part of the security boundary. We are now more consistent in treating them as such.
## What customers should do
There is no Transloadit-specific customer action required from this review.
If you installed any packages publicly listed as affected by Mini Shai-Hulud on or after April 29, 2026, we recommend following the relevant package maintainer guidance. In general, that means checking lockfiles and CI logs, removing affected versions, and rotating any credentials that were reachable from environments in which the malicious packages may have run.
For your own CI systems, we recommend the same controls we are applying:
* Use lockfile-only installs in CI and deployment workflows.
* Add dependency release-age gates where your package manager supports them.
* Avoid dependency caches in publish or deployment workflows.
* Be very careful with `pull_request_target`; do not combine it with checking out untrusted PR code and access to secrets or write tokens.
* Keep GitHub Actions permissions as small as possible, and elevate only in the job that needs the permission.
* Disable force-pushes on shared repository branches where possible. If developers need to rework history, prefer new branches over rewriting branches that other people or automation may pull.
## Closing
We are grateful to the maintainers and researchers who moved quickly to publish technical details and indicators. This made it possible for teams like ours to check exposure quickly and turn the lessons into concrete hardening work.
We will continue monitoring the campaign and will update this post if we find any material impact to Transloadit or any required customer action.
[#security](/blog/tags/security.md)[#supply-chain](/blog/tags/supply-chain.md)[#incident-response](/blog/tags/incident-response.md)[#open-source](/blog/tags/open-source.md)
### 👩💻 Join 20k+ developers
Sign up for our [monthly newsletter](/newsletters.md) to receive direct links to 3 exclusive tech — and 2 product updates. No less, no more.
Your email:
Get access
## File uploading and encoding. Made simple.
Transloadit streamlines file handling for developers, trusted by brands like Coursera and The New York Times. We’re known for a reliable API, top-notch support, and a strong commitment to open source, with projects like [Uppy](https://uppy.io) and [Tus](https://tus.io) setting standards in file processing.
[Sign up](/c/)[Book a Demo](https://survey.typeform.com/to/kRg47Xi5)
No credit card needed · 5 GB included in the free plan
Cancel anytime