CriticalSupply chainMonitoring

TeamPCP campaign (CVE-2026-33634): Trivy, KICS, LiteLLM and Telnyx turned into credential stealers

Poisoned Trivy and KICS actions and images, LiteLLM 1.82.7/1.82.8 and Telnyx 4.87.1/4.87.2 stole CI and developer secrets. Check, then rotate.

Published
Updated
Fixed in
trivy 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6, litellm 1.83.0, telnyx 4.87.0 (last clean)
Exploitation
Yes. CISA added CVE-2026-33634 to its Known Exploited Vulnerabilities catalogue on 26 March 2026

Live scores

CVE-2026-33634
EPSS
0.597
very likely to be attacked soon
VEDAS
0.973
strong exploit evidence
On CISA KEV
Yes, since 2026-03-26
Detection rule
None yet
EPSS (chance of attack)
100.1CVE-2026-33634 EPSS over time2026-082026-11-01
VEDAS (exploit evidence)
100.9CVE-2026-33634 VEDAS over time2026-082026-11-01

Thin horizontal line: the “likely” (EPSS 0.10) or “strong” (VEDAS 0.90) threshold. Shaded “no data” areas are periods when cve-scores did not publish.

What happened

A group known as TeamPCP took over the release channels of two security scanners and used the secrets it stole there to poison two popular Python packages. Unit 42 says the group is also tracked as PCPcat, ShellForce and DeadCatx3, and moved into supply-chain attacks in mid-March 2026 (Unit 42). Google tracks it as UNC6780 (Google Threat Intelligence).

  • Late February 2026: attackers abused a misconfiguration in Trivy’s GitHub Actions setup and took a privileged token. Aqua disclosed this and rotated credentials on 1 March, but the rotation was incomplete, so the attacker kept access (Aqua Security; Trivy advisory).
  • 19 March, Trivy: the attacker published a malicious Trivy v0.69.4, force-pushed 76 of 77 aquasecurity/trivy-action tags to malicious commits, and replaced all 7 aquasecurity/setup-trivy tags. The bad v0.69.4 went out through GitHub releases, Deb and RPM packages, GHCR, ECR Public, Docker Hub and get.trivy.dev (Trivy advisory).
  • 22 March, Trivy on Docker Hub: aquasec/trivy:0.69.5 and 0.69.6 were pushed straight to Docker Hub with separately stolen credentials. No matching GitHub releases exist (Trivy advisory).
  • 23 March, Checkmarx actions: the tags of Checkmarx/kics-github-action and Checkmarx/ast-github-action were rewritten. SANS ISC advises checking for ast-github-action runs between 12:58 and 19:16 UTC that day (SANS ISC; Datadog Security Labs). Datadog also lists the Open VSX extensions ast-results 2.53.0 and cx-dev-assist 1.7.0. Unit 42 dates this wave 21 March.
  • 24 March, LiteLLM: litellm 1.82.7 and 1.82.8 went live on PyPI at 10:39 UTC, for about 40 minutes, until PyPI quarantined them. LiteLLM believes the attacker got its publishing access through the Trivy step in its own CI. The official proxy Docker image ghcr.io/berriai/litellm was not affected (LiteLLM).
  • 27 March, Telnyx: telnyx 4.87.1 and 4.87.2 were published to PyPI from 03:51 UTC and quarantined by 10:13 UTC. The Telnyx platform itself was not compromised (Telnyx).
  • 22 April, KICS on Docker Hub: at about 12:35 UTC someone used valid Checkmarx publisher credentials to overwrite checkmarx/kics tags latest, v2.1.20, v2.1.20-debian, alpine and debian, and to create fake v2.1.21 and v2.1.21-debian tags (Docker). Socket found Checkmarx VS Code extensions poisoned the same day, and says TeamPCP “appears to be taking credit” (Socket).

The same group is linked to the May 2026 TanStack compromise that led to the GitHub breach. See our TanStack, Nx Console and GitHub advisory.

What the payloads did

  • Trivy actions: an infostealer in entrypoint.sh ran before the real scan. It read the GitHub runner’s process memory, searched more than 50 paths for SSH keys, cloud and Kubernetes credentials, Docker configs and .env files, encrypted the haul and sent it to scan.aquasecurtiy[.]org (note the misspelling). If that failed and a token was available, it created a public tpcp-docs repository and uploaded the data there (Trivy advisory).
  • LiteLLM: 1.82.7 hid its payload in litellm/proxy/proxy_server.py. 1.82.8 also added litellm_init.pth, which Python runs at every interpreter start, not only when you import LiteLLM. It sent data to models.litellm[.]cloud, persisted as ~/.config/sysmon/sysmon.py with a user systemd unit sysmon.service, and created privileged node-setup-* pods when it found a Kubernetes service-account token (Datadog Security Labs).
  • Telnyx: the code ran at import and pulled its second stage from a WAV file served by 83.142.209[.]203:8080 (Telnyx; Datadog Security Labs).
  • KICS images: scan output was encrypted and sent to audit.checkmarx[.]cx with the User-Agent KICS-Telemetry/2.0 (Docker).

