TeamPCP Campaign Timeline: From the Trivy Compromise to the LiteLLM Breach 

TeamPCP’s 2026 campaign shows why removing a malicious software artifact is not the same as containing a supply-chain compromise. Surviving identities, poisoned CI execution, and stolen publishing privileges gave TeamPCP routes into additional software-delivery environments, eventually reaching LiteLLM.

CloudSEK’s August 11 investigation connects those stages using evidence from more than 2,500 organizations and approximately 434,000 potentially exposed CI/CD pipelines. The reconstruction traces how compromised CI execution exposed secrets and publishing privileges, creating new paths into downstream software-delivery environments. CloudSEK distinguishes potential exposure from confirmed execution or credential theft, using the dataset to trace attack paths without inflating exposure into a victim count.

Combined with Aqua, LiteLLM, PyPA, NVD, CISA, and FBI disclosures, CloudSEK’s findings show how TeamPCP carried privileges from one software-delivery layer into another. Credentials remained usable after remediation, compromised CI jobs encountered additional secrets, and publishing identities opened new release paths. The same evidence also defines an important forensic boundary: investigators have reconstructed the Trivy-to-LiteLLM relationship, but the exact CI execution, credential, and PyPI authentication event connecting those stages have not been released publicly.

How Did TeamPCP Survive Trivy’s First Remediation?

TeamPCP remained inside Trivy’s release environment because the first remediation revoked known credentials without eliminating every compromised identity.

Trivy traced the initial credential theft to a vulnerable pull_request_target workflow abused on February 27. Organization- and repository-level secrets were exposed through that workflow, giving the intruder credentials tied to privileged automation.

Aqua’s chronology suggests that the March 19 activity was a continuation of the earlier compromise rather than a fresh intrusion:

• February 27: organization- and repository-level credentials were stolen through the vulnerable workflow.
• March 1: Trivy revoked credentials associated with automation identities investigators already knew were compromised.
• After March 1: activity continued through another affected user and token.
• March 19: the same token seen during the March 1 persistence period appeared again in malicious activity.

CloudSEK separately reconstructs an approximately 20-day window in which an automation token remained usable after rotation. The duration is a CloudSEK reconstruction rather than an independently verified forensic interval.

NIST’s NVD record for CVE-2026-33634 explains why rotation did not terminate the intrusion. Credentials were not invalidated simultaneously after March 1, leaving at least one identity usable while replacement secrets were being issued.

If a surviving identity could access newly rotated secrets, rotating individual tokens would not necessarily remove TeamPCP from the release environment.

Later findings point to a broader identity-containment problem rather than one forgotten token. On March 22, activity tied to a service account not previously considered compromised touched 43 repositories in another organization.

Trivy’s first remediation removed known credentials but left other automation identities usable across connected release workflows. The persistence therefore survived in valid identities and permissions not merely in the malicious artifact.

How Did the March 19 Trivy Compromise Turn CI/CD Pipelines Into Credential Sources?

Malicious Trivy code turned downstream CI/CD runners into credential-collection points, searching for secrets before the legitimate scanner executed.

CloudSEK found a 105-line malicious block inserted into the compromised workflow. Its collection logic ran first and then launched the expected Trivy scan, so a job could finish its normal security task after attacker-controlled code had already searched the runner for sensitive material.

The runner type determined what the injected code searched for.

GitHub-hosted runners were examined through process memory, where short-lived authentication material could be present during job execution. Self-hosted runners received a broader sweep covering at least seven categories:

• SSH keys
• cloud credentials
• Kubernetes tokens
• Docker configuration
• Terraform state
• Helm secrets
• cryptocurrency-wallet material

CI/CD runners were valuable because they already held credentials spanning repositories, cloud platforms, registries, deployment targets, and cluster infrastructure. TeamPCP therefore targeted the workflow where those identities were already present rather than attacking each credential store separately.

CloudSEK’s August 11 exposure table quantifies how much secret material appeared in a selected high-confidence sample. Across 35 organizations, the dataset records 16,131 aggregate runs and 8,844 aggregate “Secrets.” Thirty-one organizations recorded a non-zero Secrets count, or 88.6% of the sample.

These figures do not represent 8,844 confirmed stolen credentials, unique secrets, or verified exfiltration events. They are aggregate exposure fields in CloudSEK’s dataset and should not be equated with confirmed compromise.

Secret material nevertheless appeared across most organizations in the selected sample. Once the poisoned Trivy component ran inside those jobs, TeamPCP was executing beside credentials whose permissions extended beyond the runner itself.

