Skip to content
HACKTECH
Supply chainReported Published 5 sources

TeamPCP campaign hijacks Trivy Action tags, then backdoors LiteLLM and Telnyx on PyPI

On 19 March 2026 an attacker using compromised credentials published a malicious Trivy v0.69.4 release, force-pushed 76 of 77 aquasecurity/trivy-action tags and replaced all seven setup-trivy tags with code that stole CI/CD secrets, according to Aqua's advisory and Datadog Security Labs. The Hacker News reported that the stealer identified itself as 'TeamPCP Cloud stealer', and Datadog linked later compromises of Checkmarx GitHub Actions on 23 March, LiteLLM 1.82.7 and 1.82.8 on 24 March and Telnyx 4.87.1 and 4.87.2 on 27 March to the same campaign. LiteLLM said it believes its compromise originated from the Trivy dependency used in its CI/CD security scanning workflow, and that initial evidence suggested the attacker bypassed its official CI/CD workflows and uploaded the malicious packages directly to PyPI.

  • TeamPCP
  • Trivy
  • GitHub Actions
  • PyPI
  • LiteLLM
  • Telnyx
  • Checkmarx
  • CVE-2026-33634
  • CI/CD
  • secrets theft
  • Kubernetes

What the sources report

  • 19 March 2026: a malicious trivy v0.69.4 was published, 76 of 77 aquasecurity/trivy-action tags were force-pushed to malicious commits and all seven aquasecurity/setup-trivy tags were replaced; Aqua's advisory GHSA-69fq-xp46-6x23 (CVE-2026-33634), published 21 March, puts the trivy-action exposure at about 17:43 UTC on 19 March to about 05:40 UTC on 20 March (Datadog, Aqua advisory).
  • Stolen data went to the lookalike domain scan.aquasecurtiy[.]org, with a public 'tpcp-docs' repository in the victim's GitHub account as fallback; the credential harvester self-identified as 'TeamPCP Cloud stealer' in its source code (Datadog, The Hacker News).
  • Aqua said the attackers abused a compromised credential and acknowledged incomplete containment of an earlier late-February/early-March incident, in which the 'hackerbot-claw' bot exploited a pull_request_target workflow to steal a personal access token; Aqua said its secret and token rotation 'wasn't atomic' (The Hacker News, Aqua advisory).
  • 22 March: the attacker pushed malicious aquasec/trivy:0.69.5 and 0.69.6 images straight to Docker Hub with separately compromised Docker Hub credentials, with no matching GitHub release and the same C2 domain as v0.69.4; Aqua's advisory puts their exposure at 15:43 UTC on 22 March to about 01:40 UTC on 23 March (Aqua advisory, Datadog).
  • 23 March: Checkmarx/kics-github-action, Checkmarx/ast-github-action and the OpenVSX extensions ast-results 2.53.0 and cx-dev-assist 1.7.0 were compromised; on 27 March telnyx 4.87.1 and 4.87.2 ran malicious code at import time and fetched a second-stage payload hidden in a WAV file (Datadog).
  • 24 March: litellm 1.82.7 carried a payload in proxy_server.py and 1.82.8 added litellm_init.pth, which runs at Python interpreter startup; the payload persisted via ~/.config/sysmon/sysmon.py and a user systemd unit, exfiltrated to models.litellm[.]cloud and could create privileged node-setup-* pods when it found a usable Kubernetes service-account token (Datadog, LiteLLM).
  • LiteLLM says the versions went live at 10:39 UTC and were quarantined by PyPI after about 40 minutes, uses a 10:39 to 16:00 UTC window in its affected-user guidance, engaged Google's Mandiant and released clean v1.83.0 on 30 March through a new CI/CD v2 pipeline; Google Threat Intelligence Group tracks TeamPCP as UNC6780 and names Trivy, Checkmarx and LiteLLM among the projects it poisoned (LiteLLM, GTIG).

What it means for your organisation

A vulnerability scanner running in CI had access to the same secrets as the build, and mutable version tags let one stolen credential repoint almost every pipeline that referenced trivy-action by tag. Aqua acknowledged that containment of an earlier incident was incomplete because its rotation was not atomic; rotation is finished only when every credential an attacker could have seen has been replaced. LiteLLM's belief that its PyPI compromise began with Trivy in its own CI shows how one CI breach can become a publishing breach for an unrelated project.

What we check

  • Inventory every third-party GitHub Action, including security scanners, and confirm each is pinned to a full commit SHA rather than a version tag.
  • Search registries, mirrors, CI caches and build hosts for trivy v0.69.4 binaries and images and the aquasec/trivy:0.69.5 and 0.69.6 Docker Hub images, including latest pulled during the exposure windows, and confirm scanner images are referenced by digest.
  • Map which secrets and token scopes are available to scan, lint and test jobs, and move publishing credentials into separate, gated jobs or trusted publishing.
  • Review pull_request_target workflows for any checkout or execution of fork code in a privileged context.
  • Hunt on build hosts and clusters for litellm_init.pth, ~/.config/sysmon/sysmon.py, node-setup-* pods, tpcp-docs repositories and egress to the campaign's lookalike domains.
  • After an incident, verify rotation by enumerating every credential reachable from affected runners, not only the ones known to be used.

Sources

Services that cover these checks

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works