Cisco Source Code Stolen in Trivy-Linked Breach as ShinyHunters Claims Multi-System Compromise
Cisco has reportedly suffered a cyberattack after threat actors used credentials stolen in the recent Trivy supply-chain compromise to breach the company’s internal development environment, steal source code, and perform unauthorized actions across a small number of AWS accounts. The incident, first reported by BleepingComputer, adds another major enterprise victim to the growing list of organizations hit by downstream fallout from the March wave of developer-toolchain attacks.
According to BleepingComputer, the breach was detected and contained by Cisco’s Unified Intelligence Center, CSIRT, and EOC teams after a malicious GitHub Action plugin linked to the Trivy compromise was used to steal credentials and data from the company’s build and development environment. The report says the intrusion affected dozens of devices, including some developer and lab workstations, and that Cisco has since isolated impacted systems, started reimaging them, and launched broad credential rotation.
The significance of the case goes beyond a routine enterprise breach. BleepingComputer says more than 300 GitHub repositories were allegedly cloned, including source code tied to Cisco’s AI-focused products such as AI Assistants, AI Defense, and unreleased offerings. A portion of the stolen repositories reportedly belonged not only to Cisco itself but also to corporate customers, including banks, BPOs, and U.S. government agencies. If accurate, that would turn the incident from a corporate development-environment breach into a broader third-party software exposure event.
The attack appears to fit the same broader pattern already seen across the Trivy, LiteLLM, and Checkmarx compromises. In Cisco’s case, the initial intrusion reportedly came from the month’s Trivy attack, in which threat actors compromised the project’s GitHub pipeline and distributed credential-stealing malware through official releases and GitHub Actions. BleepingComputer says the compromise enabled the theft of CI/CD secrets from organizations using Trivy, opening the door to internal build environments that were never directly exposed to the internet but were reachable through poisoned trust in the software pipeline.
That chaining effect is what makes this incident especially important. The Trivy compromise was not just about one tool. It was about using a trusted security product as a credential vacuum, then using each new set of stolen secrets to pivot into other development ecosystems. Cisco appears to be one of the most high-profile examples yet of how that playbook can translate into real enterprise damage: not a package hijack in isolation, but a full breach of internal engineering infrastructure. This is an inference based on the reported attack path and the broader TeamPCP-linked campaign.
There is also a second layer to the story now circulating on leak sites. A screenshot shared from ransomware.live attributes claims against Cisco to ShinyHunters and alleges three separate breaches involving UNC6040, Salesforce Aura, and AWS accounts, along with more than 3 million Salesforce records, GitHub repositories, and AWS buckets. At this stage, those claims should be treated carefully. They reflect an extortion-style actor posting alleged victim data and warnings, not independently verified facts. The more substantiated public reporting currently comes from BleepingComputer’s account of a Trivy-linked compromise in Cisco’s development environment. The ShinyHunters posting may represent threat-actor narrative, overlapping access, or an attempt to amplify pressure following the incident, but the available public sources do not yet verify all of those claims.
Another notable detail from BleepingComputer is that more than one threat actor may have been involved in the Cisco breaches, with varying degrees of activity across the CI/CD and AWS compromise paths. That possibility matters because it suggests the victim environment may have been touched by overlapping criminal operations after the initial secret theft, which is increasingly common in modern intrusion chains. Once credentials leak from one trusted build system, they may circulate across multiple actors, leading to layered access and more confusing attribution.
The cloud component is especially serious. BleepingComputer reports that multiple AWS keys were stolen and then used to perform unauthorized activity in a small number of Cisco AWS accounts. In many organizations, development and build environments sit close to artifact stores, cloud pipelines, model infrastructure, deployment credentials, and customer code. That means a compromise at the development layer can rapidly become a source-code, cloud, and downstream customer-data problem all at once. This is an inference based on the reported AWS key misuse and repository cloning.
From a defender’s perspective, the Cisco incident reinforces several uncomfortable truths. First, security tools inside CI/CD can become privileged attack paths if they are compromised upstream. Second, source-code exposure is no longer just a developer concern. It can reveal internal product roadmaps, cloud logic, secrets-handling patterns, customer implementations, and potential future weaknesses. Third, once multiple attackers begin exploiting the same stolen credential pool, incident response becomes less about one clean containment and more about wave-on-wave fallout. Those conclusions are analytical, but they are directly supported by the reported facts of the incident and the surrounding supply-chain campaign.
Cisco had not responded to BleepingComputer’s questions at the time of publication, so the full scope and the company’s official framing remain incomplete. But even from the current public details, the breach appears to be one of the clearest examples so far of how a supply-chain compromise in a trusted developer security tool can cascade into source-code theft inside a major technology vendor.
Reference Links and Sources
