software supply chain security
SBOM vulnerability management
software supply chain chain reaction
multi-stage supply chain attack
dependency graph security
prevent open source attacks
multi-stage intrusion defense
supply chain attack pivot
3CX breach lessons
dependency layer security
trusted dependency compromise
open source supply chain security
purge compromised dependencies
rapid dependency patching
automated dependency remediation
InstaSLA dependency alerts
cross-repository dependency management
AppSec supply chain playbook
transitive dependency attacks
software bill of materials security
Supply Chain Chain Reactions: Stopping Multi-Stage Attacks
Back to blog
The Evolution of the Multi-Stage Supply Chain Attack
Phase 1: The Upstream Compromise (Poisoning the Well)
Phase 2: The Pivot (Triggering the Chain Reaction)
Phase 3: Broad Ecosystem Distribution
Phase 4: Downstream Execution and Harvesting
The Criticality of Dependency Graph Security
The Ticking Clock: Why Legacy AppSec Fails
Stopping the Pivot: The InstaSLA Playbook
- Grouping Shared Dependency Alerts
- Enforcing Emergency SLAs
- CI/CD Pipeline Blocking
- Post-Incident Auditing and Credential Rotation Conclusion Supply Chain "Chain Reactions": Stopping Multi-Stage Intrusions at the Dependency Layer In the continually evolving landscape of cybersecurity, the nature of software supply chain attacks has undergone a radical transformation. We have moved far beyond the days when a threat actor would simply exploit a misconfigured server or guess a weak password to gain initial access. Today's apex predators in the cybercriminal ecosystem understand that the most efficient way to compromise a thousand organizations is to compromise the one software vendor they all trust.
This paradigm shift was starkly illuminated by the 3CX breach of 2023. Mandiant, the incident response firm brought in to investigate, described it as the first time they had seen one software supply chain compromise lead directly to another — a double software supply chain attack. The attackers, tracked by Mandiant as UNC4736 and linked to the North Korea-aligned Lazarus Group, didn't go after 3CX directly. They first compromised Trading Technologies, poisoning a since-discontinued trading application called X_TRADER that was, unfortunately, still downloadable from the vendor's website. A 3CX employee installed the trojanized installer on a personal computer in April 2022, which planted a modular backdoor (VEILEDSIGNAL) and handed the attackers working credentials into 3CX's corporate network. From there they moved laterally, compromised 3CX's Windows and macOS build pipelines, and shipped a poisoned version of the 3CX desktop client — complete with a downloader (SUDDENICON) that pulled command-and-control addresses from encrypted icon files hosted on GitHub — to a customer base of roughly 600,000 organizations and 12 million daily users.
Three years on, that methodology hasn't just persisted — it has been industrialized. The "chain reaction" is no longer a rare anomaly; it is standard operating procedure for a multi-stage supply chain attack. This article walks through the anatomy of the largest confirmed cascading breach of 2026, why traditional application security (AppSec) response models are structurally too slow to stop it, and how engineering and security operations (SecOps) teams can use intelligent grouping and strict SLA enforcement to purge compromised dependencies before an attacker can pivot.
The Evolution of the Multi-Stage Supply Chain Attack
To understand how to defend against a chain reaction, it helps to deconstruct one in detail. Between March and August 2026, a financially motivated threat actor tracked by Google as UNC6780 — and publicly known as TeamPCP (also seen under the aliases DeadCatX3, PCPcat, ShellForce, and CipherForce) — ran what several incident responders now consider the reference case for this attack pattern. The group didn't appear out of nowhere: it spent late 2025 as an opportunistic cloud botnet operator, mass-compromising more than 60,000 internet-exposed Docker, Kubernetes, and Redis instances for cryptomining, before pivoting to supply chain intrusions in early 2026.
A modern multi-stage supply chain attack typically executes in four distinct phases.
Phase 1: The Upstream Compromise (Poisoning the Well)
Attackers no longer target the end victim directly. They seek out a foundational, over-trusted layer of the development infrastructure — and in 2026, the preferred target was the security tooling itself. According to Aqua Security's own advisory and subsequent analysis from Akamai and StepSecurity, the roots of the incident actually trace back roughly 16 months, to November 2024, when a maintainer of an unrelated project accidentally exposed a personal access token inside a CI workflow. That leaked token was eventually used, in February 2026, to exploit a misconfigured pull_request_target trigger in the GitHub Actions workflow for Trivy, Aqua Security's widely deployed open-source vulnerability scanner. Aqua rotated credentials after detecting the intrusion, but the rotation wasn't atomic — a gap that let the attackers retain working access to Trivy's aqua-bot service account.
On March 19, 2026, TeamPCP used that retained access to force-push malicious commits — impersonating real maintainers' GitHub identities in the process — across 76 of the 77 version tags in aquasecurity/trivy-action and all seven tags of aquasecurity/setup-trivy, while simultaneously publishing a backdoored Trivy binary (v0.69.4). Because Git tags are mutable by default, none of the tag names, publish dates, or release pages showed any visible sign of tampering; organizations pinning to @v0.35.0 or similar version tags — widely considered a security best practice — were silently redirected to malicious code. The compromise was assigned CVE-2026-33634 (CVSS 9.8) and added to CISA's Known Exploited Vulnerabilities catalog a week later. SANS Institute estimated more than 10,000 CI/CD workflows referenced the affected actions.
Phase 2: The Pivot (Triggering the Chain Reaction)
Because a security scanner is inherently trusted and typically runs with elevated privileges inside CI/CD pipelines, TeamPCP used the compromised Trivy action as a pivot point rather than an end in itself. Even after Aqua's containment efforts began, the attackers demonstrated they hadn't fully lost their foothold — three days into remediation, they published two more malicious Trivy images to Docker Hub (v0.69.5 and v0.69.6) with no corresponding GitHub releases, a mismatch that itself became a key detection signal.
The same playbook was run against a second security tool almost immediately: on March 23, TeamPCP hijacked 35 tags across Checkmarx's KICS and AST GitHub Actions, along with Checkmarx's VS Code extensions. And critically, because the AI gateway project LiteLLM ran Trivy inside its own CI pipeline, the poisoned scanner harvested LiteLLM's PyPI publishing token straight out of runner memory. TeamPCP used it the next day.
Phase 3: Broad Ecosystem Distribution
On March 24, 2026, between roughly 10:39 and 16:00 UTC, TeamPCP published two malicious versions of LiteLLM — 1.82.7 and 1.82.8 — to PyPI. LiteLLM is downloaded an estimated 3.4–3.6 million times a day, and because the updates came from the project's own legitimate, trusted publishing pipeline, package managers pulled them into production without friction. The compromise was tracked as PySEC-2026-2 and later folded into the same CVE-2026-33634 record as the Trivy incident.
The campaign didn't stop there. The same stolen-credential playbook was used to push malware into the npm ecosystem — a self-propagating campaign researchers dubbed "CanisterWorm," which hit at least 64 unique packages and more than 140 published artifacts, using an Internet Computer Protocol canister as a dead-drop for its command-and-control infrastructure. Over the following months, public reporting and independent timelines tied the broader TeamPCP campaign to compromises of the Telnyx Python SDK, the TanStack and AntV JavaScript ecosystems (323 packages in AntV's case alone), Microsoft's DurableTask project, roughly 3,800 internal GitHub repositories, 32 Red Hat Cloud Services packages, and packages tied to Bitwarden and SAP.
Phase 4: Downstream Execution and Harvesting
The final stage occurred inside the infrastructure of the ultimate victims. In the Python ecosystem specifically, the malicious LiteLLM releases used a .pth startup-hook file — a technique that executes the moment the Python interpreter initializes, regardless of whether a developer ever explicitly imports the compromised library. Analysis from Trend Micro found the payload was staged in three parts: a credential harvester targeting more than 50 categories of secrets, a Kubernetes lateral-movement toolkit, and a persistent backdoor for follow-on access. Once active inside a victim's CI/CD runner, the malware swept for AWS, GCP, and Azure credentials, Kubernetes service account tokens, SSH keys, .env file contents, and LLM API keys.
Estimates of the total blast radius vary by methodology and are still being revised as more forensic reporting emerges. CloudSEK's threat intelligence team, after obtaining and analyzing a large corpus of exfiltrated CI runner data, mapped exposure to more than 2,500 organizations and roughly 434,000 CI/CD pipelines, calling it the largest AI-infrastructure supply chain breach of 2026. A separate law-enforcement estimate cited in later reporting put the figure at more than 1,000 confirmed compromised organizations, over 500,000 stolen credentials, and at least 300GB of exfiltrated data. Public advisories and reporting named the European Commission, Mistral AI, OpenAI, and GitHub among the organizations affected downstream — not because their own SDKs were poisoned, but because they were customers or users of the compromised tooling. The harvested credentials were, per multiple reports, sold on cybercriminal forums or used directly for extortion.
In a coda that will be of some comfort to defenders: Australian, U.S., and Western Australian police arrested two men — reported by Krebs on Security as Ruben Ian Thomson and Michael Gaebler, aged 21 and 23 — on August 26, 2026, after investigators traced operational security failures (the same handles, and in one case the same cat avatar, reused across HackerOne, Hugging Face, TikTok, Steam, and Telegram) back to real identities. The pair faced 14 combined cybercrime charges, with a court date set for September 18, 2026.
The Criticality of Dependency Graph Security
The success of a software supply chain chain reaction relies entirely on the opacity of modern dependency trees. Modern software is not built from scratch; it is assembled from thousands of interconnected third-party libraries. This web of interconnected code is the dependency graph, and the scale of the problem it represents is no longer abstract.
Dependency graph security is the practice of mapping, monitoring, and securing every node within this tree, including direct dependencies (the libraries your developers explicitly import) and transitive dependencies (the libraries your libraries import, often without a developer ever seeing the name). Sonatype's 2026 State of the Software Supply Chain report — drawing on telemetry from Maven Central and its own security research — counted over 454,600 newly identified malicious open source packages across npm, PyPI, Maven, NuGet, and Hugging Face in 2025 alone, a 75% year-over-year increase, bringing the cumulative tracked total above 1.23 million. ReversingLabs' own 2026 report put the year-over-year growth at a similar 73%, and specifically flagged 2025 as the year attackers pivoted from obscure, single-maintainer packages toward popular, actively maintained ones — the same pattern visible in the Trivy-to-LiteLLM chain. Well over 99% of tracked open source malware now shows up on npm specifically, according to Sonatype's data.
The stakes of getting this wrong are no longer theoretical. Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled in a single year, from 15% to 30% — the largest single-year shift the report has ever recorded. IBM's 2025 Cost of a Data Breach Report priced the average supply chain compromise at $4.91 million and found it takes an average of 267 days to identify and contain — the longest lifecycle of any breach vector the report tracks. ENISA's 2025 Threat Landscape attributed roughly 10.6% of a nearly 5,000-incident corpus to traditional software supply chain attacks.
When a multi-stage attack occurs, the malicious payload is frequently hidden deep within the transitive layers of this graph, exactly as it was with Trivy → LiteLLM. A developer might explicitly trust and import Package A. Package A imports Package B, which relies on Package C. If Package C is compromised via a chain reaction, the entire application becomes vulnerable — often without anyone on the engineering team having ever heard of Package C.
To prevent open source attacks from cascading, organizations need real-time visibility into their Software Bill of Materials (SBOM) and the ability to instantly identify every application, microservice, and repository that relies on a specific, newly compromised package. But identifying the vulnerability is only half the battle. The true failure point for most organizations lies in how they operationalize that intelligence once they have it.
The Ticking Clock: Why Legacy AppSec Fails
When a widely used package is compromised and actively harvesting CI/CD secrets in the wild, the remediation window is measured in hours, not days or weeks — the LiteLLM exposure window alone was measured in a matter of hours on March 24. Unfortunately, the traditional Application Security response model is fundamentally incompatible with the speed a chain reaction demands.
Consider the standard response to a zero-day dependency compromise:
Alert Generation: The organization's Software Composition Analysis (SCA) tool detects that a critical dependency — say, a poisoned version of LiteLLM — is present somewhere in the environment.
The Ticket Cannon: Because the organization relies heavily on AI-adjacent tooling, the SCA tool finds this dependency in 500 different repositories. The legacy AppSec system automatically generates 500 individual Jira tickets, assigning them to engineering managers scattered across different business units.
Chaos and Friction:
Alert Fatigue: Engineering managers, already buried in backlog, see an influx of high-severity tickets indistinguishable from routine noise.
Duplication of Effort: 500 different developers independently start researching the same CVE, trying to understand blast radius and figure out how to patch or roll back.
Asynchronous Patching: Team A might roll back within two hours. Team B might let the ticket sit until the end of the sprint. During that delay, Team B's CI/CD pipeline runs, executes the poisoned code, and leaks production AWS keys — precisely the failure mode IBM's 267-day average containment timeline reflects at scale.
This decentralized, ticket-based approach all but guarantees failure during a genuine chain reaction. It transforms an urgent, organization-wide crisis into hundreds of isolated, uncoordinated tasks. The attackers, as the Trivy incident showed, operate in a matter of hours and re-establish access the moment remediation stalls. Defending with manual ticket routing is bringing a knife to a gunfight.
Stopping the Pivot: The InstaSLA Playbook
To survive a multi-stage supply chain attack, threat intelligence and AppSec teams need a centralized, structured, and rapid response mechanism. The goal is to purge the compromised package organization-wide before attackers can exfiltrate credentials and pivot deeper into infrastructure. This is where modern SLA management and remediation platforms like InstaSLA become critical — shifting the focus from individual tickets to coordinated "Fix Campaigns."
Grouping Shared Dependency Alerts
When the alert fires indicating a trusted dependency has been compromised in a multi-stage attack, the first imperative is to stop the ticket cannon. Instead of generating 500 individual alerts for 500 affected repositories, InstaSLA groups all instances of that specific vulnerable dependency into a single, high-priority Fix Campaign. For the AppSec team, this provides a unified view of the exact blast radius across the entire dependency graph. For engineering teams, they no longer receive isolated, contextless tickets — they're pulled into a centralized campaign with one clear directive: roll back Dependency X from v1.82.8 to a known-clean version, immediately.Enforcing Emergency SLAs
In a multi-stage supply chain attack, time is the adversary. The moment a compromised package executes in a CI/CD pipeline, tokens start leaving the building — the actual LiteLLM window was measured in hours, not days. Remediation cannot be treated as a standard sprint task. Through a centralized Fix Campaign, security leadership can enforce a strict, non-negotiable SLA — for an actively exploited chain-reaction vulnerability, that might be as short as 4 to 8 hours. InstaSLA provides real-time visibility into SLA compliance so engineering directors can see exactly which repositories have purged the dependency and which are dangerously close to breaching it, eliminating the bystander effect common in mass vulnerability disclosures.CI/CD Pipeline Blocking
Visibility and SLAs only have teeth if they're backed by enforcement. The Trivy incident is a useful cautionary tale here: post-incident analysis from Upwind pointed out that GitHub's "Immutable Releases" badge — meant to signal that a release can't be altered — was itself present on some of the compromised artifacts, because the poisoning happened at the tag level before the badge was ever applied. Trust signals alone weren't enough. During a Fix Campaign, systems like InstaSLA integrate directly into the CI/CD pipeline so that if a repository attempts to build or deploy while it still contains the compromised dependency version, the pipeline is mechanically blocked — regardless of whether a developer saw the alert. This is the pattern the industry actually converged on in the weeks after the Trivy incident: security teams at organizations like Telnyx moved to PyPI's Trusted Publishing model to eliminate long-lived, stealable tokens altogether, and a wave of GitHub Actions users pinned their workflow dependencies to immutable commit SHAs instead of mutable tags, closing the exact gap TeamPCP exploited.Post-Incident Auditing and Credential Rotation
Once a dependency is purged organization-wide and the Fix Campaign is closed, the work isn't over. Because these attacks steal secrets directly from process memory — TeamPCP's toolkit reportedly read runner secrets straight out of /proc/pid/mem — the safe assumption is that any credentials exposed to the compromised package during its active window are burned. The centralized nature of the Fix Campaign provides the exact exposure timeline for each repository, so security teams can drive targeted credential rotation — revoking and reissuing GitHub PATs, cloud access keys, and Kubernetes tokens only for verifiably exposed systems, rather than attempting a chaotic, disruptive global reset.
Conclusion
The software supply chain has become a highly leveraged attack surface, and the numbers back that up: a 75% year-over-year jump in newly discovered malicious open source packages, a doubling of third-party involvement in breaches, and an average 267-day containment window that no attacker actually waits for. The 3CX breach of 2023 proved that compromising a single trusted node could yield access to thousands of downstream targets. By 2026, TeamPCP's Trivy-to-LiteLLM campaign showed just how far that methodology has been industrialized — routinely pivoting from security tooling into AI SDKs, package registries, and, eventually, enterprise CI/CD pipelines at a scale CloudSEK measured in the hundreds of thousands of exposed pipelines.
Defending against a software supply chain chain reaction requires organizations to fundamentally re-evaluate their incident response protocols for dependency vulnerabilities. When a trusted library turns malicious, generating hundreds of disconnected Jira tickets is a recipe for exactly the kind of asynchronous, 267-day-average failure the industry keeps re-learning. To secure the dependency graph and prevent open source attacks from spreading, AppSec and engineering teams need unified visibility and enforced speed — both the structural fixes the industry adopted after Trivy (SHA-pinned actions, trusted publishing, treating security tooling itself as a first-class dependency to be scrutinized) and the operational discipline to group shared alerts into singular Fix Campaigns with tools like InstaSLA. In the era of the multi-stage pivot, coordinated speed is the only defense that actually keeps pace with the attackers.Software Supply Chain Security: Moving from SBOMs to SLA Enforcement
Top comments (0)