grid
Abstract circular gradient with concentric rings in blue, green, yellow, and red fading into black background.
5 min read

Cisco Source Code Stolen in Trivy Supply Chain Attack

Cisco supply chain attack
Published on
April 1, 2026

Cisco's internal development environment has been breached in a supply chain attack that began weeks before the company's systems were ever touched. Threat actors used credentials harvested during the compromise of Trivy, a widely used open-source vulnerability scanner, to access Cisco's build pipelines, clone source code, and move laterally into a small number of its AWS accounts.

The breach is the highest-profile confirmed casualty of a coordinated campaign carried out by a threat group known as TeamPCP. What started with a single compromised security tool has now cascaded across some of the most trusted components in modern software development infrastructure.

How the Trivy Compromise Set the Stage

The attack chain began on March 19, 2026, when TeamPCP gained access to Aqua Security's service account and used it to force-push malicious code to 76 of 77 version tags in the aquasecurity/trivy-action GitHub Action and all seven tags in aquasecurity/setup-trivy. At the same time, the group published a malicious Trivy binary, version 0.69.4, to official distribution channels including GitHub Releases and container registries.

The payload was designed for stealth. It ran silently alongside the legitimate vulnerability scan, so pipelines produced normal-looking output while credentials were being harvested in the background. Environment variables, cloud tokens, SSH keys, and AWS credentials were encrypted and exfiltrated to attacker-controlled infrastructure.

The incident was assigned CVE-2026-33634 with a near-maximum CVSS score of 9.4. The Trivy team identified and contained the active distribution phase later that day, but by then the credential theft was already done.

Cisco's Development Environment Targeted

Cisco used Trivy as part of its CI/CD pipeline security scanning. When those pipelines executed the compromised GitHub Action, TeamPCP's infostealer harvested the credentials needed to access Cisco's internal build and development infrastructure.

The impact was substantial. Attackers cloned more than 300 GitHub repositories from Cisco's internal environment. The stolen code includes source code for several of Cisco's AI products, including AI Assistant and AI Defense, as well as code for products that have not yet been publicly released. A portion of the stolen repositories reportedly belongs to corporate customers, including banks, business process outsourcing firms, and US government agencies.

Beyond the code repositories, multiple AWS keys were stolen and later used to perform unauthorized activity across a small number of Cisco AWS accounts. The breach affected dozens of devices in total, including developer and lab workstations. More than one threat actor was reportedly involved across the CI/CD and AWS account compromises.

Cisco's Unified Intelligence Center, CSIRT, and Emergency Operations Center teams have contained the breach. However, the company expects continued fallout from downstream supply chain attacks that followed the initial Trivy compromise.

A Campaign That Kept Expanding

The Cisco breach did not happen in isolation. After the Trivy compromise gave TeamPCP a wide pool of stolen credentials, the group moved methodically through the development tooling ecosystem.

On March 23, the campaign reached Checkmarx, with the group hijacking GitHub Actions for both the KICS and AST repositories. Malicious VSCode extensions were published around the same time. On March 24, LiteLLM, an open-source AI gateway with roughly 95 million monthly PyPI downloads, was compromised through poisoned package versions 1.82.7 and 1.82.8. By March 27, the Telnyx Python SDK had also been targeted.

Each wave used credentials stolen in the previous phase. One stolen token from one incomplete credential rotation became the entry point for a cascading compromise spanning multiple ecosystems.

The campaign introduced a technically notable innovation: a blockchain-based command-and-control mechanism using an Internet Computer Protocol canister, referred to as CanisterWorm in relation to a self-propagating npm component. Because the C2 is hosted on decentralised infrastructure, conventional domain takedown methods do not work against it.

What Makes This Attack Particularly Damaging

The Cisco supply chain attack illustrates a risk that security teams have long warned about, but rarely seen confirmed at this scale. The organisations most exposed were not those ignoring security hygiene. They were the ones running automated vulnerability scans on every build. Trivy was trusted precisely because it was a security tool. That trust became the attack surface.

When source code from AI products and government-adjacent customer repositories is stolen, the downstream risks extend far beyond the initial breach. Attackers with access to proprietary source code can study it for vulnerabilities, map internal logic, or use it to craft more targeted attacks against Cisco's customers and partners.

The theft of AWS credentials adds another dimension. Cloud account access can enable data exfiltration, resource abuse, or lateral movement into customer environments, depending on what permissions were attached to the compromised keys.

Steps Organisations Should Take Now

Any organisation that ran Trivy, Checkmarx KICS, or LiteLLMin a CI/CD pipeline between March 19 and March 24, 2026, should treat all credentials accessible to those pipelines as compromised. That means rotating AWS keys, SSH keys, GitHub tokens, Kubernetes secrets, and any other secrets that build runners had access to during that window.

Audit GitHub Actions workflow logs for references to tpcp.tar.gz, suspicious outbound connections from CI runners, or repositories named tpcp-docs created within your GitHub organisation. These are known indicators of successful exfiltration.

Going forward, pinning GitHub Actions to full commit SHAs rather than version tags removes one of the core mechanisms this attack exploited. Version tags are mutable and can be force-pushed. Commit SHAs cannot. It is a straightforward configuration change that closes a significant exposure in any CI/CD pipeline.

Cisco has not issued a public statement at the time of writing.

Subscribe to newsletter

Subscribe to receive the latest blog posts to your inbox every week.

By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.