Trivy, Not LiteLLM Behind the 2,500 Org Compromise

1. Executive summary

A supply-chain compromise originating in Aqua Security's Trivy scanner — not the LiteLLM PyPI package as initially reported — affected approximately 2,188 organisations across six CI/CD platforms between 19–24 March 2026. The threat actor "TeamPCP" (attribution unconfirmed — no MITRE profile resolved in verified reference data) deployed worm-like malware via a Python .pth persistence mechanism that auto-executed at interpreter startup, harvesting cloud keys, SSH keys, Kubernetes tokens, database passwords, JWT/auth tokens, and API keys. SOCRadar analysis confirms 95% of affected organisations (2,085 of 2,188) were compromised via Trivy before the two malicious LiteLLM packages were published on 24 March. The stolen dataset of ~434,000 files is now being brokered, exposing committer email addresses at over 1,100 organisations alongside machine tokens — giving attackers both developer identities and CI/CD access. EMEA financial services with GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI, or Buildkite pipelines active in the affected window should assume potential credential exposure.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 19: reporting of major ICT-related incidents to competent authorities	Stolen CI/CD credentials, cloud keys, and API tokens at financial entities constitute a major ICT-related incident with potential for operational disruption and data compromise.	If your organisation is within the affected set, assess against your major-incident classification thresholds and prepare authority notification if thresholds are met.
DORA Art. 28: ICT third-party risk — general principles	The compromise propagated through a third-party security tool (Trivy) and an open-source dependency (LiteLLM), both consumed via package registries.	Review third-party/registry intake controls; the attack vector — a trusted scanner distributing worm-like credential theft — challenges assumptions about security-tooling supply chains.
NIS2 Art. 21(2)(d): supply chain security measures	The attack chain exploited automated CI/CD dependency resolution and a security tool's distribution channel to propagate across organisations.	Validate that supply-chain security measures account for security tooling as a threat vector, not just a control; review build-pipeline secret exposure.

3. Technical analysis & attack chain

Confirmed attack chain (corroborated by SOCRadar, CloudSEK, and Hudson Rock)

Initial compromise — Trivy scanner. Aqua Security's Trivy scanner was compromised by threat actor "TeamPCP" (attribution unconfirmed — no MITRE profile in verified reference data). Malicious Trivy builds were published to Docker Hub on 19 March 2026 at ~18:05 UTC. The earliest credential collection occurred 18 minutes after publication.
Worm-like propagation. The malware used stolen developer secrets to modify accessible packages and push malicious versions to registries, expanding the attack surface. This is the "Shai-Hulud worm" pattern attributed to TeamPCP. Malicious code auto-executed when an infected package was fetched and run.
Credential harvesting on infected CI/CD hosts. The malware targeted secrets broadly across CI/CD environments. Affected platforms: GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI, and Buildkite. Collection surged 22–23 March when malicious Trivy images were live on Docker Hub.
Downstream propagation to LiteLLM. LiteLLM was compromised via the Trivy infection chain. Two poisoned LiteLLM package versions were published to PyPI on 24 March and remained available for ~40 minutes before PyPI quarantined them.
Persistence via .pth file. The LiteLLM packages were injected with a .pth file that Python automatically executes at interpreter startup — even if LiteLLM was never imported. This bypassed ignore-scripts protections. SOCRadar notes this is why credential collection continued on already-infected hosts after the source of infection was removed.
Data collection and brokering. The attackers captured ~434,000 files. The dataset maps per-organisation records including timestamps, credential types, CI/CD platforms, and domains. Collection window: 19 March 18:05 UTC – 24 March 20:09 UTC (~5 days). The stolen data is now being brokered.

Technical specifics

Persistence mechanism: Python .pth file injection — auto-executed by the Python interpreter at startup regardless of whether the package is imported; bypasses --ignore-scripts / pip's script execution controls.
Secret types harvested: Cloud keys (AWS access keys), SSH keys, Kubernetes tokens, database passwords, JWT/auth tokens, GitLab tokens, OpenAI API keys, Slack webhooks, GitHub Actions tokens, Google API keys, private keys.
Committer email compromise: Over 1,100 organisations had committer email addresses compromised, giving attackers both developer identities and machine tokens.
Geographic distribution: Germany, Brazil, and France most affected.
Confidence ratings in dataset: 56% high confidence (keyed on CI host identity and legitimate committer domains), 39% medium, 6% low.
Highest secret count per org: ~3,477 secrets (one organisation); ~3,459 secrets across just six files in another.

Single-sourced claims — confidence caveat: The per-organisation dataset analysis (2,188 entities, timestamps, credential breakdown) is single-sourced from SOCRadar. The ~434,000-file dataset was obtained by CloudSEK. The 2,500+ organisation figure originates from CloudSEK and Hudson Rock. The discrepancy between 2,188 and 2,500+ reflects which records carry attributable identifiers. Verify before enforcement if acting on specific organisation counts.

4. Mitigation & containment

P1 — within 24 hours

