Cisco Got Breached. They Ran a Security Scanner.
Cisco Got Breached. They Ran a Security Scanner.
In my last post I wrote about three attacks hitting the JavaScript ecosystem on March 31, 2026 — the Claude Code leak, the axios RAT, and the dependency confusion attack targeting developers trying to compile the leaked source.
I was missing the bigger picture.
Those three incidents were not the beginning of the story. They were the end of it. The axios RAT, the Claude Code chaos, the ShinyHunters extortion demand against Cisco — all of it traces back to a single compromised tool that started spreading 12 days earlier.
It started with Trivy. A vulnerability scanner. A tool whose entire job is to find security problems in your code.
The 12-Day Chain
March 19: Trivy
Trivy is an open-source vulnerability scanner built by Aqua Security. It is one of the most widely used security tools in CI/CD pipelines — thousands of companies, including Cisco, run it automatically as part of their build process. It scans your code for known vulnerabilities. It is trusted by design.
In late February, an automated bot exploited a misconfigured GitHub Actions workflow in the Trivy project and stole a privileged access token. Aqua Security discovered the theft and rotated credentials — but the rotation was incomplete. The threat group known as TeamPCP retained access.
On March 19, TeamPCP used those surviving credentials to force-push malicious code to 76 of 77 version tags across the Trivy GitHub Action repositories. Every CI/CD pipeline that ran Trivy that day executed the malicious code silently alongside the normal vulnerability scan. Pipeline output looked completely clean. No errors. No warnings. Nothing to indicate anything had changed.
Underneath, TeamPCP's Cloud Stealer infostealer was running. It dumped process memory from CI/CD runners, harvesting SSH keys, AWS tokens, Kubernetes secrets, GitHub tokens, and API keys. Everything was encrypted and exfiltrated to attacker-controlled infrastructure before the pipeline job finished.
The incident was assigned CVE-2026-33634 with a CVSS score of 9.4.
March 23: Checkmarx KICS
Using credentials stolen from Trivy's victims, TeamPCP moved to their next target: Checkmarx. They hijacked GitHub Actions for both the KICS and AST repositories and deployed the same infostealer. Malicious VSCode extensions were published around the same window.
March 24: LiteLLM
LiteLLM is an open-source AI gateway — a proxy layer that sits between applications and LLM providers. Roughly 95 million monthly PyPI downloads. TeamPCP compromised it through poisoned package versions 1.82.7 and 1.82.8. Every developer who updated LiteLLM that day ran the stealer.
March 27: Telnyx Python SDK
The campaign reached Telnyx. Same playbook. Credentials from the previous wave used to move into the next target.
March 31: Cisco
Using credentials harvested from Trivy's victims weeks earlier, attackers accessed Cisco's internal build and development environment through a malicious GitHub Action plugin from the Trivy compromise. They moved laterally across dozens of devices — developer workstations, lab machines, build servers.
What they took:
- 300+ private GitHub repositories cloned — including source code for Cisco's AI Assistant, AI Defense, and other unreleased products
- Multiple AWS access keys stolen — used to perform unauthorized operations across a number of Cisco cloud accounts
- Customer repositories — a portion of the stolen repos reportedly belong to corporate customers, including banks, BPOs, and US government agencies
ShinyHunters: The Extortion Layer
On March 31, the same day the breach became public, extortion group ShinyHunters published a victim page for Cisco on the dark web with an April 3 deadline.
Their claim is significantly larger than what the Trivy-linked breach alone explains. They allege three separate access paths:
- Voice phishing (attributed to a group tracked as UNC6040)
- A Salesforce Aura vulnerability
- AWS account compromise
The Trivy-linked breach is confirmed and substantiated. The broader ShinyHunters claims are unverified — no dataset has been released, and the screenshots alone are not proof of the full scope. But the overlap in timing and the AWS access pattern make it plausible that these are connected incidents, not separate ones.
The Cisco CVE (Separate Issue)
One thing worth clarifying: the Cisco security advisory published April 1 — CVE-2026-20041, an SSRF vulnerability in Cisco Nexus Dashboard and Nexus Dashboard Insights — is unrelated to the TeamPCP breach. It was discovered through internal security testing and has a CVSS score of 6.1 (medium). Cisco has released fixed software. There are no workarounds.
If you run Nexus Dashboard or Nexus Dashboard Insights, patch it. But don't conflate it with the supply chain breach — they are separate incidents.
TeamPCP's Playbook
The pattern is now clear enough to name it:
Compromise one trusted dev tool
↓
Steal CI/CD credentials from every pipeline that runs it
↓
Use those credentials to compromise the next trusted tool
↓
Repeat
Each wave funded the next. Trivy gave them access to thousands of CI/CD environments. Those environments gave them Cisco. Cisco's repos and AWS keys give them whatever comes next.
TeamPCP is also tracked as PCPcat, DeadCatx3, and ShellForce. Security researchers believe they may be operating as an Initial Access Broker — systematically building a stockpile of stolen credentials and developer environment access, then selling downstream access to other threat actors.
Mandiant's CTO said explicitly after the axios attack that the secrets harvested from this campaign would fuel follow-on compromises — ransomware, crypto heists, SaaS environment breaches — over the coming weeks and months. The Cisco breach is consistent with exactly that.
The Connection to March 31
Here is where the previous story and this one become one story.
If you read the last post, you'll remember March 31 had three simultaneous hits — the Claude Code source leak, the axios RAT deployed by North Korean group UNC1069, and a dependency confusion attack targeting developers trying to compile the leaked source. At the time it looked like three unrelated incidents converging on the same bad day.
The Cisco breach reframes all of it. UNC1069's axios attack was a separate operation from TeamPCP's campaign — different actor, different tooling, different motivation. But both were active on the same day, in the same ecosystem, against overlapping victim pools.
Claude Code developers who updated via npm during the axios window may have pulled a RAT. Cisco developers who ran Trivy in their CI/CD pipeline on March 19 had their credentials silently stolen. LiteLLM users who updated on March 24 were also compromised.
These weren't coordinated. Three separate threat actors, operating independently, found different entry points into the same developer infrastructure over the same 12-day window.
The trust model that connects all of these: the assumption that tools doing security work are themselves secure.
Trivy scans for vulnerabilities. LiteLLM proxies your AI calls. Axios handles your HTTP requests. Claude Code writes your code. All of these were attack vectors in the same two-week period.
What's Happening Now
- The active Trivy distribution phase has been contained
- TeamPCP's C2 infrastructure for the axios-adjacent attacks is offline
- Cisco has contained the breach but expects continued fallout from downstream compromises
- ShinyHunters April 3 deadline has passed — no dataset released at time of writing
- Mandiant and Google GTIG are actively tracking both campaigns
- Rotate AWS keys, GitHub tokens, SSH keys, Kubernetes secrets
- Audit pipeline logs for the exposure window
- Check for outbound traffic to
sfrclak[.]com(axios C2) or unknown infrastructure
- If LiteLLM was affected, check for the
.pthfile injection mechanism in Python's site-packages
The Open Question
Cisco is not a small startup with an under-resourced security team. It is one of the largest networking infrastructure companies in the world. Network security is their product.
They ran a security scanner. The scanner had been compromised. Their pipeline executed it and everything looked normal.
That's not a failure of hygiene. That's a failure of the trust model.
The question I keep coming back to: if a tool specifically designed to make your pipeline safer can become the vector for a breach of this scale — without triggering a single alert — what does meaningful pipeline security actually look like?
Pinning dependencies helps. Network egress allowlisting helps. SLSA provenance helps. But none of those controls were specifically designed to handle a situation where the security tooling itself is the attack surface.
We're in territory where the standard advice — audit your dependencies, rotate your credentials, use lockfiles — is necessary but not sufficient. The attack surface is now the entire trusted toolchain. And that's a significantly harder problem than anything a checklist solves.
Previous post: Claude Leak → Axios RAT: The Supply Chain Story Nobody Connected
Written by Vishwam Dhavale
Full stack developer building scalable web & mobile systems. Founding Engineer with a passion for clean architecture and great DX.