When a compromised GitHub Actions workflow executed at TanStack, 84 malicious package artifacts were published across 42 @tanstack/* packages within six minutes. The worm's self-propagation mechanism then expanded rapidly. By end of day, 373 malicious versions had spread across 169 npm packages plus compromised PyPI packages.
No phishing email landed in anyone's inbox. No attacker typed a password at a login screen. The CI/CD pipeline did it itself, and then used its own trusted credentials to keep going.
That is the Mini Shai-Hulud campaign, attributed to a threat group called TeamPCP and documented by researchers at Unit 42, Aikido, and ReversingLabs across May and June 2026. South African enterprises running JavaScript-based applications, cloud-connected development environments, or GitHub Actions pipelines face exactly the same attack class. The question your security team needs to answer is whether your current penetration testing South Africa programme would find any of it before an attacker does.
Mini Shai-Hulud is a worm designed to live inside modern build systems, harvest tokens from CI/CD pipelines and developer workstations, and then weaponise that access to publish malicious versions of additional packages. The attack abuses npm lifecycle scripts, the Bun JavaScript runtime, GitHub trusted publishing workflows, and OIDC authentication to spread automatically through trusted release paths.
The initial TanStack vector illustrates the attack's sophistication.
The root cause was a compromised account used to trigger GitHub Actions workflows that requested OpenID Connect (OIDC) tokens, publishing trojanised packages with valid SLSA provenance. The certificate was accurate: the packages really were built by that pipeline. They also happened to have malware injected into them at the time.
This matters because SLSA provenance is increasingly treated as a trust signal by enterprise security tooling. The Mini Shai-Hulud campaign demonstrated that provenance validation and malware are not mutually exclusive.
The malware executes the moment an affected software package is installed, whether in a developer's local environment or inside a CI/CD pipeline. A hook fires before any other step, giving the payload immediate access to the machine. It harvests GitHub tokens, npm tokens, SSH keys, cloud provider credentials, and database connection strings.
The stolen tokens then fuel autonomous republication: every package the victim developer or CI runner had permission to publish becomes a potential next victim.
One of the most technically advanced capabilities in Mini Shai-Hulud is its memory scraper. It targets the Runner.Worker process on Linux-based GitHub Actions runners. By reading process memory directly, it can extract secrets that are "masked" in logs. While a GitHub log might show asterisks for a secret variable, the malware sees the raw plaintext value sitting in the runner's heap.
This renders standard secret-masking techniques ineffective against an attacker who has already reached the runner environment.
On June 1, 2026, researchers at Aikido and OX Security confirmed that 32 packages and 96 package versions under Red Hat's @redhat-cloud-services namespace had been backdoored with a new variant called Miasma. TeamPCP publicly released the Mini Shai-Hulud source code in May, and Miasma appears to be a fork.
The campaign is no longer one group running one operation. The attack pattern is now available to any threat actor willing to use it.
Most penetration testing South Africa programmes treat the network perimeter, applications, and endpoints as the attack surface. That framing made sense when attackers primarily approached from outside. It does not capture attacks that travel through the software delivery pipeline itself.
A standard vulnerability assessment and penetration testing engagement probes internet-facing services, tests authentication mechanisms, and looks for exposed credentials or misconfigured APIs. A standard internal network penetration test attempts lateral movement and identifies privilege escalation paths. Neither exercise typically covers the npm registry, the GitHub Actions workflow configuration, or whether CI/CD secrets are scoped appropriately. Those gaps are exactly where Mini Shai-Hulud operated. CI/CD security sits almost entirely outside the scope of a conventional penetration test.
The Mini Shai-Hulud campaign exposes a structural problem: most security tools were built to audit configurations and permissions. They enforce static controls. This campaign operated entirely in the runtime integration layer, where credentials are used, tokens are minted, data moves between systems, and agents act. That layer has been largely unmonitored.
It rarely appears in a penetration test report because it falls outside the declared scope of a conventional vulnerability assessment and penetration testing engagement.
RL's 2026 Software Supply Chain Security Report notes that npm accounted for nearly 90% of detected open-source malware in 2025, and highlights how campaigns like Shai-Hulud weaponised stolen credentials to spread at scale.
SA enterprises building or maintaining JavaScript applications, using containerised workloads, or running CI/CD infrastructure are consuming from that ecosystem every time a developer runs npm install. A standard vulnerability assessment will not enumerate the full transitive dependency graph of a production application or verify package integrity against expected checksums.
Attackers are no longer just stealing data; they are embedding themselves into CI/CD pipelines to attain long-term, undetectable access to enterprise environments. Multi-stage payloads often deploy dormant "sleeper" dependencies that only activate under specific environmental conditions to evade automated scanners.
A pen test that does not examine pipeline behaviour will not find a dormant payload sitting in a dependency that has not yet been triggered.
Supply chain security testing is a structured assessment of the trust relationships and execution paths connecting your development environment to your production systems. It is not a single scan, and it covers territory that traditional penetration testing services do not routinely include.
CI/CD security assessment examines the configuration of your build pipelines directly. This includes reviewing GitHub Actions workflow files for overly broad permissions, identifying where pipeline secrets are injected and whether they are scoped to minimum necessary access, testing whether OIDC token configurations appropriately limit publishing rights, and verifying that protected branch rules would prevent unauthorised code from triggering a release workflow. A penetration testing South Africa engagement that includes CI/CD scope attempts to exploit misconfigured workflow triggers to demonstrate actual privilege escalation, not merely flag configuration issues on a checklist.
Credential repository testing addresses the specific behaviour Mini Shai-Hulud demonstrated at scale. This involves checking developer workstations and CI runners for stored credentials in predictable locations, reviewing how npm tokens, GitHub PATs, and cloud service keys are stored and rotated, and testing whether secrets management tooling is configured to prevent long-lived static credentials from sitting in environment variables. Magix's source code scanning capability extends into this area, identifying hardcoded secrets in application repositories before an attacker does.
Package integrity verification tests whether your organisation has controls that would detect a compromised package before it executes in your environment.
npm's semver resolution picks the highest version matching a range, regardless of the latest tag. Any project with a caret range in its package.json resolves to the highest available matching version on the next clean install.
Testing whether your CI pipelines use `npm ci` with an immutable lockfile or `npm install` with floating version ranges is a basic but critical finding. The difference between those two commands determined whether organisations were protected during the Mini Shai-Hulud AntV wave.
DevSecOps pipeline validation reviews the full software delivery chain as an attack surface. This covers whether dependency scanning runs on every pull request, whether SAST tools are integrated into build pipelines, and whether alerting would fire on a publishing anomaly of the type Mini Shai-Hulud produced.
The May 19 wave published 637 malicious versions across 317 packages in a 22-minute automated burst.
A security operations environment with behavioural baselines on pipeline activity would see that anomaly immediately; most SA enterprises do not yet have one in place.
Assessing supply chain exposure starts with questions that do not typically appear in a vulnerability assessment and penetration testing scoping call, and that is a gap worth closing before you commission your next engagement.
The first area is the dependency inventory. Do you know the full transitive dependency graph of your production applications? Can you produce a Software Bill of Materials covering every package version in your builds? Can you determine, within an hour, whether any of your builds installed a compromised package version during a specific 22-minute window? Many SA enterprises cannot answer those questions confidently. The inability to answer them is itself a finding.
The second area is pipeline access governance. This connects directly to third-party risk management: CI/CD pipelines routinely have access to production deployment credentials, cloud infrastructure, and customer data environments. Testing whether those access paths follow least-privilege principles, and whether there is any monitoring for anomalous pipeline behaviour, is as relevant as testing whether your network segmentation holds under lateral movement.
"What we see in enterprise environments is that the CI/CD pipeline gets treated like internal infrastructure: assumed safe because it's internal," said Tim Butler, COO, Magix Security. "Mini Shai-Hulud proved that assumption is wrong. The pipeline is a privileged identity with access to everything your developers can touch. If you have not tested it as an attack surface, you have not finished your security assessment."
The third area is incident response readiness for a supply chain event specifically.
Rotating credentials that may have been exposed on affected systems or pipelines, including version control system tokens, CI/CD secrets, cloud keys, npm tokens, and SSH keys, is the immediate required response to a confirmed supply chain compromise.
Most organisations do not have a tested playbook for executing that process rapidly. A supply chain-focused assessment can validate whether your team could execute that rotation within a timeframe that limits damage, or surface the gaps before an actual event forces the question.
The fourth area covers your external development partners. SA enterprises commonly grant outsourced development teams access to GitHub repositories and CI/CD tooling. That access may not be reviewed regularly, may not be scoped to specific repositories, and may not be revoked when an engagement ends. Assessing third-party access paths into your build and deployment infrastructure is an extension of vulnerability management that most programmes currently do not include. As we covered in our analysis of third-party risk as systemic risk, the access your vendors hold into your environment is increasingly where attackers look first.
POPIA Section 19 requires responsible parties to take appropriate, reasonable technical and organisational measures to prevent unauthorised access to personal information. A supply chain compromise of the Mini Shai-Hulud type is precisely the scenario Section 19 addresses: an attacker gains access to production credentials through a trusted development pathway and then has unrestricted access to any system those credentials can reach, including databases containing personal information of South African data subjects.
The PCI DSS 4.0 connection is equally direct. Requirement 6.3 mandates that all system components are protected from known vulnerabilities, and Requirement 6.2 specifically addresses the security of bespoke and custom software. If your payment application's JavaScript dependencies pull from a compromised npm namespace, that is a PCI DSS scope issue, not merely a developer tooling problem. Our guide on incorporating PCI DSS testing into your DevOps cycle outlines how compliance validation integrated directly into the build pipeline is more defensible than treating it as a periodic audit exercise.
There is also a cyber insurance implication that SA enterprises are only beginning to contend with. Policies increasingly distinguish between attacks that exploit known, unpatched vulnerabilities and attacks that succeed because no one tested the relevant attack surface at all. Supply chain security testing, as a documented, scoped assessment of your CI/CD environment and dependency infrastructure, is exactly the kind of evidence that supports a policy claim after an incident and a credible risk posture before one.
The Mini Shai-Hulud campaign, the Red Hat namespace compromise, and the earlier Axios attack that hit over 100 million weekly downloads have collectively established that software supply chain attacks are not a theoretical category reserved for nation-state targets. They are an active attack class targeting the infrastructure that SA enterprises use to build and deploy software every day. If your current penetration testing programme does not include CI/CD security assessment, dependency chain analysis, and credential repository testing, your attack surface is larger than your last pen test report shows.
Magix's penetration testing services extend to supply chain security assessment across your development pipeline, dependency infrastructure, and third-party access paths. Contact Magix to discuss what a supply chain-focused engagement would cover for your organisation.
