One leaked automation token. Three tools deep. Over 2,500 organisations across five continents exposed. That is the entire anatomy of 2026’s largest AI supply chain breach, and it took roughly forty minutes to happen.
How a Security Scanner Became the Weapon
In March 2026, a threat group tracked as TeamPCP compromised Trivy, a widely used open-source security scanner, through a leaked automation token. From there the attackers force-pushed malicious code into Trivy’s own version tags. When LiteLLM, a popular AI gateway that routes traffic between applications and model providers, pulled the poisoned scanner into its build pipeline, it published two compromised releases to PyPI, versions 1.82.7 and 1.82.8. A hidden file inside those packages executed automatically the moment Python started, no import required, harvesting cloud keys, repository tokens, SSH credentials, Kubernetes secrets and AI provider API keys from anyone who installed it. The malicious packages were live for roughly forty minutes before removal. That was enough.
A Genuinely Global Exposure List
CloudSEK’s analysis, later corroborated by an FBI advisory in July, identified more than 2,500 affected organisations and 434,000 exposed CI/CD pipelines. The named companies span the world rather than one region: AWS, Nvidia, Salesforce and Airbus’s US Space and Defense division from the US, Samsung Electronics and MediaTek from Asia, Siemens, Volkswagen and Munich Re from Germany, Thales and Orange from France, Roche from Switzerland, Philips from the Netherlands, Vodafone and the London Stock Exchange Group from the UK, and Thomson Reuters from Canada, alongside Cisco, FedEx, Deloitte and dozens more. This was never a story about one country’s technology sector. It was a demonstration of how deeply a single open-source dependency now sits underneath enterprise infrastructure everywhere.
The Same Argument, a Different Layer
This publication has already made the case that The September AI Outage Had Two Real Causes. Almost Everyone Reported One. LiteLLM extends that argument one layer deeper, into the software supply chain feeding the infrastructure itself. A vendor risk register that lists which cloud provider or model vendor an organisation depends on is no longer sufficient. It also needs to account for the open-source scanners, build tools and CI pipelines every one of those vendors quietly depends on, tools most procurement processes never ask about because nobody signed a contract for them.
What a PMO Should Actually Check
Three questions belong on every technology steering committee agenda this quarter. First, does anyone in the organisation maintain a current list of the open-source build and security tooling embedded in critical CI/CD pipelines, not just the paid vendors. Second, when was a leaked or rotated credential last tested as an actual incident scenario, rather than a line item in a policy document. Third, if a dependency three layers removed from a primary vendor were compromised tomorrow, how long would it take anyone to notice. The organisations named in the LiteLLM breach were not careless. They were exposed by a dependency most of them did not know they had, which is precisely the risk a vendor register built only around visible, contracted suppliers will always miss.