Which Credentials Allowed the Campaign to Move Beyond Trivy?

Software-publishing credentials created the clearest route beyond Trivy because they authorized new artifacts under project identities users already trusted.

LiteLLM provides the clearest documented example. Its shared CircleCI environment exposed three classes of static release credentials: PyPI, GHCR, and Docker publishing. The compromised Trivy scanning step had visibility into those environment variables.

Not every exposed credential carried the same downstream consequence.

LiteLLM later saw two unauthorized PyPI releases, 1.82.7 and 1.82.8. PyPA’s advisory states that the malicious uploads followed API-token exposure from an exploited Trivy dependency. LiteLLM likewise says release credentials exposed through CI were subsequently used in its release path.

A separate Trivy incident shows the same form of privilege being abused through another registry. Aqua reported that leaked Docker Hub credentials were used to publish malicious Trivy images 0.69.5 and 0.69.6 directly to Docker Hub.

Publishing identities shortened the route from credential theft to downstream software distribution. A valid registry credential could let TeamPCP publish attacker-controlled software under an existing, trusted project identity.

Some stolen secrets therefore represented more than authentication material: they carried permission to create the next trusted software artifact.

What Can We Confirm About the Pivot From Trivy to LiteLLM?

Multiple public disclosures support the Trivy-to-LiteLLM relationship, but the exact CI job, stolen token, and PyPI authentication event remain unpublished. CloudSEK therefore treats this as a reconstructed attack path, not a claim of forensic certainty.

The observable timeline places the first suspicious Trivy activity on March 19 and the malicious LiteLLM v1.82.7 release on March 24 roughly 4 days and 17 hours apart.That interval establishes sequence, not credential dwell time. Public disclosures do not reveal when LiteLLM’s particular CircleCI job executed the affected Trivy component, when a release credential was first exposed, or when the attacker first authenticated with it.

LiteLLM’s own language shows how attribution confidence evolved. Its March 24 disclosure used deliberately cautious phrases including “We believe that the compromise originated from the Trivy dependency,” “Current evidence suggests,” “may have been compromised,” and “may be linked.”

By March 27, LiteLLM described its “present understanding” as a compromised Trivy package executing during a CI security scan, seeing environment variables, and exposing credentials subsequently used in the release path. Mandiant was still assisting with forensic analysis to confirm the source of the attack.

PyPA’s PYSEC-2026-2 advisory uses firmer language, describing the malicious LiteLLM releases as following API-token exposure from an exploited Trivy dependency. CloudSEK’s August reconstruction likewise connects the compromised scanner to LiteLLM’s build path.

Public material still lacks several artifacts required to close the chain at forensic granularity:

• the CircleCI job ID that executed the compromised Trivy component;
• a runner record showing the exact credential-read event;
• the specific token fingerprint later presented to PyPI;
• the upload source IP or user agent; and
• a registry authentication event tying the PyPI publication back to that token.

LiteLLM also reported no malicious code pushed to main, no effect on installation from its GitHub source repository, no impact on its official Proxy Docker image, and no evidence of lateral movement into internal corporate systems. Those negative findings place the incident around the CI/CD and release boundary, not in LiteLLM’s normal source tree.

Independent disclosures therefore support the Trivy-to-LiteLLM connection, but the exact sequence of specific Trivy execution → specific exposed credential → specific PyPI authentication event has not been released publicly.

What Changed When TeamPCP Reached LiteLLM?

LiteLLM widened TeamPCP’s potential execution surface: version 1.82.7 relied on malicious package code being reached, while 1.82.8 added a .pth file that could execute during Python startup.

1.82.7 depended on package code being reached

LiteLLM confirms that 1.82.7 contained malicious code inside:

litellm/proxy/proxy_server.py

PyPA’s package analysis points specifically to line 130 of the malicious wheel and describes execution occurring during package-module import.

Installation alone does not prove that 1.82.7 executed malicious code. Python still had to reach the affected package module.

1.82.8 changed the trigger

Version 1.82.8 retained the malicious proxy_server.py payload and added:

litellm_init.pth

In the affected environment, Python processed the .pth file during interpreter initialization. Execution no longer depended on an explicit LiteLLM import.

The execution difference was direct:

1.82.7: malicious package code had to be reached
1.82.8: Python startup became the payload trigger

The startup hook also exposed an implementation flaw

