Sophisticated 'Mini Shai-Hulud' Campaign Abuses GitHub Actions and SLSA Signing to Spread Malware
‘Mini Shai-Hulud’ Supply Chain Attack Hits 170+ Open-Source Packages via GitHub Actions
Full Report(when first published)
Executive Summary
A highly sophisticated software supply chain attack, named Mini Shai-Hulud, has been uncovered, impacting over 170 packages across the NPM and PyPI open-source ecosystems. The campaign, attributed to the TeamPCP threat group, successfully injected credential-stealing malware into the build processes of popular projects, including TanStack, Mistral AI, and UiPath. The attackers chained multiple advanced techniques, including the abuse of GitHub Actions CI/CD pipelines and cache poisoning. Most alarmingly, they were able to get their malicious packages signed with valid SLSA (Supply-chain Levels for Software Artifacts) provenance signatures by hijacking the legitimate build process. This attack represents a significant evolution in supply chain threats, undermining cryptographic trust mechanisms designed to prevent such attacks.
Threat Overview
- Threat Actor: TeamPCP, a group specializing in supply chain attacks.
- Campaign: Mini Shai-Hulud.
- Attack Vector: The core of the attack was the abuse of misconfigured GitHub Actions workflows, particularly those using the
pull_request_targettrigger, combined with cache poisoning across repository forks. - Impacted Ecosystems: NPM (JavaScript) and PyPI (Python).
- Malware Functionality: The primary goal was credential harvesting. The malware was designed to steal developer credentials, API keys (Stripe), cloud secrets (AWS), cryptocurrency wallets, and AI tool credentials. It also had self-propagation capabilities, using stolen tokens to spread to other packages.
Technical Analysis
The attack chain was complex and demonstrates a deep understanding of modern CI/CD security weaknesses:
- Initial Foothold: The attackers identified open-source projects with vulnerable GitHub Actions workflows. Specifically, they targeted workflows that use the
pull_request_targetevent, which runs with access to the base repository's secrets, even for pull requests from forks. - Code Injection via Cache Poisoning: They combined the
pull_request_targetabuse with cache poisoning (T1574.013 - Ptrace System Calls- conceptually similar cache abuse). By manipulating the build cache in their forked repository's pull request, they could inject malicious commands and code that would be executed by the trusted CI/CD pipeline of the target project. - Hijacking SLSA Provenance: This is the most novel aspect. Because the malicious code was running within the legitimate, trusted build environment, the build process itself generated valid SLSA provenance signatures for the compromised packages. This made the malicious artifacts appear authentic and trustworthy, bypassing a key supply chain security control (
T1611 - Valid Accounts: Cloud Accounts). - Credential Theft: The injected malware executed during the build process or upon package installation (
postinstallscripts) and began harvesting sensitive information from the developer's environment. - Exfiltration: Data was exfiltrated using the decentralized Session network. This makes the command-and-control (C2) infrastructure highly resilient and difficult to track or take down (
T1048 - Exfiltration Over Alternative Protocol). - Propagation: The malware used stolen GitHub and npm/PyPI API tokens to commit malicious code to other repositories or publish new malicious versions of packages, enabling it to spread automatically (
T1105 - Ingress Tool Transfer).
Impact Assessment
The Mini Shai-Hulud campaign has severe implications for the open-source community:
- Erosion of Trust: By successfully generating valid SLSA signatures for malicious packages, the attackers have undermined a critical security framework designed to build trust in the software supply chain.
- Widespread Credential Compromise: The theft of developer credentials, API keys, and cloud secrets can lead to further, more damaging attacks against individuals and their employers.
- Contamination of the Ecosystem: With over 170 packages compromised and self-propagation capabilities, the malware could spread rapidly, creating a cascade of compromised software that is difficult to eradicate.
- Threat to AI Development: The targeting of AI projects like Mistral AI indicates that attackers are focusing on the rapidly growing AI development ecosystem, aiming to steal valuable models, data, or compute resources.
IOCs — Directly from Articles
No specific Indicators of Compromise (IPs, domains, hashes) were mentioned in the source articles.
Cyber Observables — Hunting Hints
Security teams and developers should hunt for the following patterns:
pull_request_target in GitHub Actions workflowspackage-lock.json or requirements.txtnode_modules/.bin or Python's site-packagesDetection & Response
- CI/CD Security Audits: Regularly audit GitHub Actions workflows. Avoid
pull_request_targetwhere possible, or use it with extreme caution, ensuring no user-controllable input is executed. Use tools likeStepSecurityto harden CI/CD pipelines. - Dependency Scanning: Implement dependency scanning tools that check for known malicious packages and suspicious behaviors (e.g., use of
postinstallscripts that access the network). - Provenance Verification: While this attack bypassed it, organizations should still verify SLSA provenance where possible but treat it as one signal among many. Correlate provenance data with other indicators, such as the reputation of the publisher and the age of the package.
- Egress Filtering: Block outbound traffic from build servers to non-essential destinations, particularly known anonymizing or decentralized networks.
Mitigation
- Harden CI/CD Pipelines: Pin GitHub Actions to specific commit SHAs to prevent injection. Disable script execution from pull request bodies. Grant the minimum necessary permissions to CI/CD jobs.
- Use Immutable Dependencies: Use lockfiles (
package-lock.json,poetry.lock) and verify their integrity during builds to ensure that the exact, vetted versions of dependencies are used. - Developer Education: Train developers on the risks of supply chain attacks, including the dangers of misconfigured CI/CD pipelines and how to vet third-party dependencies.
- Principle of Least Privilege: Ensure that secrets and tokens available in the CI/CD environment are scoped to the minimum required permissions and have short lifetimes.
Timeline of Events
Article Updates
May 19, 2026
TanStack details reveal sophisticated supply chain attack on 42 npm packages via GitHub Actions cache poisoning and OIDC token theft.
Update Sources:
MITRE ATT&CK Mitigations
Software Configuration
Harden CI/CD pipeline configurations. Avoid dangerous settings like 'pull_request_target' in GitHub Actions, or apply strict controls to prevent script injection from PRs.
Code Signing
While bypassed in this attack, code signing and provenance verification (SLSA) are still crucial. This incident highlights the need to secure the signing process itself.
Run build processes in ephemeral, isolated, and sandboxed environments with no access to the broader network or sensitive secrets, limiting the blast radius of a compromised build.
Filter Network Traffic
Implement strict egress filtering for build environments to block connections to unknown or decentralized networks like Session, preventing data exfiltration.
Mapped D3FEND Techniques:
D3FEND Defensive Countermeasures
The primary vector for the 'Mini Shai-Hulud' attack was the abuse of misconfigured GitHub Actions. Organizations must immediately audit all CI/CD workflows for insecure configurations. Specifically, any workflow using the pull_request_target trigger should be treated as highly sensitive. Best practice is to avoid this trigger if possible. If it must be used, ensure that no part of the pull request (e.g., title, body, branch name) is used to construct scripts or commands. Instead, use dedicated GitHub Actions that are designed to safely handle input from forks, such as those provided by StepSecurity. Harden workflows by pinning actions to full commit SHAs instead of tags (e.g., actions/checkout@a12a3959b4314016424a4da9ea17db71f2b9d54c instead of actions/checkout@v2). This prevents the build from being compromised if the tag is maliciously moved.
To detect malicious behavior in dependencies, integrate dynamic analysis (sandboxing) into the CI/CD pipeline. Before a new or updated dependency is promoted to a production build, it should be installed and run in an isolated, instrumented environment. Monitor the dependency for suspicious activities such as network connections to unexpected endpoints (especially anonymizing networks like Session), file system access outside of its intended scope, or attempts to read sensitive environment variables. Tools like Socket or Phylum provide this type of analysis for open-source packages. This acts as a critical backstop, catching malicious code that static analysis might miss, and can prevent a compromised package from ever reaching a developer's machine or a production build.
Build environments should be treated as untrusted and have strict network controls. Implement outbound traffic filtering (egress filtering) for all CI/CD runners. By default, deny all outbound network connections. Create an explicit allowlist for only the necessary domains required for the build process (e.g., npmjs.com, pypi.org, internal artifactories). This would have effectively neutered the 'Mini Shai-Hulud' malware by blocking its ability to exfiltrate stolen credentials to the decentralized Session network. This 'zero trust' approach to the build environment's networking capabilities is a powerful mitigation against both data exfiltration and the downloading of second-stage malware.
Sources & References(when first published)
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.