How Replicating Marauder Rewired the Supply Chain Playbook

In March 2026, researchers began linking a series of software supply-chain compromises to Replicating Marauder, the BlueVoyant Threat Fusion Cell (TFC) primary identifier for the actor publicly tracked elsewhere as TeamPCP. What made the campaign stand out was that trusted software was poisoned and one compromise repeatedly appeared to enable the next by exposing credentials, release paths, or Continuous Integration and Continuous Delivery or Deployment (CI/CD) trust relationships.

By late April and early May 2026, that pattern had widened into the Mini Shai-Hulud phase, in which malicious packages and worm-like propagation moved across npm, PyPI, Docker Hub, and Packagist in a compressed operational window. For security leaders, defenders, and technical decision-makers, BlueVoyant TFC assesses with high confidence that the attackers were not just targeting companies one at a time; rather, they likely sought to hijack the tools, identities, and update mechanisms those companies already trusted, turning the software supply chain itself into a self-propagating attack surface.

Background and Threat Overview

Replicating Marauder was already associated with cloud-focused criminal activity before the 2026 supply-chain phase, and earlier Shai-Hulud activity had already demonstrated interest in scalable access, credential theft, and abuse of trusted technical pathways for downstream gain. What changed in March 2026 was operational maturity: rather than simply abusing access after compromise, the actor increasingly targeted developer tooling, package registries, and CI/CD relationships as force multipliers.

That made Replicating Marauder distinct from more conventional criminal campaigns that scale through a single vulnerable platform or straightforward extortion pressure, especially when compared with reporting on Rift Brigantine (a.k.a. Cl0p), Volatile Brigantine (a.k.a. LAPSUS$), and Obsidian Marauder (a.k.a. FIN7). Its defining feature was the combination of poisoned developer tooling, chained build-path compromise, and later cross-ecosystem propagation.

In mid-May 2026, the source code for the Shai-Hulud malware was released publicly, which ReversingLabs described as lowering the barrier for additional supply-chain operators and copycat activity. That public code release shifted the threat from one actor's campaign into a potentially reusable criminal framework. Reporting also indicated that new Mini Shai-Hulud variants were still emerging in May 2026, including a large npm phase against the AntV ecosystem and related packages, reinforcing the view that the campaign had moved from targeted compromise into repeatable propagation.

Attack Breakdown

Phase 1: Trust Seeding Through Security and Developer Tooling

In March 2026, the campaign centered on compromising tools that developers and defenders already trusted, including incidents associated with Trivy, LiteLLM, and Telnyx. Those compromises established the campaign's core operating model: poison trusted tooling, steal credentials or tokens, and position for downstream access through normal software-delivery behavior.

This phase was less about autonomous spread and more about seeding access into environments that already had privileged visibility into code, secrets, and release paths. In practical terms, the attackers treated security and developer tooling as high-leverage entry points rather than as end targets.

Phase 2: Chained CI/CD and Downstream Exploitation

In late April 2026, the activity broadened from isolated package compromise into chained abuse of build and release relationships. Incidents involving the Checkmarx KICS compromise, xinference, and the Bitwarden CLI cascade showed that Replicating Marauder was not just inserting malicious code into packages, but also exploiting automation, inherited trust, and ordinary CI/CD workflows to push compromise further downstream.

This was the point where the campaign most clearly demonstrated that one poisoned dependency or container image could trigger compromise in an unrelated organization's release pipeline. The tactical shift turned isolated software poisoning into a reproducible method for victim-to-victim expansion.

Phase 3: Mini Shai-Hulud Cross-Ecosystem Propagation

Beginning 29 April 2026, the Mini Shai-Hulud phase marked the campaign's most consequential evolution. The initial documented spread crossed npm, PyPI, and Packagist through compromised packages associated with SAP, PyTorch Lightning, intercom-client, and intercom-php.

This propagation model then escalated in May 2026 through large npm-centered phases that affected the TanStack ecosystem and later the AntV ecosystem, alongside related package sets such as echarts-for-react and other downstream dependencies. Public reporting on these later May phases described large-scale malicious publishing, stolen CI/CD secrets, forged provenance signals in some cases, and repeated repackaging behavior consistent with a mature propagation framework rather than isolated package tampering.

A separate May variant also used a typosquatted npm package, crypto-javascri, to push compromise into maintained packages and support stealthier persistence and command-and-control behavior. The TFC assesses with high confidence that the attackers were not just targeting companies one at a time; rather, they likely sought to hijack the tools, identities, and update mechanisms those companies already trusted, turning the software supply chain itself into a self-propagating attack surface.

Technique Evolution

The campaign's phases differed less by target branding than by technique and propagation model. The March phase emphasized trusted release-point compromise and credential theft from high-value tooling; the April phase cantered on chained CI/CD abuse and downstream inheritance of trust; and the Mini Shai-Hulud phase added repeated repackaging, automated spread, and cross-ecosystem propagation.

That evolution shows a progression from access seeding, to build-path chaining, to scalable self-propagation. In other words, the campaign became more dangerous not merely because it touched more packages, but because each successive phase reduced the amount of manual effort required to create new downstream victims.

