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, including 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 describes a chain that combined a pull_request_target workflow, GitHub Actions cache poisoning, and trusted publishing/OIDC token access. That allowed malicious packages to be published through official release infrastructure.

Socket's Mini Shai-Hulud tracker 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 it in the Website repo, API, and other internal repositories, but each 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.

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.

The TanStack incident was a useful reminder that build caches and release jobs are part of the security boundary. We now treat them that way more consistently.

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 where 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.

Closing

We are grateful to the maintainers and researchers who moved quickly to publish technical details and indicators. That 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.