Trivy exposure windows, in UTC, from the Trivy advisory:

ComponentBad versionsWindow (UTC)
trivy binary and imagesv0.69.419 Mar 18:22 to about 21:42
trivy-actiontags 0.0.1 to 0.34.219 Mar about 17:43 to 20 Mar about 05:40
setup-trivybelow 0.2.619 Mar about 17:43 to about 21:44
aquasec/trivy on Docker Hub0.69.5, 0.69.622 Mar 15:43 to 23 Mar about 01:40

Am I affected?

Start with your CI configuration and images:

bash
# Workflows that use the affected actions, and how they are pinned
grep -rniE 'aquasecurity/(trivy-action|setup-trivy)@|checkmarx/(kics-github-action|ast-github-action)@' .github/workflows

# Trivy and KICS images on this machine or runner, with digests
docker image ls --digests aquasec/trivy
docker image ls --digests checkmarx/kics

# The Trivy binary itself
trivy --version

A tag pin such as @0.34.2 or @v1 resolved to malicious code during the window. The advisory says even trivy-action SHA pins older than 9 April 2025 were affected. Compare any KICS digest against the list in Docker’s post.

Then check Python environments. Look for files first: any Python start, including pip, runs a .pth payload.

bash
# Payload and package metadata left on disk
find / -path '*site-packages*' \( -name 'litellm_init.pth' \
  -o -name 'litellm-1.82.[78].dist-info' -o -name 'telnyx-4.87.[12].dist-info' \) 2>/dev/null

# LiteLLM persistence
ls -la ~/.config/sysmon/sysmon.py ~/.config/systemd/user/sysmon.service /tmp/pglog 2>/dev/null

# Pinned versions in requirements and lockfiles
grep -rnE '^(litellm|telnyx)(\[[^]]*\])?==(1\.82\.[78]|4\.87\.[12])' --include='requirements*.txt' .
grep -nE -A1 'name = "(litellm|telnyx)"' poetry.lock uv.lock 2>/dev/null | grep -E '"(1\.82\.[78]|4\.87\.[12])"'

# Installed versions (this starts Python)
pip show litellm telnyx 2>/dev/null | grep -E '^(Name|Version)'

Finally, check GitHub and your clusters:

bash
# Exfiltration repositories created in your organisation
gh repo list YOUR_ORG --limit 1000 --json name --jq '.[] | select(.name | test("tpcp")) | .name'

# Pods the LiteLLM payload creates
kubectl get pods -A --no-headers | grep -E 'node-setup-'

Search DNS, proxy and egress logs for scan.aquasecurtiy.org, checkmarx.zone, models.litellm.cloud, audit.checkmarx.cx and 83.142.209.203. Any hit means data probably left.

What to do now

  1. Rotate everything the job or machine could read. That means the GITHUB_TOKEN scope and any personal access tokens, cloud keys, registry and package-publishing tokens, Kubernetes service-account tokens and SSH keys. Datadog warns that reverting the package alone is not a fix (Datadog Security Labs).
  2. Move to known-good versions. Trivy v0.69.2 or v0.69.3, trivy-action v0.35.0 and setup-trivy v0.2.6 (Trivy advisory). LiteLLM 1.83.0 or later (LiteLLM), but read our LiteLLM 1.107.0 advisory before picking a version. Telnyx 4.87.0 or a later clean release (Telnyx).
  3. Clean up the host. Remove litellm_init.pth, the sysmon files and the systemd unit, then rebuild the environment from a pinned lockfile. Delete any node-setup-* pods after you have captured them for investigation.
  4. Pin by SHA and digest. Reference actions by full commit SHA and images by @sha256: digest. Tags can be moved; digests cannot. Purge the bad KICS and Trivy digests from runner caches and registry mirrors.
  5. Starve the scanner of secrets. A scanner step needs read access to code, not your deploy keys. Run it in a job with no cloud credentials and a read-only GITHUB_TOKEN.
  6. Audit your own workflows. The way in was a misconfigured workflow in Trivy’s repository. Review any pull_request_target workflow that checks out fork code, and make credential rotation complete: list every token before you revoke, and confirm each one is dead.

Why this is part of the Vulnpocalypse

The tools teams added to cope with the flood of vulnerabilities became the way in. A security scanner runs on every push, with the pipeline’s secrets in reach, and few teams pin it. One incomplete rotation at one project cascaded into LiteLLM, Telnyx and, per later reporting, the TanStack and GitHub breaches. None of it needed a bug in your code. Treat your CI tools as production dependencies, because they hold production keys.

Sources