Criminal Strategy in Context

Replicating Marauder fits within a broader criminal pattern of abusing concentrated trust to reach many victims quickly, but it differs from other financially motivated campaigns in how heavily it relies on developer infrastructure and release automation, especially when compared against Rift Brigantine, Volatile Brigantine, and Obsidian Marauder. Rift Brigantine is most closely associated with mass exploitation of shared third-party data transfer services/infrastructure for data-theft extortion, while Volatile Brigantine became known for supplier compromise, credential theft, and public pressure, and Obsidian Marauder remains a broad cybercrime operator with mature monetization tradecraft.

What separates Replicating Marauder is that software supply chains are not just an entry vector; they functioned as the operating environment itself. The campaign repeatedly converted package registries, CI/CD systems, maintainer trust, and release pipelines into both access mechanisms and propagation infrastructure, which is why its activity looks less like a conventional smash-and-grab intrusion set and more like a criminal strategy built around industrializing trust abuse.

Documented Activity Ledger

Remaining Questions

Several questions will shape whether future Replicating Marauder activity remains episodic or matures into a repeatable criminal playbook and whether copycats accelerate that maturation.

First, it remains unclear whether future iterations will continue prioritizing package ecosystems alone or will expand into adjacent trust infrastructure such as artifact registries, container base images, IDE extension marketplaces, infrastructure-as-code module registries (e.g., Terraform, Helm), or AI/ML model hubs like Hugging Face. Each represents a concentrated trust boundary with weaker provenance controls than mainstream package managers.

Second, defenders should watch for more deliberate efforts to operationalize stolen maintainer credentials and CI/CD access across multiple ecosystems in parallel rather than sequentially. A logical next step would be coordinated, time-synchronized publishing across npm, PyPI, and Packagist designed to outpace detection windows and registry takedown response.

Third, the campaign raises the possibility that future phases could blend propagation with faster monetization — collapsing the gap between initial compromise, downstream spread, and exploitation. This could include pre-staged ransomware deployment through poisoned CI/CD runners, automated cryptocurrency wallet draining via injected build steps, or direct sale of harvested CI/CD secrets in bulk to access brokers.

Fourth, the public release of Shai-Hulud source code creates space for capability divergence. Copycat actors may strip the worm logic for stealth-focused intrusions, while more sophisticated operators could graft it onto new payloads — including data-poisoning attacks against AI training pipelines, signed-build forgery, or persistence inside developer identity providers (e.g., GitHub Apps, OAuth tokens).

Finally, an open question is whether nation-state actors will adopt or adapt this model. The same tradecraft that enables criminal propagation also enables targeted espionage at scale, particularly against software vendors whose products reach high-value downstream environments.

Mitigation and Recommendations

The campaign's logic suggests that defenses should be prioritized around trust boundaries, not just around malware scanning or package reputation, as indicated by GitHub Docs. Modern supply-chain attacks succeed when untrusted code, identities, or build state are allowed to cross into trusted release paths.

Priority 1: Protect the Release Trust Boundary

This priority combines release identity protection and cache or workflow isolation because both defend the point where code becomes a trusted published artifact. Organizations should lock down OpenID Connect (OIDC) and trusted publishing, restrict which workflows can publish, validate workflow claims, separate cache scopes between pull request and release workflows, review risky patterns such as pull_request_target, pin external actions to commit SHA, and invalidate caches after suspicious activity.

Priority 2: Reduce Attacker Leverage Inside CI/CD

This priority combines credential minimization and pipeline hardening because both reduce what an attacker can do after entering the build system. Organizations should eliminate long-lived secrets where possible, tightly scope ephemeral tokens, monitor unusual credential issuance, segment runners, restrict egress, and keep untrusted code away from privileged jobs.

Priority 3: Improve Trust Verification and Detection

This priority combines provenance and verification with behavioral monitoring because both improve the ability to distinguish legitimate builds from compromised ones. Organizations should require provenance, validate artifact origin before promotion, adopt SLSA-aligned controls, and alert on unusual maintainer actions, unexpected workflow changes, abnormal publish times, and mismatches between repository history and release activity/

Priority 4: Limit Downstream Impact and Administrative Exposure

This priority combines supplier compromise readiness and maintainer or administrator security because both reduce blast radius if upstream trust is still broken, as advised by Wiz. Organizations should inventory critical dependencies, predefine rollback and package pinning procedures, identify high-blast-radius upstream components, require MFA for repository and registry administration, and reduce the number of users and systems that can approve or trigger releases.

Conclusion

The Replicating Marauder and Mini Shai-Hulud campaign marked a shift in criminal cyber operations from targeting one organization at a time to targeting the trust relationships that connect many organizations at once, as indicated by SANS ISC. Its significance lies in the way individually documented package incidents, CI/CD compromises, and worm-propagated downstream infections formed one broader criminal strategy centered on reusable access and monetization.

For defenders, the lesson is clear: modern cyber resilience now depends as much on securing release identities, build pipelines, package flows, and dependency trust as it does on protecting endpoints and networks, as made clear by GitHub Docs.