Last week the security firm CloudSEK published an analysis of an attack that took place back in March. What is new is the scale: it potentially affected more than 2,500 organisations and roughly 434,000 CI/CD pipelines. The list includes Cisco, Siemens, Volkswagen, Airbus, Deloitte, Deutsche Bahn, Thales, Munich Re, Bosch, and Vodafone.

More interesting than the numbers, though, is how it happened. Not one of those companies was attacked directly. Neither was the library through which it reached them.

What happened

The target was LiteLLM, an open-source library that provides a unified interface to different AI models. It is widely used because it lets organisations switch providers without rewriting their application.

But nobody attacked LiteLLM. The chain was longer than that.

Step one. A group tracked as TeamPCP obtained an automation token belonging to the security scanner Trivy. The token leaked and was rotated, but not fully revoked. That left roughly a twenty-day window in which the attacker force-pushed malicious code over the scanner's already-published version tags. Anyone pulling that tag received malicious code that still looked entirely legitimate.

Step two. LiteLLM's build pipeline installed Trivy automatically from the system package manager, unpinned. The compromised scanner therefore flowed into the build on its own.

Step three. That build produced and published malicious versions 1.82.7 and 1.82.8 to PyPI.

One un-revoked token, three tools deep. That is the whole story.

Why forty minutes was enough

The malicious packages were available on PyPI for roughly forty minutes. That sounds like very little. It is not.

Automated build systems do not sleep or wait. Within those forty minutes the package was pulled by scheduled jobs, ephemeral runners, developer laptops, and caches. From there it kept spreading well after removal from the registry.

The malicious code also sidestepped the usual protection. Rather than using install scripts, which can be disabled with --ignore-scripts, it used a .pth file. That executes when the Python interpreter starts, not when the library is imported. Installation alone was sufficient. Nobody had to use the package.

What went out the door

The payload escalated to root and swept everything the process could reach:

Most of this required no exploit at all. It simply used the access the environment already carried.

The collected data was shipped to a typosquatted domain. And where exfiltration failed, the malware created a public repository inside the victim's own GitHub account and uploaded the stolen data there. Some organisations were publishing their own credentials without knowing it.

Removing the package does not end the incident

This is the single most important sentence of the case.

The package disappeared from the registry within forty minutes. The stolen credentials remained usable. On 2 July 2026 the FBI issued an advisory (FLASH-20260702-01) warning that affiliated actors are likely to weaponise the harvested credentials long after the original intrusion.

Sophos separately reported the same day that TeamPCP has partnered with a ransomware operation. Stolen access does not have to be used immediately, and it does not have to be used by whoever stole it.

Practically, this means rotating one key is not enough. You need to rotate everything the affected process could reach — cloud, repositories, registries, clusters, databases, SaaS, and model providers.

This is not an isolated case

It would be convenient to treat this as an exotic accident. It is not.

The same campaign also weaponised Checkmarx KICS. Two of the three entry vectors were therefore security tools. Zscaler, a security vendor, appears on the list of potentially exposed organisations.

The pattern goes back further. SolarWinds, Kaseya, 3CX, package attacks across npm and PyPI. What has changed is that the targets are no longer only management tools, but tools meant to provide security — and now the infrastructure around AI.

The logic is straightforward. Model gateways, agent runtimes, and connector servers hold credentials to models, databases, cloud services, and internal tools all at once. Whoever reaches that layer does not need to hunt systems one at a time.

Why the supply chain has to be addressed

The fundamental shift is in who you are actually trusting.

You are not just trusting your suppliers. You are trusting your suppliers' suppliers. LiteLLM chose Trivy. You chose LiteLLM. You had no visibility into the first decision and no way to influence it.

Three factors make this worse:

Automation amplifies a brief mistake. Manual installation would have caught a compromised package in a handful of cases. A build pipeline distributes it across the organisation in minutes.

