In March 2026, attackers compromised the release pipeline of Trivy, a widely used open-source vulnerability scanner, distributing a credential stealer through official channels; the poisoned tool was auto-installed by LiteLLM’s build pipeline and used to publish compromised packages to PyPI, exposing roughly 2,500 organisations, including a confirmed breach at the European Commission.
The AI enemy within??
In March 2026, criminals took control of the release machinery behind Trivy, an open-source vulnerability scanner used inside more than ten thousand software build pipelines. For a matter of hours, anyone who asked for a legitimate, named version of that scanner received a credential stealer instead. It arrived through official channels, with no lookalike domain and no dodgy download link. Every organisation that got it did so by asking for the real thing.
The poison then flowed onward. LiteLLM’s build pipeline installed the scanner automatically, the attackers then used it to publish poisoned versions of that library to the public Python repository, where they sat for well under an hour before being pulled (this time is disputed).
By August, two threat intelligence firms had reconstructed the damage from the attackers’ own data. Between them they mapped exposure across roughly 2,500 organisations: cloud keys, SSH keys, database passwords, API tokens belonging to some of the largest companies on earth. One confirmed downstream victim is the European Commission, which lost several hundred gigabytes from a cloud account and saw it published on an extortion site within days.
Nobody was phished. No password was cracked. No firewall was breached.
Where the easy explanations fall short
It is tempting to file this under “AI security incident.” The AI angle is real but secondary. LiteLLM is where the damage concentrated, because AI gateways sit on top of every model provider key an organisation holds. But that explains where it hurt, not why it happened.
There is one genuine AI dimension worth naming honestly. The original break-in, weeks before the main event, was carried out by an autonomous agent methodically scanning public repositories for a specific build misconfiguration. AI changed the economics of finding the weakness, and it raised the value of what was sitting behind it. It did not change the weakness itself. That was a badly scoped token in an automated workflow, a problem the industry has understood for years.
It is equally tempting to file this under third party risk and leave it there. The problem is that most third-party processes are anchored to contracts, and this arrived without one.
Supplier management must cover SaaS and cloud products, not just the vendors who send invoices. Most organisations now accept that much. Fewer have extended the same logic one step further, to the open-source components engineers pull into build pipelines as a matter of course. Those components come with no contract, no questionnaire, no breach notification clause and no account manager to call, and they run with considerably more access than most formally assessed vendors ever receive.
It is worth being precise about what putting them on the register would have achieved. Due diligence would not have prevented this. Due diligence would not uncover a stolen token sitting inside a maintainer’s release automation (unless you are clairvoyant). What an accurate register buys you is the ability to respond, to answer, on the day it matters, which pipelines ran the affected tool, what those pipelines could reach, and therefore exactly what must be rotated. The conclusion is not that supplier management is beside the point. It is that the register must be comprehensive and include everything your people use.
So What’s Involved in Exception Management?
The Uncomfortable Truth
Strip away the AI framing and the supply chain framing and you are left with something plainer and more uncomfortable. A security scanner is, by design, one of the most privileged things in your environment. You cannot ask a tool to inspect everything and simultaneously hide everything from it. Give it a build pipeline to examine and it can read the cloud credentials, the repository access, the container registry keys and the database passwords that pipeline needs to do its job.
That is a higher level of trust than most organisations grant the cloud environment hosting their customer data. The PII environment is inspected, segmented, logged, access-reviewed and re-certified on a schedule. The scanner watching over it is installed once and never thought about again.
When the scanner became the attacker, it did not need to break anything. It read what it was already entitled to read and quietly forwarded it, then ran the legitimate scan it was supposed to run. From the outside, everything looked normal. Green ticks all round.
That is the whole story. Not novel technology. Not a sophisticated exploit. A category of software that carries maximum privilege and attracts minimum governance.
The Same Failure, Twice, from Two Directions
The gap shows up in two distinct places, and it is worth separating them, because it is easy to dismiss the first as somebody else’s problem.
Upstream as a maintainer, the compromise traces back to an earlier, smaller incident that was found, disclosed and handled, but not handled all the way. Credentials were rotated, but not all at once, leaving a window in which the attacker could capture the replacements using a key that was still valid. Containment was announced while the door was still open. Three weeks later, that gap cost thousands of organisations their secrets. Then it happened a second time, when access was re-established after the response was already underway.
Downstream as a consumer, every organisation that got hit did so through choices that are entirely ordinary and entirely optional. They referenced tooling by a version label that could be silently repointed, rather than by a fixed, verifiable identifier. They let build runners hold long-lived credentials with broad reach. They installed security tooling automatically from whatever version happened to be current.
Nobody in the second group could have prevented the first failure. All of them could have limited what it cost them.
What “treat it like the PII environment” actually means?
If your organisation applies real discipline to a cloud environment holding personal data, and most regulated organisations now do, you already have the model. The work is applying it one tier up, to the tooling that watches over everything else:
- Pin to something that cannot move – A version label is a pointer, not a guarantee. Reference security tooling by verified commit hash or artifact digest, the way you would insist on a known-good image rather than “latest” in production.
- Scope the access – A scanner needs to read the thing it is scanning. It rarely needs standing credentials for every cloud account, registry and cluster the pipeline touches. Least privilege is not a novel control here; it is simply one nobody applied.
- Shorten credential lifetimes – A stolen key does not expire because the news cycle moved on. It works until someone changes the lock. Credentials that live for minutes remove most of the value from the theft.
- Know what installed itself – Because a library can arrive as an invisible dependency of something else, “do we use it?” is the wrong question. “Did anything on this machine install it?” is the right one. Plenty of affected organisations answered the first honestly and were exposed anyway.
- Treat remediation as something you prove, not something you declare – This is the discipline point, and it is the one that generalises furthest beyond this incident. Rotation is not finished when the tickets close. It is finished when you can demonstrate that no pre-incident credential still works. Anything less is a containment status, not a containment outcome.
The Question for the Board
An advisory issued in July made the point that ought to concentrate minds: credentials harvested in March are expected to be weaponised long after the original break-in, and that expectation has already been borne out in follow-on extortion activity.
The question five months on is not whether you patched. Patching was never the exposure. It is whether your security tooling is governed with the same seriousness as the environments it protects, and whether, if you rotated back in March, you can prove the rotation finished.
Final Thoughts
Attack vectors and points of exposure can vary enormously, especially within this new age of AI, just as we are evolving and increasing our usage of AI so too are the global threat actors.
If you’d like to see how Morrisec can help your business continue to defend and bolster, reach out to our team or contact us at hello@morrisec.com.au.
Article compiled from various sources.
0 Comments