Mini Shai-Hulud: The Supply Chain Worm That Turned Trusted Publishing Against Its Owners
- Joseph Assaf Turner
- May 15
- 11 min read
Executive Summary
Mini Shai-Hulud was not just another malicious package incident. It was a software supply chain attack against the trust machinery behind modern development: package registries, GitHub Actions workflows, CI/CD runners, trusted publishing, developer workstations and signing material.
On 11 May 2026, attackers compromised TanStack’s npm release path and published 84 malicious versions across 42 @tanstack/* packages between 19:20 and 19:26 UTC. According to TanStack, the attack chained three weaknesses: a risky pull_request_target GitHub Actions pattern, cache poisoning across the fork-to-base repository trust boundary and runtime extraction of an OIDC token from GitHub Actions runner memory. TanStack says no npm tokens were stolen and the npm publish workflow itself was not directly compromised. (TanStack)
OpenAI later confirmed that two employee devices in its corporate environment were impacted by the broader Mini Shai-Hulud / TanStack supply chain attack. OpenAI says it found no evidence that user data was accessed, that production systems or intellectual property were compromised, or that its software was altered. OpenAI also said the impacted repositories included signing certificates for its products and that it is rotating code-signing certificates as a precaution. (OpenAI)
The management lesson is direct:
The attacker did not need to compromise production first.The attacker compromised the process that production trusts.
This incident should be treated as a warning about CI/CD governance, not only open-source dependency hygiene. The question is no longer only “Which packages do we use?” The better question is: which identities, workflows and machines are trusted to build, sign, publish and deploy software?
What Leaders Need to Know
Mini Shai-Hulud is a self-propagating software supply chain malware campaign targeting package ecosystems such as npm and PyPI. Its purpose is to steal credentials from developer machines and CI/CD environments, then use package-publishing authority to spread into additional trusted packages. Aikido reported that its malware team detected 373 malicious package-version entries across 169 npm package names, with the basic goal of stealing credentials from developer machines and CI/CD runners, then using those credentials to reach more packages. (Aikido)
The incident matters because it struck at several layers of trust at once:
The strategic lesson is uncomfortable but useful: valid publishing infrastructure does not guarantee clean software if the workflow that produced it was compromised.
How the Attack Worked
The TanStack compromise began with a GitHub Actions workflow design weakness. TanStack’s postmortem describes a pull_request_target workflow that checked out fork-controlled code and ran build logic. This created the “Pwn Request” pattern: code from an untrusted pull request influenced a workflow running in a more privileged base-repository context. (TanStack)
The attacker used that opening to poison the GitHub Actions cache. TanStack explains that the malicious script wrote data into the pnpm store under a cache key that the legitimate release workflow would later compute and restore. When the release workflow ran on main, it restored the poisoned cache as designed. (TanStack)
The final step was OIDC token extraction. TanStack says the release workflow legitimately declared id-token: write for npm trusted publishing. Once the poisoned cache restored attacker-controlled code onto the runner, that code located the GitHub Actions runner process, read memory from /proc, extracted the OIDC token and used it to authenticate directly to the npm registry. This bypassed the workflow’s defined publish step. (TanStack)
That is why this incident is more serious than a stolen npm token. The attacker abused the release identity from inside the trusted workflow runtime.
Key Timeline
TanStack’s postmortem states that the malicious versions were detected publicly within about 20 minutes by the external researcher and that all affected versions were deprecated. (TanStack)
The Payload: Install-Time Execution, Credential Theft and Propagation
The malicious package versions contained payload behavior designed for developer and CI/CD environments.
Aikido reports that the malware searched for:
GitHub tokens
npm tokens
GitHub Actions OIDC tokens
AWS credentials and instance metadata
Kubernetes service account files
HashiCorp Vault tokens and local Vault endpoints
environment variables
local filesystem secrets
Aikido also states that the payload contained propagation logic: after stealing tokens, it attempted to find packages the victim could publish, modify package archives, inject the malicious dependency, bump versions and publish new compromised releases. (Aikido)
Socket described router_init.js as a self-contained supply chain worm targeting GitHub Actions, AWS, HashiCorp Vault and Kubernetes, with a propagation mechanism that steals an npm OIDC token from GitHub Actions CI environments and republishes itself under compromised maintainer identities. (Socket)
This is the technical core of Mini Shai-Hulud: the package was not only designed to steal secrets from the current victim. It was designed to turn the victim’s own release authority into the next infection path.
Why Trusted Publishing and Provenance Were Not Enough
Trusted publishing and provenance remain important security controls. They reduce some risks, especially risks linked to long-lived static package tokens. But Mini Shai-Hulud exposed a dangerous assumption: provenance can identify a workflow path, but it cannot prove that the workflow runtime was clean.
Socket specifically warns not to rely on Sigstore provenance badges alone, because an attacker who can execute inside GitHub Actions can generate valid Sigstore attestations for malicious packages. (Socket)
A precise way to state the lesson:
Provenance can show where a package came from.It cannot prove that the build environment was not poisoned.
That distinction matters for boards, CISOs and engineering leaders. A package can look legitimate because it came through the expected automation, while the automation itself has been abused.
What Was Impacted
TanStack confirmed 42 affected packages and 84 malicious versions, with two malicious versions per affected package. The confirmed-clean package families included @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store and the @tanstack/start meta-package, excluding @tanstack/start-* packages. (TanStack)
The broader campaign extended beyond TanStack. Aikido identified affected package groups across @squawk, @tanstack, @uipath, @tallyui, @beproduct, @mistralai, @draftlab, @draftauth, @taskflow-corp, @tolka and unscoped packages. (Aikido)
Socket later reported additional compromised artifacts affecting OpenSearch, PyPI mistralai, PyPI guardrails-ai and additional @squawk/* npm artifacts. Socket specifically listed @opensearch-project/opensearch npm versions 3.5.3, 3.6.2, 3.7.0 and 3.8.0, PyPI mistralai@2.4.6 and PyPI guardrails-ai@0.10.1. (Socket)
The practical impact varied by where the malicious package ran:
Install location | Likely risk |
Developer workstation | Local credentials, GitHub tokens, npm tokens, SSH keys, persistence in developer tooling |
CI runner | CI secrets, GitHub Actions OIDC tokens, cloud credentials, package-publishing rights |
Release workflow | Unauthorized package publication and downstream propagation |
Container build | Compromised build layer, embedded secrets, later deployment exposure |
Cloud-connected build system | AWS, Kubernetes, Vault and deployment credential exposure |
The package was the entry point. The real blast radius depended on the secrets and authorities available at install time.
OpenAI’s Confirmed Exposure
OpenAI confirmed impact from the TanStack npm supply chain attack and said the incident was part of the broader Mini Shai-Hulud campaign. OpenAI says it found no evidence that OpenAI user data was accessed, that production systems or intellectual property were compromised, or that its software was altered. (OpenAI)
OpenAI also said the impacted repositories included signing certificates for its products, including iOS, macOS and Windows. As a result, OpenAI is rotating code-signing certificates as a precaution. It also said it found no evidence that malicious software was signed with OpenAI certificates. (OpenAI)
For customers, the immediate OpenAI action is specific: macOS users must update OpenAI applications by 12 June 2026. Once OpenAI fully revokes the previous certificate on that date, new downloads and launches of apps signed with the previous certificate will be blocked by macOS security protections. (OpenAI)
OpenAI also states that customer passwords and API keys were not affected. (OpenAI)
This does not make the incident insignificant. It makes the impact bounded, based on OpenAI’s current public statement.
What Suppliers Should Do
Software suppliers, package maintainers and technology vendors should treat Mini Shai-Hulud as a release-engineering control failure pattern.
Control area | Required action |
GitHub Actions trust boundaries | Remove unsafe pull_request_target patterns that execute fork-controlled code in privileged contexts |
CI cache security | Prevent untrusted PR workflows from saving caches that trusted release workflows later restore |
OIDC permissions | Set id-token: none by default and allow id-token: write only in isolated publish jobs |
Build identity | Separate build, test, sign and publish identities |
Action dependencies | Pin third-party GitHub Actions to commit SHAs |
Publishing monitoring | Alert on unexpected package versions, dist-tag changes, publish events after failed CI and unusual workflow IDs |
Package validation | Validate lifecycle scripts, Git dependencies, optional dependencies, tarball contents and source-to-package reproducibility |
Emergency response | Maintain playbooks for package deprecation, registry escalation, credential rotation and customer notification |
TanStack’s own postmortem notes that detection was external and that no internal alerting caught the compromise. TanStack identified the need for monitoring on its own package publishes. (TanStack)
That is a key supplier lesson. Package publishing should be monitored as a security-sensitive production event, not as an engineering side effect.
What Customers Should Do
Customers should focus on exposure identification, containment, credential rotation and forensic review.
TanStack’s GitHub Security Advisory states that any developer or CI environment that ran npm install, pnpm install or yarn install against an affected version on 11 May 2026 should be considered compromised. It also recommends immediate rotation of all credentials accessible to the install process and review of cloud audit logs for activity from affected hosts. (GitHub)
Step | Action |
1 | Search lockfiles, SBOMs, package caches, CI workspaces and artifact repositories for affected packages and versions |
2 | Identify where affected versions were installed: developer laptop, CI runner, release workflow, container build or deployment environment |
3 | Isolate exposed systems where feasible |
4 | Rotate credentials reachable from exposed install hosts |
5 | Review GitHub commits, npm/PyPI publishing logs, cloud audit logs and CI workflow logs |
6 | Inspect .claude/ and .vscode/ directories for persistence artifacts |
7 | Block or monitor Session infrastructure where not business-required |
8 | Rebuild affected workspaces and containers from clean state |
Credential rotation should include:
npm tokens
GitHub PATs
GitHub Actions secrets
GitHub OIDC trust relationships
AWS credentials and role sessions
Kubernetes service account tokens
HashiCorp Vault tokens
SSH private keys
deployment credentials
signing material where exposed
The priority is not only to remove the malicious package. The priority is to understand what the package could access when it executed.
Indicators to Hunt
The following indicators should be reviewed in package manifests, lockfiles, developer machines, CI logs, repositories and egress telemetry.
Indicator | Meaning |
router_init.js | Main obfuscated payload |
router_runtime.js | Persistence-related payload copy |
tanstack_runner.js | Git dependency execution payload |
@tanstack/setup | Malicious or fictitious dependency marker |
github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c | Malicious Git dependency reference |
bun run tanstack_runner.js | Lifecycle execution marker |
.claude/ | Possible persistence path |
.vscode/tasks.json | Possible persistence path |
Suspicious commit author requiring review | |
filev2.getsession[.]org | Exfiltration path |
169.254.169.254 | AWS EC2 metadata target |
169.254.170.2 | AWS ECS task metadata target |
vault.svc.cluster.local:8200 | In-cluster Vault endpoint |
npm token validation endpoint |
Aikido lists the malicious dependency reference, prepare script and key network / service indicators, including filev2.getsession.org, AWS metadata endpoints, npm token validation and Vault service endpoints. (Aikido)
What Is Confirmed and What Remains Uncertain
Confirmed
TanStack confirmed 84 malicious versions across 42 @tanstack/* packages.
The TanStack attack chained pull_request_target, GitHub Actions cache poisoning and OIDC token extraction from runner memory.
OpenAI confirmed impact from the TanStack npm supply chain attack.
OpenAI says it found no evidence that user data, production systems, intellectual property or software were compromised.
Aikido and Socket tracked broader campaign activity across npm and PyPI.
Socket reported additional compromised artifacts involving OpenSearch, PyPI mistralai, PyPI guardrails-ai and additional Squawk packages.
Interpretation
This is best understood as a CI/CD identity and release-trust compromise, not merely a malicious package upload.
Trusted publishing reduces static-token risk, but it does not prevent abuse if attacker-controlled code executes inside the trusted workflow.
Developer endpoints and CI runners should be treated as part of the production trust chain.
Caution on attribution
Socket reported infrastructure and artifacts suggesting a link to TeamPCP, including attacker-controlled messaging signed “With Love TeamPCP.” OpenAI’s public statement does not attribute the incident to TeamPCP. The careful formulation is therefore: Socket linked campaign artifacts to TeamPCP; OpenAI confirmed impact from the TanStack / Mini Shai-Hulud supply chain attack but did not publicly attribute the actor. (Socket)
Lessons Learned
CI/CD is production-critical infrastructure
The attack path ran through GitHub Actions, npm publishing, package installation, developer machines and CI runners. These systems are not secondary engineering utilities. They are part of the production control plane.
Security governance should treat CI/CD environments as high-value assets with privileged identity, change authority and access to sensitive secrets.
Trusted publishing does not mean trusted runtime
OIDC trusted publishing reduces the risk of long-lived npm token theft. That remains valuable. But if attacker-controlled code executes inside a workflow that can mint an OIDC token, the attacker may still publish through the trusted path.
The control objective is not only “avoid static tokens.” It is prevent untrusted code from reaching publishing authority.
Provenance is evidence, not proof
A provenance badge can help show which workflow produced a package. It does not prove the workflow was clean, that its cache was safe or that no attacker-controlled code executed during the run.
Organizations should validate both provenance and package content.
Install-time execution remains dangerous
Package lifecycle scripts, Git dependencies and optional dependencies can turn dependency installation into arbitrary code execution. In this incident, normal package-manager behavior became the execution path.
CI environments should minimize install-time script execution where possible and monitor it where it remains necessary.
Developer workstations are part of the supply chain
OpenAI’s disclosure shows how an upstream package compromise can reach corporate developer devices and internal repositories. OpenAI says the impact was limited and found no evidence of customer data exposure, but the path itself matters. Developer devices may hold source-code access, local credentials, AI-tool hooks, signing material and deployment context. (OpenAI)
Customers need dependency incident response, not only vulnerability management
A CVE-style patch workflow is too narrow for package-worm incidents.
Customers need to answer quickly:
Did we install the affected version?
Where did it execute?
What credentials were available there?
Did it persist?
Did it publish anything?
Did it modify repositories?
Did it access cloud, Vault, Kubernetes or deployment systems?
That is incident response, not routine patching.
Suppliers need release observability
TanStack’s postmortem notes that detection was external. Suppliers should monitor their own package publications, release workflow behavior, dist-tag changes, tarball contents and provenance anomalies. Waiting for an external researcher to notice a malicious release is not a control. It is luck with a GitHub issue number. (TanStack)
FAQ
What is Mini Shai-Hulud?
Mini Shai-Hulud is a self-propagating software supply chain malware campaign targeting package ecosystems such as npm and PyPI. It focuses on stealing developer and CI/CD credentials, then abusing package-publishing authority to spread into additional trusted packages.
Was OpenAI breached in the Mini Shai-Hulud campaign?
OpenAI confirmed impact from the TanStack npm supply chain attack and said two employee devices lacked updated configurations that would have prevented downloading the newly observed malicious package. OpenAI says it found no evidence that user data, production systems, intellectual property or software were compromised. (OpenAI)
How did the TanStack compromise work?
The TanStack compromise chained a risky GitHub Actions pull_request_target pattern, GitHub Actions cache poisoning and OIDC token extraction from runner memory. That allowed malicious packages to be published through a trusted npm publishing path. (TanStack)
What should customers do first?
Customers should identify whether affected packages were installed, determine where installation occurred, isolate affected developer or CI systems where feasible, rotate all reachable credentials and audit package-publishing logs, GitHub commits, cloud audit logs and CI workflow activity.
Why is provenance not enough?
Provenance can show that a package came from a specific workflow, but it cannot prove that the workflow runtime was clean. Socket warns that an attacker executing inside GitHub Actions can generate valid Sigstore attestations for malicious packages. (Socket)
What is the board-level lesson?
The board-level lesson is that software supply chain risk is no longer limited to third-party code selection. It now includes the integrity of build systems, identity federation, signing material, publishing workflows, developer endpoints and CI/CD secrets.
Conclusion
Mini Shai-Hulud is a warning about misplaced trust in software delivery automation.
The campaign did not rely only on tricking developers into installing a malicious package. It abused CI/CD workflows, poisoned build caches, extracted OIDC tokens, published through trusted package infrastructure and attempted to turn victim publishing rights into the next infection path.
OpenAI’s confirmed exposure shows why this matters even to mature technology companies. OpenAI reports no evidence of customer data exposure and no evidence that its products were compromised, which is important. But the incident still highlights a broader control problem: modern organizations depend on shared software ecosystems, package managers, CI/CD workflows and developer tooling that can propagate compromise quickly. (OpenAI)
The right lesson is not “avoid open source.” That is neither practical nor serious.
The lesson is this:
Software supply chain security is not only about what code you import.It is about who can publish it, which workflow can sign it, which runner can build it, which identity can deploy it and which secrets are exposed when installation becomes execution.
That is where the real control conversation begins.
Comments