Last updated: March 2026
Key Takeaways:
- Cisco's internal development environment was breached through the March 2026 Trivy supply chain attack. Attackers cloned more than 300 GitHub repositories, including source code for Cisco's AI-powered products and customer code belonging to banks, business process outsourcing firms, and US government agencies.
- The breach is the highest-profile confirmed casualty of the TeamPCP campaign that already compromised Trivy, Checkmarx KICS, and LiteLLM — confirming the cascading supply chain failure that security researchers warned about is actively unfolding.
- Whether you run Cisco networking equipment at home or manage CI/CD pipelines professionally, there are concrete steps you should take now — from auditing your development environment to strengthening your home network with open-source, locally controlled infrastructure.
On March 31, 2026, BleepingComputer reported that Cisco suffered a significant cyberattack traced directly to the Trivy vulnerability scanner supply chain compromise that began on March 19. Threat actors used credentials stolen through the compromised Trivy GitHub Actions to breach Cisco's internal build and development environment, exfiltrate source code, and access a small number of the company's AWS accounts.
This is not an isolated incident. It is the latest and most consequential domino to fall in a coordinated supply chain campaign carried out by a threat group known as TeamPCP. If you have been following our coverage of the LiteLLM supply chain attack, this is the next chapter in the same story — and it now involves one of the largest networking infrastructure companies in the world.
What Happened to Cisco
The Breach Timeline
The attack chain that ultimately reached Cisco started weeks earlier. In late February 2026, an autonomous bot called hackerbot-claw exploited a misconfigured GitHub Actions workflow in Aqua Security's Trivy project to steal a privileged access token. Aqua Security discovered the theft and rotated credentials, but the rotation was incomplete. TeamPCP retained access.
On March 19, the group used surviving credentials to force-push malicious commits to 76 of 77 version tags in Trivy's GitHub Action repositories. Any CI/CD pipeline that ran Trivy that day silently executed credential-stealing malware alongside the normal vulnerability scan. The pipelines appeared to complete successfully. Nothing looked wrong. But underneath, the "TeamPCP Cloud Stealer" was dumping process memory from CI/CD runners, harvesting SSH keys, cloud credentials, Kubernetes tokens, and API keys, then encrypting the haul with AES-256 and RSA-4096 before exfiltrating it to attacker-controlled infrastructure.
Cisco's development pipelines used Trivy for security scanning. When those pipelines ran the compromised action, TeamPCP harvested the credentials needed to access Cisco's internal environment. According to sources who spoke with BleepingComputer, Cisco's Unified Intelligence Center, CSIRT, and Emergency Operations Center teams contained the breach, but not before significant damage was done.
| Date | Event | Impact |
|---|---|---|
| Late Feb 2026 | hackerbot-claw steals Trivy PAT via misconfigured GitHub Actions workflow | Initial credential theft; incomplete rotation leaves door open |
| March 19 | TeamPCP force-pushes malicious commits to 76/77 Trivy Action version tags | Thousands of CI/CD pipelines worldwide begin executing credential-stealing malware |
| March 19 | Malicious Trivy binary (v0.69.4) published to GitHub Releases, Docker Hub, GHCR, ECR | Developer workstations running Trivy locally are also compromised |
| March 20 | CanisterWorm detected on npm; 47+ packages compromised via stolen publish tokens | Self-propagating worm spreads across JavaScript developer infrastructure |
| March 23 | TeamPCP pivots to Checkmarx KICS and AST GitHub Actions | Second security scanning tool weaponized using credentials stolen from first wave |
| March 24 | LiteLLM versions 1.82.7 and 1.82.8 published to PyPI with credential-stealing payload | AI infrastructure gateway compromised; PyPI quarantines within ~3 hours |
| March 31 | Cisco breach disclosed; 300+ GitHub repos cloned, AWS keys stolen | Source code for AI products and customer repos exfiltrated; incident response ongoing |
What Was Stolen
The scope of the Cisco breach is substantial. According to BleepingComputer's reporting, attackers cloned more than 300 GitHub repositories from Cisco's internal environment. The stolen code includes source code for several of Cisco's AI-powered products:
- AI Assistants — Cisco's AI-driven support and automation tools
- AI Defense — Cisco's network-level AI security product designed to protect enterprise AI deployments
- Unreleased products — Code for products not yet publicly announced
Beyond Cisco's own repositories, a portion of the stolen code reportedly belongs to corporate customers. The affected organizations include banks, business process outsourcing firms, and US government agencies. Multiple sources told BleepingComputer that more than one threat actor was involved in the Cisco CI/CD and AWS account breaches, with varying degrees of activity.
As part of the breach, multiple AWS access keys were stolen and used to perform unauthorized activities across a small number of Cisco's AWS accounts. Cisco has isolated affected systems, begun reimaging compromised devices (including developer and lab workstations), and is performing wide-scale credential rotation. The company expects continued fallout from the follow-on LiteLLM and Checkmarx supply chain attacks.
| Category | Details | Risk |
|---|---|---|
| AI product source code | AI Assistants, AI Defense, unreleased products | Vulnerability discovery, targeted exploits against Cisco security products |
| Customer repositories | Banks, BPOs, US government agencies | Downstream supply chain attacks, targeted compromise of customer infrastructure |
| AWS credentials | Keys used for unauthorized access to Cisco AWS accounts | Cloud infrastructure compromise, data exfiltration, lateral movement |
| Developer workstations | Dozens of devices impacted, including lab systems | Persistent access, additional credential harvesting, code tampering |
BleepingComputer contacted Cisco with questions regarding the breach but had not received a reply at the time of publication.
How the Trivy Supply Chain Attack Made This Possible
The Cisco breach did not happen because of a flaw in Cisco's own security practices in isolation. It happened because a widely trusted open-source security tool was turned into a weapon.
Trivy, developed by Aqua Security, is one of the most popular vulnerability scanners in the cloud-native ecosystem. It is embedded in thousands of CI/CD pipelines across every industry, running automatically on every pull request, every merge, every deployment. It runs with access to pipeline secrets by design — that is how it functions. When TeamPCP compromised Trivy, they did not just get code. They got the keys to everything those pipelines could touch.
We covered the full technical breakdown of how this attack unfolded — and what it means for anyone running local AI infrastructure — in our detailed analysis of the LiteLLM supply chain attack. That article covers the mechanics of the TeamPCP Cloud Stealer, the CanisterWorm npm propagation, and the specific steps to audit your Python environment for compromise. If you have not read it yet, start there for the technical foundation.
The short version: TeamPCP exploited an incomplete credential rotation after an earlier Trivy incident to regain access to Trivy's release infrastructure. They then force-pushed malicious code to nearly every version tag of Trivy's GitHub Actions, meaning any pipeline referencing those actions by tag (which is how most organizations configure them) automatically executed the attacker's code on the next run. The malicious payload harvested secrets from CI/CD runner process memory, cleaned up after itself, and then ran the legitimate Trivy scan so everything appeared normal.
From those stolen credentials, the attack cascaded outward. Stolen npm tokens fed a self-propagating worm that compromised over 47 npm packages. Stolen PyPI credentials enabled the publication of malicious LiteLLM versions. And stolen CI/CD secrets from organizations like Cisco gave attackers direct access to internal development environments and cloud infrastructure.
Why Security Tools Are the Most Dangerous Attack Surface
There is a painful irony at the center of this story. The organizations most likely to be compromised were the ones doing the right thing — running automated security scans on every build. The more diligently you scanned, the more times the malicious payload executed in your environment.
Security tools run with elevated privileges by design. A vulnerability scanner needs access to source code, container images, dependencies, and often cloud credentials to do its job. Compromising a security tool gives an attacker access to exactly the environments that organizations work hardest to protect. As Microsoft's Faisal Hussain noted in the aftermath of the Trivy compromise, security tools are granted broad access because that is how they function — and that makes them the highest-value targets in the software supply chain.
This is not a theoretical risk anymore. Cisco, one of the largest and most security-capable companies on Earth, was breached through exactly this vector. The SANS Institute has described the TeamPCP campaign as the most consequential CI/CD supply chain attack since SolarWinds. The pattern is clear: breach a security tool, use the stolen credentials to breach the next tool in the chain, use those credentials to breach the organizations that trusted both tools. Repeat.
Why This Matters for Your Home Network
Cisco Firmware and Equipment Implications
Cisco manufactures networking equipment that runs in millions of homes and businesses worldwide — routers, switches, firewalls, wireless access points, and security appliances. When attackers steal source code for a company's security products, the immediate concern is whether that code reveals exploitable vulnerabilities.
To be clear: there is no evidence that Cisco's shipping firmware or consumer products have been directly compromised by this breach. The attack targeted the development environment, not the production firmware distribution pipeline. But source code theft is a precursor, not an endpoint. Attackers with access to the source code for Cisco AI Defense and other security products can study that code at their leisure to find vulnerabilities that they can later exploit against deployed systems.
The stolen customer repositories add another layer of concern. If code belonging to banks, government agencies, and enterprise clients was exfiltrated alongside Cisco's own code, downstream attacks targeting those organizations become more feasible. The full scope of what was taken has not been publicly disclosed, and Cisco's investigation is ongoing.
For anyone running Cisco networking equipment, the practical advice is straightforward: monitor Cisco's security advisories closely in the coming weeks and months, apply firmware updates promptly when they are released, and do not assume that this breach will have no downstream consequences just because no consumer-facing impact has been confirmed yet.
The Case for Open-Source and Local-First Infrastructure
This breach reinforces a principle we have been building toward across ModemGuides: the more you depend on a single vendor's proprietary, opaque stack for your network security, the more you inherit that vendor's entire attack surface — including risks you cannot see, audit, or control.
When Cisco's development environment was compromised, no one outside Cisco had visibility into the problem until BleepingComputer's reporting broke the story. Compare this with the Trivy compromise itself: because Trivy is open-source, the security community was able to identify the malicious commits, trace the attack chain, and publish detailed technical analyses within hours. Open-source security tools can still be compromised (Trivy proves that), but the community's ability to detect, analyze, and respond to the compromise is fundamentally different.
This is the same principle that applies to your home network. Open-source router firmware like OpenWrt and pfSense gives you auditable code, community-driven security patches, and control over your own network behavior in ways that no proprietary vendor firmware can match. If a vulnerability is discovered in OpenWrt, the patch history is public. If a vulnerability is discovered in a proprietary Cisco firmware image, you wait for the vendor to acknowledge it and release a fix on their timeline.
For local AI deployments, the lesson from the LiteLLM compromise is equally relevant. Routing your AI workloads through a multi-provider cloud gateway like LiteLLM creates a centralized point of trust that, when compromised, exposes every API key and model provider in your stack. Running models locally through tools like Ollama on dedicated hardware you control eliminates that dependency entirely. Your data never leaves your network, and a supply chain attack on a PyPI package cannot steal credentials for services you are not using.
Layer in DNS-level monitoring with a tool like Pi-hole, and you gain passive visibility into what every device on your network is actually doing. If a compromised tool starts making unexpected DNS queries to unfamiliar domains, you will see it in the Pi-hole dashboard. On stock firmware with no DNS visibility, that same activity would be completely invisible.
Network isolation through VLANs — achievable with pfSense or OpenWrt — means that if a single device on your network is compromised, the attacker cannot pivot to your personal computers, NAS, or other sensitive systems. Segment your IoT devices, your AI server, and your workstations onto separate network segments, and a breach of one does not automatically become a breach of all.
None of this makes you invulnerable. But it makes you less dependent on any single vendor's security posture, and it gives you the tools to see and respond to problems that proprietary firmware keeps hidden. That is the practical meaning of digital sovereignty — controlling the infrastructure you depend on, rather than trusting someone else to control it for you.
What You Should Do Now
For Developers and IT Professionals
If your organization uses Trivy, Checkmarx KICS, or LiteLLM in any CI/CD pipeline, treat all secrets accessible to those pipelines between March 19 and March 24 as compromised. This is not precautionary — it is the guidance from Microsoft, Wiz Research, SANS, and every major security vendor that has analyzed this campaign. Specifically:
-
Audit CI/CD pipeline logs from March 19 through March 24 for any references to
tpcp.tar.gz,aquasecuritydomains, orcheckmarx.zonein runner logs. -
Search your GitHub organization for repositories named
tpcp-docs. This repository name is the TeamPCP Cloud Stealer's fallback exfiltration method — its presence means secrets were successfully stolen from your environment. - Rotate every secret accessible to affected pipelines: GitHub tokens, cloud provider credentials (AWS, GCP, Azure), SSH keys, Docker registry tokens, Kubernetes secrets, database passwords, and API keys.
-
Pin all GitHub Actions to full commit SHAs going forward. Mutable version tags (like
@v2or@v0.35.0) can be force-pushed to point at arbitrary commits. Commit SHAs cannot. This attack proved at scale that tag-based pinning is not safe. - Implement a 7 to 14 day cooldown before adopting new package versions. Automated scanning services from firms like Socket, Aikido, and Snyk monitor package registries continuously and typically flag malicious packages within days. A one-week waiting period lets those systems catch problems before they reach your infrastructure.
- Update to safe versions immediately if you have not already: Trivy binary v0.69.3 or earlier, trivy-action v0.35.0 (commit 57a97c7), setup-trivy v0.2.6 (commit 3fb12ec).
For Home and Small Business Network Operators
The Cisco breach does not require immediate action for most home users, but it is a strong signal to reduce your dependency on any single vendor's security:
- Monitor Cisco's security advisories at sec.cloudapps.cisco.com for any downstream firmware or product updates related to this breach. If you run Cisco equipment, apply patches promptly when released.
- Consider open-source firmware for your router. Our open-source firmware comparison guide covers OpenWrt, FreshTomato, and pfSense to help you find the right fit for your hardware and skill level.
- Set up DNS-level monitoring with Pi-hole to gain visibility into what your network devices are actually communicating with. This is especially valuable if you run any IoT devices, smart home systems, or local AI services.
- Isolate devices on separate network segments using VLANs if your router supports them. Keep IoT devices, AI servers, and personal workstations on separate segments so a compromise of one does not cascade to the rest.
- Use encrypted DNS providers like Quad9 (9.9.9.9) or Cloudflare (1.1.1.1) configured at the router level, and route your traffic through a trusted VPN like Proton VPN or Mullvad VPN for an additional layer of privacy.
Frequently Asked Questions
Was my Cisco router or modem directly affected by this breach?
There is no evidence that Cisco's shipping firmware or consumer networking products were directly compromised. The breach targeted Cisco's internal development environment — specifically their CI/CD pipelines and GitHub repositories. However, the theft of source code for Cisco's AI and security products means vulnerabilities could be discovered and exploited in the future. Monitor Cisco's security advisories for updates.
What is a supply chain attack and why is it so dangerous?
A supply chain attack compromises a trusted tool or dependency that other organizations rely on, rather than attacking those organizations directly. In this case, TeamPCP compromised Trivy (a security scanner used by thousands of companies) and used the credentials stolen from Trivy's users to breach downstream targets like Cisco. Supply chain attacks are especially dangerous because the compromised tool is trusted by design — security scanners, build tools, and package managers are granted access to the most sensitive parts of an organization's infrastructure.
What is TeamPCP and what else have they compromised?
TeamPCP (also tracked as DeadCatx3, PCPcat, ShellForce, and CipherForce) is a threat group that has been conducting a coordinated campaign against open-source developer tools and security infrastructure since late February 2026. Their confirmed targets include Aqua Security's Trivy vulnerability scanner, Checkmarx's KICS and AST GitHub Actions, the LiteLLM AI gateway on PyPI, over 47 npm packages via their self-propagating CanisterWorm, and now Cisco's development environment. The campaign uses a novel command-and-control infrastructure built on the Internet Computer Protocol (ICP) blockchain, which is resistant to traditional takedown methods.
How do I know if my development environment was affected by the Trivy compromise?
Search your GitHub organization for any repository named tpcp-docs — its presence indicates successful credential exfiltration by the TeamPCP Cloud Stealer. Review CI/CD pipeline logs from March 19 through March 24 for references to tpcp.tar.gz, any aquasecurity domain variations, or checkmarx.zone. If you used Trivy binary version v0.69.4, trivy-action with any tag other than v0.35.0 pinned to commit SHA 57a97c7, or LiteLLM versions 1.82.7 or 1.82.8, treat your environment as compromised and rotate all accessible secrets immediately.
Does open-source firmware protect against supply chain attacks?
Open-source firmware does not make you immune to supply chain attacks — the Trivy compromise itself proves that open-source tools can be weaponized. However, open-source firmware provides a fundamentally different trust model. Because the code is publicly auditable, compromises are discoverable by the community rather than hidden behind a proprietary vendor's walls. OpenWrt, FreshTomato, and pfSense all have their source code publicly available, which means security researchers can (and do) inspect changes for malicious code. Proprietary firmware gives you no such visibility. Our open-source firmware guide covers the specific privacy and security benefits of each option.
What should I do if I used LiteLLM versions 1.82.7 or 1.82.8?
Treat your environment as fully compromised. The malicious LiteLLM versions deployed a persistent backdoor using a Python .pth file that executes automatically on any Python interpreter startup — meaning every python, pip, or pytest command would trigger the credential stealer. Immediately roll back to LiteLLM version 1.82.6 or earlier, search your Python site-packages directories for any file named litellm_init.pth and remove it, rotate all API keys and cloud credentials accessible to the affected environment, and review our full LiteLLM supply chain attack analysis for detailed remediation steps.
Will Cisco release a patch or advisory related to this breach?
Cisco has not yet publicly commented on the breach beyond what BleepingComputer has reported through anonymous sources. The company's CSIRT and Emergency Operations Center teams have contained the initial incident, and Cisco is performing wide-scale credential rotation and system reimaging internally. Whether this breach results in security advisories for Cisco's shipping products will depend on what the stolen source code reveals and whether attackers used their access to tamper with production code. Monitor Cisco's official security advisories page for any updates.