litellm_init.pth started another Python interpreter. That child processed the same .pth file, launched another interpreter, and repeated the cycle.

FutureSearch documented the recursive process creation as an unintended fork-bomb effect that crashed the machine where the malicious package was discovered. In that observed incident, the startup mechanism itself helped expose the compromise.

LiteLLM pushed execution beyond CI

CloudSEK notes that .pth startup execution extended the affected surface to local developer laptops, not only CI runners. FutureSearch provides a concrete example: 1.82.8 arrived transitively through an MCP plugin running inside Cursor.

Custom container builds formed another exposure path. LiteLLM warned that images built during the malicious window with an unpinned pip install litellm could have consumed the poisoned package. Its official Proxy image, ghcr.io/berriai/litellm, was unaffected because its dependency set did not pull the malicious versions.

Once the payload was executed, its behavior changed according to the environment. PyPA documents persistence through a Systemd service presented as “System Telemetry Service.” CloudSEK identifies the associated files as:

• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service

In Kubernetes environments, CloudSEK found logic designed to access secrets across namespaces and attempt privileged pod creation. PyPA independently confirms Kubernetes-specific pod creation behavior.

Those mechanisms existed in the payload, but public reporting does not establish successful persistence, credential exfiltration, or privileged pod creation in every affected installation.

LiteLLM marked more than another package compromise. TeamPCP moved from malicious code tied to LiteLLM package execution toward a Python-startup mechanism that brought developer workstations and other affected runtime environments into scope.

What Does the Timeline Reveal About TeamPCP’s Supply-Chain Strategy?

TeamPCP repeatedly changed technical routes while preserving the same strategic objective: inherit trust from legitimate software identities and use it to reach another distribution surface.

Trusted distribution mattered more than one delivery technique

Aqua’s chronology shows TeamPCP invoking Trivy’s legitimate GitHub Actions release workflow on March 19. Three days later, malicious Docker images were pushed directly to Docker Hub with leaked credentials rather than through the GitHub release path.

Different mechanics produced the same result: attacker-controlled software appeared through distribution infrastructure already trusted by downstream users.

The FBI’s July 2 FLASH broadens that behavior beyond Trivy. It names Trivy, KICS, LiteLLM, and the Telnyx Python SDK in connection with compromised trusted software distribution channels.

TeamPCP did not depend on one package manager, CI provider, or publication method. Trust in the legitimate publisher reduced the need to convince each downstream user to execute an unfamiliar artifact.

Valid identities outlived the original intrusion

Credentials obtained in one environment can remain valuable after the original artifact is removed, particularly when they retain access to repositories, registries, or release workflows.

Credential theft and package compromise form part of the same supply-chain pattern. A still-valid software-delivery identity preserved privileges after the first malicious artifact disappeared and could open another registry, repository, or release process.

Initial discovery may have been opportunistic; later behavior was more deliberate

Aqua adds an important qualification to the campaign narrative. Activity from the hackerbot-claw account on February 28 resembled an automated penetration-testing bot scanning GitHub for vulnerable projects. Its user agent and behavior differed from other events Aqua examined.

Public evidence does not prove that Trivy was selected from the outset as part of a fully preplanned TeamPCP operation.

Behavior after the initial credential exposure was more purposeful: persistence across identities, movement into adjacent repositories, use of legitimate release machinery, alternate registry publication, downstream secret collection, and later software poisoning.

Taken together, the evidence supports a recurring sequence:

discover a trusted software path → obtain the identity behind it → inherit its privileges → use an existing distribution channel → reach another trust domain

That sequence is an analytical synthesis of Aqua, FBI, LiteLLM, PyPA, and CloudSEK evidence rather than a formal TeamPCP doctrine attributed by any single source. It explains why the campaign continued to expand even as individual artifacts, tokens, and publication routes changed.

Conclusion

Viewed together, Trivy and LiteLLM reveal a campaign that repeatedly converted existing software trust into new privileges. The poisoned package was only one part of the attack path; the more durable advantage came from the identities, CI/CD permissions, and publishing privileges exposed along the way. A surviving Trivy identity outlasted the first remediation, malicious CI execution encountered additional secrets, and publishing privileges opened new distribution routes without requiring TeamPCP to breach every downstream project independently.

CloudSEK’s reconstruction clarifies how those stages connect while keeping potential exposure separate from confirmed malicious use. Removing the poisoned package addresses the artifact investigators can already see; effective containment also has to account for identities and release privileges that survive it. Those permissions may provide the starting point for the next compromise.