Security · 15 Aug 2026 · Rob Nidschelm

The Supply-Chain Attack Was Bigger Than the Package Everyone Blamed

The LiteLLM supply chain attack was not a single poisoned-package incident. It was a cascading compromise in which trusted security tooling, automated builds and stolen credentials turned one breach into a much wider exposure graph.

The first headlines focused on malicious LiteLLM packages that appeared on PyPI on 24 March 2026. Newer dataset analysis suggests that this was the closing stage of a campaign already collecting data through the compromised Trivy security scanner five days earlier.

That distinction changes the defensive lesson. The important question is not simply whether an organisation installed one bad package. It is which trusted tools ran inside its build environment, which secrets those tools could read and where those credentials could be used next.

Your security scanner became the supply-chain attack

The Trivy ecosystem compromise is tracked as CVE-2026-33634. Aqua Security has confirmed that attackers used compromised credentials on 19 March to publish a malicious Trivy v0.69.4 release, force-push 76 of 77 tags in aquasecurity/trivy-action and replace all seven tags in aquasecurity/setup-trivy. Malicious Trivy 0.69.5 and 0.69.6 container images were later pushed directly to Docker Hub.

The payload ran before the legitimate scan. It searched CI runners for SSH keys, cloud credentials, Kubernetes tokens, Docker configuration, database passwords, environment files and other secrets. It also scraped process memory, where CI systems may hold values that their logs are designed to mask.

LiteLLM has confirmed that its compromise originated in the Trivy incident and that an unpinned Trivy dependency was present in its CI/CD workflow. The attacker then published LiteLLM 1.82.7 and 1.82.8 to PyPI.

There is an important nuance in the final step. LiteLLM’s incident thread says the malicious packages bypassed its official GitHub release workflow and were uploaded directly using compromised PyPI publishing access. Aqua’s advisory and third-party analysis show how the Trivy stealer could harvest exactly that kind of token. The accounts therefore support the same broader sequence: the trusted scanner exposed credentials, and those credentials opened a downstream publishing route.

Version 1.82.7 embedded its payload in proxy_server.py. Version 1.82.8 added litellm_init.pth, which could execute when Python started even if an application never imported LiteLLM. That makes installation itself the dangerous event.

The 40-minute story is incomplete

SOCRadar’s August analysis examined 2,188 attributable organisation records from a reconstructed exposure dataset. It says 2,085 of those records, or 95%, showed collection activity before 24 March, when the poisoned LiteLLM packages were published. The earliest record was timestamped 18:05 UTC on 19 March, 18 minutes after the malicious Trivy build was published.

The same analysis counted platform data for 1,156 records:

• GitHub Actions: 496 organisations
• GitLab CI: 462
• Jenkins: 105
• Bitbucket: 77
• CircleCI: 15
• Buildkite: 1

CloudSEK separately reports a reconstructed exposure of more than 2,500 organisations and roughly 434,000 captured CI/CD files or pipelines. Both researchers stress that these are exposure estimates, not proof that every named organisation was successfully compromised or that every credential was used.

The package exposure window is also described differently. SOCRadar and CloudSEK put it at roughly 40 minutes before PyPI quarantine. LiteLLM’s own public update said the affected versions were live for eight hours before removal. Defenders should not choose the shortest figure. They should investigate the wider period, including cached artifacts and hosts where the .pth payload could continue running after the packages disappeared.

SOCRadar’s row-level timestamps add a persistence signal. Collection rose again on 22 and 23 March while malicious Trivy 0.69.5 and 0.69.6 images were live on Docker Hub. The dataset’s final record is timestamped 20:09 UTC on 24 March, roughly nine hours after PyPI quarantined the poisoned LiteLLM releases. This does not prove that every exposed credential was used, but it shows why removing the source package did not end collection on hosts where the startup payload was already running.

The stolen data entered a resale market

SOCRadar says its dark-web monitoring observed a broker advertising more than 150 GB of compressed data on Telegram, bundling material associated with LiteLLM, Trivy and CanisterWorm. The same reporting links the resale activity to the Vect ransomware ecosystem. These are attributed threat-intelligence findings, not independent proof that every advertised record is authentic or that every exposed credential was used. They are still operationally significant because copied credentials can remain valuable after the poisoned packages are removed.

Software supply chains are graphs, not chains