Build environments hold broad privileges. To deploy, they need production access. Whoever controls the build does not need to break into production separately.

Visibility is missing. Most organisations cannot answer whether they ever had a specific version of a specific library installed. Without that answer, the incident cannot even be assessed.

What the CRA says about this

This is where regulation intersects the problem, and quite precisely.

From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities within 24 hours. If this happened to you and you had shipped it inside your product, you are the one reporting. We covered the detail in our article on CRA reporting.

From 11 December 2027, a software bill of materials (SBOM) becomes mandatory. That is not paperwork for auditors. It is precisely the thing that answers "did we ever run 1.82.7?" in minutes rather than in a week.

The CRA also requires due diligence when integrating third-party components. In other words, the law says choosing your dependencies is your responsibility, even when you did not write the code.

What to do in practice

Concrete measures, ordered by return on effort.

Pin your versions. Pin dependencies and pipeline actions to a verified hash, not a tag. A tag can be overwritten; a hash cannot. This single control would have stopped the entire chain described above.

Shorten credential lifetime. Replace static keys with short-lived workload identity. A stolen credential that expires in fifteen minutes is worth considerably less.

Narrow build permissions. A build job does not need access to every cloud account. Separate environments and limit what each step can see.

Maintain a component inventory. Start generating an SBOM automatically as part of the build. Tools like Syft and cdxgen handle it; SPDX and CycloneDX are the standard formats.

Monitor build environment behaviour. Unusual outbound traffic from a runner is a detectable signal. In this case it would have surfaced the compromise.

Rotate by reach, not by evidence. If you are unsure what was accessible, rotate broadly. The cost of rotation is almost always lower than the cost of delayed containment.

Ask your suppliers. How do they manage their own dependencies? Do they pin versions? Do they maintain an SBOM? How would they notify you if this happened to them? For key suppliers, this belongs in the contract.

What to take away

Securing your own code is now the smaller part of the problem. Most of what runs in your organisation was not written by you and will never be read by you. Secure development is therefore not primarily about how you write code, but about what you allow into it and what privileges it runs with.

That is exactly what DevSecOps means in practice, and exactly why the CRA will require it of manufacturers. We wrote more about the underlying principle in Security by Design.

And if you take only one thing from this case, make it this: a security tool is not automatically trustworthy simply because it is a security tool.

How we can help

The supply chain is awkward precisely because it cannot be solved by one control or one department. It cuts across architecture, development, procurement, contracts, and compliance. Organisations therefore tend not to know who owns it, and the topic gets deferred until something happens.

This is exactly the kind of cross-cutting problem we are built for.

We establish where you stand. Architecture review and assessment of your development and deployment pipeline. Where builds run, what privileges they hold, what gets installed unpinned, where the static keys are and who holds them. The output is not a list of findings but a plan with sequencing. → Security Assessment

We set up supplier governance. Risk-based categorisation, security requirements written into contracts, assessment of key suppliers, and periodic review. Including the questions to ask them and the evidence to require. → Security Technologies

We get risks out of spreadsheets. A risk and supplier register with owners, controls, and deadlines, plus reporting for leadership. Seven-day free trial. → Observa

We prepare you for the CRA. Determining whether you are a manufacturer under the regulation, standing up SBOM generation, building the 24-hour reporting process, and establishing a public vulnerability disclosure channel. The 11 September deadline is close. → Compliance, NIS2 and DORA

We take ownership when you lack the people. An external cybersecurity manager who runs this agenda long-term and is accountable for it — without having to find a senior hire on a market where there are none. → vCISO and Security Leadership

And if it has already happened. Scoping the exposure, prioritising credential rotation, forensic support, and regulatory communication. → Incident support

Large firms will send you a two-hundred-page report. We go through every line with you and stay until it is actually resolved.

Book a free consultation →

We will tell you plainly what is worth addressing first and what can wait. Free, no obligation, answer within 24 hours.