Assume credential exposure. If your organisation ran Trivy from Docker Hub or installed LiteLLM from PyPI between 19–24 March 2026, treat all secrets accessible from those CI/CD environments as compromised. Rotate: AWS access keys, SSH keys, Kubernetes tokens, database passwords, JWT/auth tokens, GitLab tokens, OpenAI API keys, Slack webhooks, GitHub Actions tokens, Google API keys, and any private keys present in those environments.
Revoke and reissue CI/CD tokens. Rotate tokens for GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI, and Buildkite if those platforms were active in the window.
Audit committer accounts. For organisations with compromised committer emails (1,100+ in the dataset), review git commit history and account activity for anomalous commits or unauthorised package modifications. Enable MFA on all developer accounts if not already enforced.
Search for .pth persistence. Scan Python site-packages directories for unexpected .pth files. On Linux: find / -name "*.pth" -path "*/site-packages/*" 2>/dev/null. On macOS: find /Library/Frameworks/Python.framework -name "*.pth" 2>/dev/null and user-level ~/Library/Python/*/lib/python/site-packages/. Any .pth file containing executable code (not just import path additions) is suspicious.

P2 — within 72 hours

Pin and verify Trivy. If using Trivy, pin to a known-clean version from before 19 March 2026 or pull from Aqua Security's official distribution with signature verification. Remove any Trivy images pulled from Docker Hub during 19–24 March.
Review PyPI install logs. Check pip/uv/poetry install logs and CI/CD build logs for LiteLLM package installations on 24 March 2026. The malicious versions were live for ~40 minutes.
Implement build-time secret scanning. Deploy secret scanning in CI/CD pipelines to detect exposed credentials before they reach build artefacts. Tools: gitleaks, trufflehog, or equivalent.
Review package registry access. Audit which service accounts and tokens have publish rights to internal package registries and external registries (PyPI, Docker Hub). Revoke unused or overly broad tokens.

P3 — within 7 days

Enforce .pth file controls. Where feasible, restrict write access to Python site-packages directories in CI/CD build environments. Consider using PYTHONSAFEPATH=1 or virtual environment isolation to limit .pth execution scope.
Implement dependency pinning. Pin all dependencies to specific versions with hash verification (pip install --require-hashes). This prevents automatic installation of newly published malicious versions.
Review supply-chain security tooling as a threat vector. Security tools with broad system access (scanners, SAST/DAST agents) are high-value targets. Apply the same supply-chain scrutiny to security tooling as to any other dependency: verify signatures, pin versions, monitor for anomalous behaviour.

5. Indicators of compromise

No atomic indicators of compromise (hashes, domains, IPs, file names) are available in the source material. The sources describe the attack mechanism and impact but do not publish specific IOCs.

Behavioural indicators

Behaviour	Where to observe	Confidence
Unexpected `.pth` files in Python site-packages directories containing executable code	Host filesystem; EDR file-write monitoring on site-packages paths	High — confirmed mechanism
Credential collection activity from CI/CD build environments between 19–24 March 2026	CI/CD build logs; EDR process monitoring on build agents	High — confirmed timeframe
Trivy image pulls from Docker Hub between 19–24 March 2026	Container registry pull logs; Docker Hub audit logs	High — confirmed vector
LiteLLM package installation from PyPI on 24 March 2026	pip/uv/poetry install logs; PyPI download logs	High — confirmed vector
Outbound network connections from build agents to unknown endpoints during package fetch/run	Network firewall logs; EDR network monitoring	Medium — consistent with exfiltration but no C2 IOCs published
Anomalous package modifications or publishes using stolen committer credentials	Package registry audit logs; git commit history	High — confirmed propagation method

6. Detection

Insufficient indicators to author detection rules. The sources describe the attack mechanism (.pth persistence, credential harvesting) but do not publish specific file names, file hashes, command-line strings, mutex names, registry keys, C2 domains, or other artefacts suitable for YARA or Sigma rule construction.

7. Sources

SecurityWeek — "Trivy, Not LiteLLM Behind the 2,500 Org Compromise" — https://www.securityweek.com/trivy-not-litellm-behind-the-2500-org-compromise/ — 2026-08-14
SecurityWeek — "Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack" — https://www.securityweek.com/over-2500-organizations-impacted-by-litellm-supply-chain-attack/ — 2026-08 (corpus reference)
The Hacker News — "Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations" — https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html — 2026-08 (corpus reference)

8. Adverse Trace position

This is a high-severity supply-chain compromise with confirmed impact on 2,188+ organisations, including heavy concentration in Germany and France — both major EMEA financial services markets. The attack is notable for three reasons: (1) it originated in a security tool (Trivy) rather than a typical dependency, challenging assumptions about trusted tooling; (2) the .pth persistence mechanism bypassed standard ignore-scripts protections, meaning organisations that believed they were protected were not; and (3) the stolen dataset combines committer identities with machine tokens, giving attackers persistent access paths that survive credential rotation if developer accounts are not also secured. Attribution to "TeamPCP" is unconfirmed — no MITRE profile was resolved in verified reference data. The per-organisation exposure data is single-sourced from SOCRadar; clients should verify their specific exposure against CI/CD logs from 19–24 March before acting on rotation decisions. We are monitoring for publication of atomic IOCs and will update this advisory if specific file hashes, C2 infrastructure, or package signatures become available. Immediate priority for EMEA financial services clients: determine whether Trivy or LiteLLM was present in any CI/CD pipeline during the affected window and rotate all exposed secrets accordingly.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.