“Supply chain” suggests a neat line from one supplier to one customer. Modern software delivery does not work like that.

A security scanner can run in hundreds of repositories. One repository can publish several packages and container images. A package can arrive directly or through transitive dependencies. A CI runner can hold tokens for source control, cloud platforms, registries, Kubernetes clusters, databases, messaging services and AI providers at the same time.

That is a graph of trust relationships. Once attackers captured a token at one node, they could traverse an edge into another repository or registry, publish another poisoned artifact and create new edges into other environments. The result looks less like contaminating one shipment and more like compromising a junction.

This is why the stronger framing is: your security scanner became the supply-chain attack. Trivy was trusted precisely because it was a security control. That trust gave it execution inside privileged automation, where it could see more than the application it was meant to inspect.

BlackTree has argued that AI agents need better boundaries. The same principle applies to build tools. A scanner should not automatically inherit every secret available to a release job simply because it runs in that job.

It also reinforces a broader management lesson: security cannot rest on one gatekeeper. A trusted tool can fail, a maintainer token can be stolen and a version tag can move. Resilience comes from limiting what each node can reach and detecting when expected relationships change.

What is confirmed, and what is not

The Trivy compromise, the affected Trivy components, the poisoned LiteLLM versions and the credential-stealing behaviour are supported by vendor advisories and technical analysis. LiteLLM also said its official Proxy Docker deployment was not affected because that path used pinned dependencies.

The large scale figures need more care. The 2,188-record analysis, the 95% pre-PyPI timing and the six-platform distribution come from SOCRadar’s examination of a reconstructed dataset. The 2,500-plus organisation and 434,000 pipeline figures come from broader reconstructed exposure reporting. They are useful for understanding reach, but they are not a verified census of successful compromises.

Likewise, finding an organisation in an exposure dataset should trigger private validation, credential review and log investigation. It should not automatically be described as a confirmed breach.

What defenders should do now

Removing LiteLLM or updating Trivy is not enough if a secret was copied. The response has to follow the credentials and every system they could access.

• Identify any use of LiteLLM 1.82.7 or 1.82.8, including indirect installation through build images, cached layers and transitive dependencies.
• Audit Trivy exposure against Aqua’s detailed windows for v0.69.4, the affected GitHub Actions and Docker Hub images 0.69.5 and 0.69.6.
• Rotate every credential accessible to an affected runner or host. Include source-control, cloud, registry, Kubernetes, database, SaaS, messaging and AI provider secrets.
• Review GitHub, GitLab, PyPI, npm, container-registry, cloud and cluster audit logs for unexpected token use, new service accounts, package publication and release activity.
• Hunt for the fallback exfiltration repositories tpcp-docs and docs-tpcp, suspicious outbound connections and persistence artifacts on affected hosts.
• Rebuild runners, containers and caches from known-clean sources. Treat a system that executed the stealer as compromised, not merely outdated.
• Pin third-party actions to full commit hashes and packages or images to verified immutable versions or digests.
• Replace long-lived publishing tokens with short-lived workload identity or trusted publishing where possible.
• Separate scanning, testing and release jobs so a scanner does not share the credentials needed to publish production artifacts.
• Maintain an inventory that maps tools to the repositories, pipelines, secrets and release targets they can reach.

Aqua’s remediation guidance names known-safe versions for the incident window, including Trivy 0.69.2 or 0.69.3, trivy-action 0.35.0 and setup-trivy 0.2.6. Organisations responding now should move to a current verified release, but still use the advisory to determine whether malicious components ran during the March exposure windows.

The LiteLLM supply chain attack is a warning about misplaced confidence in linear controls. Pinning a dependency helps, but it is only one edge. The more durable defence is to make the graph visible, reduce the privileges at each node and assume that any trusted component can become untrusted without warning.

Sources and further reading

• Aqua Security: Trivy ecosystem supply chain temporarily compromised
• Aqua Security: Trivy supply-chain attack incident updates
• LiteLLM: PyPI package compromise timeline and status
• SOCRadar: LiteLLM supply chain attack and row-level dataset analysis
• CloudSEK: 2,500+ companies and 434,000 CI/CD pipelines potentially exposed
• CircleCI: Rotate credentials if LiteLLM ran in CI/CD pipelines
• GitHub: Secure use of third-party actions