LiteLLM Supply Chain Attack: Inside the AI Breach That Exposed 2,500+ Companies

Key Takeaways

• New in this update: SOCRadar’s row-level analysis found that 95% of affected organizations were exposed before the well-known 40-minute PyPI window opened. That window marked the end of a five-day collection run, not the beginning.
• Background: The LiteLLM breach planted credential-stealing code in two PyPI releases, v1.82.7 and v1.82.8, live for roughly 40 minutes on March 24, 2026 before PyPI quarantined them.
• Potential exposure has been reconstructed across 2,500+ organizations and about 434,000 captured CI/CD files. These figures describe reconstructed exposure rather than a confirmed victim count.
• SOCRadar’s record-level analysis found that 95% of affected organizations were already exposed before March 24, when the packages went live. The 40 minutes on PyPI closed a collection run that had already been going for five days.
• Exposure spans six CI/CD platforms, skews European and Latin American by primary domain, and reaches payment, publishing, and communications keys well beyond the AI stack.
• The harvested data is already being brokered on Telegram, bundled with other TeamPCP stages and tied to a ransomware affiliate program.
• The malware swept cloud keys, SSH keys, Kubernetes tokens, database passwords, .env secrets, and AI provider keys, including OPENAI_API_KEY and ANTHROPIC_API_KEY.
• It is part of the wider TeamPCP campaign (Google: UNC6780) that first compromised the Trivy scanner. The ecosystem flaw is tracked as CVE-2026-33634, added to CISA’s KEV catalog on March 26.
• A .pth file ran at Python startup, so the payload executed even when nothing imported LiteLLM. An unpinned transitive dependency via DSPy, MLflow, CrewAI, OpenHands, or Arize Phoenix was enough.
• Response is credential-scoped. Removing the package does not contain it: rotate every secret any affected runner could reach and hunt for repositories named tpcp-docs or docs-tpcp.

New analysis published in August 2026 has overturned the original timeline of the LiteLLM supply chain attack. The well-known 40-minute PyPI window was not the beginning of the exposure. It was the final stage of a five-day collection run that started with the compromise of the Trivy scanner.

Record-level data now maps exposure across more than 2,500 organizations and roughly 434,000 captured CI/CD files. SOCRadar’s analysis found that 95% of affected organizations appeared in the dataset before the malicious LiteLLM packages were published on March 24.

Organizations did not need to install LiteLLM directly to be exposed. The package could arrive through frameworks such as DSPy, MLflow, CrewAI, OpenHands, and Arize Phoenix, while its payload executed at Python startup without requiring a LiteLLM import.

What is the LiteLLM supply chain attack?

The LiteLLM supply chain attack was a software supply chain compromise in which malicious releases v1.82.7 and v1.82.8 harvested cloud, SSH, Kubernetes, database, and AI provider credentials. Later analysis showed that the broader collection activity began days before the roughly 40-minute PyPI exposure window.

It is not a vulnerability in how you configured LiteLLM, and it is not a data breach of LiteLLM’s own servers. The project’s official Docker image and LiteLLM Cloud were never affected, because those deployment paths pin dependencies and did not pull the poisoned PyPI packages. Installs from the GitHub repository were also clean, since the repository itself was not compromised. The exposure landed on anyone who ran an unpinned pip install litellm during the window, whether directly, in a Docker build, or through a transitive dependency dragged in by an agent framework or orchestration tool.

Scale is what makes the window matter. LiteLLM is among the most widely deployed open-source LLM proxy gateways in the AI and ML ecosystem, at roughly 3.4 million downloads per day. Forty minutes of exposure on a package at that volume translates into hundreds of thousands of automated installs.

The compromised versions were removed from PyPI within the hour, and neither version appears in the package’s release history today, while 1.82.6 and 1.83.0 remain available. Removal did not end the incident. A copied credential stays usable until someone rotates it.

LiteLLM supply chain attack at a glance

How the Attack Actually Worked

Attackers hijacked the trusted Trivy security scanner in LiteLLM’s build pipeline, used it to publish two poisoned LiteLLM releases to PyPI, then relied on a Python startup file to run a credential stealer on every host that installed them.

LiteLLM was never attacked head-on. The compromise flowed downhill through three tools, from one credential that was rotated but not fully revoked.

The 13-minute gap between the two releases is the detail worth holding onto. The first version needed an application to import LiteLLM. The second did not.

1. Upstream: the Trivy scanner is hijacked

In late February 2026, an actor exploited a pull_request_target misconfiguration in Trivy’s GitHub Actions workflows and obtained a privileged personal access token. Although Aqua Security rotated the affected credentials, the rotation was not completed atomically, leaving residual access that TeamPCP later used to compromise Trivy’s release infrastructure.

The token was not stolen by TeamPCP. In late February, an autonomous agent called hackerbot-claw exploited a pull_request_target misconfiguration in Trivy’s GitHub Actions workflows and took a privileged personal access token. Aqua rotated credentials in response. In its own words, the containment was incomplete: the rotation was not atomic, and the attacker may have been privy to the refreshed tokens. Roughly three weeks later, TeamPCP used what survived.

On March 19 at 17:43 UTC it force-pushed 76 of 77 trivy-action tags and all seven setup-trivy tags to malicious commits, then triggered the release workflow to build and publish a malicious Trivy 0.69.4 four minutes later. The commits spoofed real maintainer identities. Downstream builds pulling those tags received poisoned code that still looked legitimate.

2. The poison reaches LiteLLM

LiteLLM’s CI pipeline installed Trivy unpinned from the system package manager, so the compromised scanner flowed into the build automatically, and that build produced and published the malicious 1.82.7 and 1.82.8 releases to PyPI. That is the chain that turns a single credential leak into ecosystem-wide exposure: Trivy, then the build system, then the release.

A point of genuine dispute. The primary accounts do not fully agree on how the packages reached PyPI. One account holds that the poisoned build published them. LiteLLM’s own incident report says the attacker bypassed official CI/CD workflows and uploaded directly to PyPI, with a maintainer’s PyPI account the suspected route, and TeamPCP publicly claimed responsibility. Unit 42 describes attackers targeting PyPI publishing tokens after the Trivy breach. These are best read as different stages of one attack chain rather than competing explanations: one covers how the credential was obtained, the others how it was used. PyPA’s advisory describes the same token-then-upload sequence.

3. Automatic execution, no import required

Version 1.82.7 carried its payload inside proxy_server.py. Version 1.82.8 went further and shipped a file named litellm_init.pth. Python processes .pth files at interpreter startup, so the payload ran whenever a Python process started in that environment, whether or not anything imported LiteLLM. That detail matters because it defeats the –ignore-scripts protection teams rely on, and it inverts the usual triage question. Whether your team knowingly uses LiteLLM matters less than whether anything on the host installed it.

4. Collection: everything the process could read

On each compromised host, the stealer (tracked by Google as SANDCLOCK) escalated to root and swept SSH keys, AWS, GCP, and Azure credentials read straight from the instance metadata service, local .aws/credentials and .kube/config files, Kubernetes tokens from mounted service-account paths, and .env and CI/CD secrets, including values GitHub Actions tries to mask, scraped from /proc/<pid>/mem.

5. Lateral movement inside Kubernetes

Where a Kubernetes service account token was present, the malware read cluster secrets across all namespaces, probed the internal API for pods and services, and attempted to schedule privileged alpine:latest pods on every node in kube-system, each mounting the host filesystem. This is the detail that turns a single poisoned runner into a cluster-wide event, and it is the reason containerized AI workloads carry more blast radius here than a developer laptop.

6. Exfiltration, persistence, and the GitHub fallback

The loot was sealed with AES-256-CBC under a hard-coded 4096-bit RSA public key and shipped to a typosquatted domain, with the exfiltration shaped to resemble ordinary telemetry traffic so it would pass as monitoring egress. Where exfiltration failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the stolen data as a release asset, so some organizations were leaking their own secrets into public view without knowing it. On the host, it installed a persistent backdoor at ~/.config/sysmon/sysmon.py (and /root/.config/sysmon/sysmon.py where root was available) registered as a systemd user service, polling for follow-on payloads.

How it was caught. The campaign was exposed by a bug. A fork bomb in the malicious payload spawned runaway processes on production systems, pegging CPU and triggering out-of-memory kills. Engineers chased the crash to the LiteLLM package. Without that defect, a stealer designed to run silently at interpreter startup would have had considerably longer than 40 minutes.

That GitHub fallback was not the only place the data surfaced. The stolen information was later advertised on Telegram and connected to underground ransomware activity.

Who Is TeamPCP?

The campaign is attributed to TeamPCP, a financially motivated group that specializes in compromising open-source security tooling and AI middleware. Google Threat Intelligence Group tracks it as UNC6780, and it is also tracked as PCPcat, ShellForce, and DeadCatx3. Documented waves through 2026 span Trivy, Checkmarx KICS, LiteLLM, the Telnyx Python SDK, Bitwarden CLI, TanStack, and Mistral AI, which makes LiteLLM one stage in a sustained campaign rather than an isolated incident.

BerriAI engaged Google’s Mandiant to run forensics on the build and publishing chain. Infrastructure analysis places both command-and-control nodes on the same bulletproof hosting provider, with TLS fingerprinting consistent with the AdaptixC2 framework. Reported links between that toolkit and a ransomware affiliate rest on infrastructure overlap, so treat the toolkit identification as solid and the wider actor relationships as moderate confidence.

What Credentials and Secrets Were Stolen?

The malware targeted every credential class a build host or developer machine typically holds: cloud keys, source-control tokens, package-publishing credentials, Kubernetes secrets, application secrets, and AI provider API keys.

What matters is what the affected process could read. The package name is secondary. LiteLLM commonly runs close to model providers, application services, and deployment systems, and in CI/CD the same host often holds credentials for source control, cloud infrastructure, registries, and production.

Credential classes at risk and their downstream consequence

Unit 42’s analysis records the payload reading environment variables that hold model API keys, specifically OPENAI_API_KEY and ANTHROPIC_API_KEY, the credentials to an organization’s entire AI stack. That is the part that makes this more than a routine PyPI incident. It is the first large-scale demonstration that compromising an AI control point exposes the identities and systems clustered around it.

The downstream reach is already documented. CERT-EU assessed with high confidence that a European Commission AWS account was compromised through the Trivy stage of the same campaign, with roughly 91.7 GB of compressed data exfiltrated.

Which Organizations Appear in the Exposure Dataset?

The reconstructed dataset lists 2,500+ organizations of every size and sector, with named high-confidence matches including NVIDIA, Cisco, Volkswagen, Deloitte, FedEx, Siemens, and X Corp. These are potential-exposure matches rather than confirmed compromises.

This is the number to handle carefully. Published reporting is explicit that the totals are not a victim count: the underlying material came from confidential intelligence sources and consists of captured loot and log files assessed as belonging to the campaign, rather than data gathered from the named organizations. A high-confidence match asserts whose systems a captured file came from, keyed on host identity and legitimate committer domains. It does not assert that any credential was used. Reported totals vary slightly depending on how captured files are attributed, and figures may be revised as organizations validate their own data, so treat the scale as an order of magnitude rather than a fixed count.

“Secrets” below is the count of exposed secrets in the supplied dataset. “Runs” is the count of pipeline runs. Sorted by secrets exposed.

Selected high-confidence organizations in the exposure dataset

Excerpt of the selected high-confidence organizations included in the reported dataset. Rows with zero secrets but many runs indicate pipeline activity matched to the organization without secret values in the captured sample.

What New Analysis Reveals About the Exposure

Most coverage of this incident works from the ranked company list. The underlying dataset carries per-organization fields that almost nobody has reported on: first- and last-seen timestamps, credential-type breakdowns, CI/CD platform, primary domain, and a confidence rating. SOCRadar analyzed those records at the row level. Every figure below comes from the 2,188 organization records in that set.

1. The “40-minute” incident was the last act of a five-day collection window

This is the finding that reframes the story. Every record carries first-seen and last-seen timestamps. The earliest is March 19 at 18:05 UTC and the latest is March 24 at 20:09 UTC, a span of just over five days. More pointedly, 2,085 of the 2,188 organizations, or 95%, show collection activity before March 24, the day the poisoned LiteLLM packages reached PyPI.

That timing lines up with the upstream Trivy compromise rather than the LiteLLM install window. The 40 minutes everyone reported was the closing act, not the whole play.

The timestamps pin it more precisely than that. Aqua Security’s own advisory puts the malicious Trivy tag force-push at 17:43 UTC on March 19 and the poisoned build at 17:47. The earliest collection record in the dataset is 18:05, eighteen minutes after that build published. Collection begins with the Trivy stage, not the LiteLLM one.

The same alignment holds at both ends of the window. The March 22 and March 23 uptick tracks the period when malicious Trivy images 0.69.5 and 0.69.6 were live on Docker Hub, from 15:43 UTC on March 22 until their removal at 01:40 on March 23. And the final record at 20:09 UTC on March 24 sits roughly nine hours after PyPI quarantined the packages, which is what persistence on already-infected hosts looks like: the .pth payload kept running after the source of the infection was gone.

2. Six CI/CD systems were hit, so this was never a GitHub problem

The instinct after a CI/CD breach is to blame one platform. The data does not allow it. Exposure spans six distinct systems, with GitHub Actions and GitLab CI in roughly equal measure, and self-hosted GitLab well represented, meaning on-premise pipelines were not spared. The counts below cover the 1,156 records that carry a platform value.

3. The footprint skewed European and Latin American

Grouping affected organizations by their primary domain’s country code gives a footprint that is not US-centric. Germany leads every country-code domain, ahead of Brazil and France, with a long European tail behind them. The set spans 137 distinct TLDs and includes eight .gov domains.

Country code is a proxy for headquarters rather than a geolocation. A .com organization can sit anywhere, and generic domains are excluded here because they carry no region signal. The concentration among European and Latin American domains is still a clear pattern.

4. It swept payment, publishing, and communications keys, not just AI keys

The credential mix is the part that should concern engineering leaders. Alongside the JWTs and private keys sit package-publishing tokens for npm and Docker, Stripe payment keys, and Twilio and SendGrid communication keys. One poisoned build reached across an organization’s entire secret estate.

Publishing tokens are the ones that turn a victim into a vector. Any organization whose npm or Docker credentials sat on an affected runner should treat its own downstream artifacts as suspect.

5. The biggest secret count is not the biggest compromise

The extremes make a vivid headline and a misleading one. The highest secret count in the set is roughly 3,477, from an organization that does not appear in the named excerpt above, followed by roughly 3,459. Several high-secret rows rest on very few files or repositories. One row carries 3,459 secrets across just six files, and some are rated low confidence. A large secret count can mean one verbose environment dump rather than deep access.

The more useful signal is scale of human identity. Committer email addresses appear for more than 1,100 organizations, which means real developer identities were captured alongside machine tokens, not just anonymous runner credentials.

On methodology and confidence. Of the 2,188 organizations in the record-level set, 56% are rated high confidence, 39% medium, and 6% low, with figures rounded. Headline reporting cites 2,500+ organizations; the difference reflects which records carry attributable identifiers. High-confidence matches are keyed on CI host identity and legitimate committer domains, meaning whose systems a captured file came from, rather than any observed use of a stolen credential. These are exposure figures rather than confirmed compromises, drawn from a reconstructed sample rather than a complete census.

The stolen data is already being brokered

The FBI’s warning that harvested credentials would be weaponized later is not hypothetical. SOCRadar’s Dark Web monitoring observed a broker advertising the campaign’s output for sale on Telegram, offering a bundle of LiteLLM, Trivy, and CanisterWorm data at over 150 GB compressed.

Two details make this worth attention. The bundle spans three distinct stages of the same campaign, which is consistent with a single actor’s collection rather than opportunistic resale of someone else’s leak. And the advertised volume is in line with the compressed size of the exfiltrated corpus described in public reporting, roughly 153 GB compressed against about 340 GB uncompressed, which suggests the seller holds the collection itself rather than a scraped subset.

A BreachForums-linked account announced the forum’s partnership with the Vect ransomware operation, extending affiliate panel access to forum users and pointing to Vect’s own statement on its involvement with TeamPCP in the LiteLLM compromise. The alignment between Vect and TeamPCP was announced in late March 2026 and formalized on BreachForums on April 16, with affiliate keys distributed to forum members two days later. SOCRadar has profiled Vect separately in its Dark Web Profile: Vect Ransomware.

This is the monetization path that makes rotation urgent regardless of what your logs show. Credentials harvested in March were being packaged for resale within weeks, and the buyer at the end of that chain is a ransomware affiliate with a panel and an incentive to use them. Sophos has since confirmed at least one Vect deployment that used TeamPCP-sourced credentials, and victims on Vect’s leak site carry labels tying them to the LiteLLM and Trivy campaign.

How Do I Check If My Company Was Affected?

Check whether LiteLLM 1.82.7 or 1.82.8 ran on any host or CI runner during the March 24, 2026 window (10:39 to 16:00 UTC), search package manager caches for litellm_init.pth, search your source-control organization for repositories named tpcp-docs or docs-tpcp, and look for the file-level and network indicators below.

Run all five checks. A clean result on one does not clear the others.

Check whether LiteLLM is even in your stack

Start here, because this is the step most teams skip. LiteLLM is a transitive dependency of DSPy, MLflow, CrewAI, OpenHands, and Arize Phoenix, among other AI frameworks, so it can sit in an environment nobody deliberately installed it into. Run the version check below even if your team has never used an AI gateway, and read lockfiles and CI job logs from March 24 for the two versions rather than trusting a dependency list written from memory.

Check installed and cached versions

On any host, confirm the running version, rule out the malicious releases, and purge caches so a poisoned wheel cannot be reinstalled:

# On a host or in a container
pip show litellm

# Look for the interpreter-startup payload in site-packages
find /usr/lib/python3.13/site-packages/ -name "litellm_init.pth"

# And in package manager caches (uv caches survive rebuilds)
find ~/.cache/uv -name "litellm_init.pth"pip cache purge 

# Persistence check
ls -la ~/.config/sysmon/ /root/.config/sysmon/ 2>/dev/null
systemctl --user list-units "sysmon*"

Scan CI/CD at scale

LiteLLM’s official incident report provides community-contributed scanners for checking GitHub Actions and GitLab CI jobs for installations of versions 1.82.7 and 1.82.8. Configure the scanners to cover the March 24, 2026 incident window and review the scripts before running them.

Look for indicators of compromise (IoCs)

LiteLLM breach indicators of compromise

Check your Dark Web and public exposure

Because credentials from this campaign are already circulating on the dark web, a version check alone is incomplete. Search for leaked credentials, source code, and CI/CD artifacts associated with your organization and its suppliers.

What should I do if my organization was exposed?

Assume credential exposure first, then use evidence to narrow scope. Rotate every secret any affected process could reach, rebuild affected environments from clean sources, and hunt for the campaign’s persistence artifacts.

Do not wait for proof before rotating. A lack of obvious malicious activity is not evidence that a credential was left alone. For any secret with production reach, the cost of rotation is far lower than the cost of delayed containment. This is also the FBI’s guidance in FLASH-20260702-01: rotate CI/CD secrets, publishing tokens, and cloud credentials accessible during the exposure windows.

• Identify and isolate: Find any use of LiteLLM 1.82.7 or 1.82.8 and the affected build windows. Isolate affected runners, hosts, images, and cached layers so a poisoned artifact cannot keep propagating.
• Rotate broadly, not narrowly: Rotating only the LiteLLM or model-provider key is insufficient. Any credential readable by the affected process, including cloud, repository, registry, Kubernetes, SaaS, database, and AI keys, plus anything in process memory or reachable via IMDS, should be treated as exposed until validated.
• Rebuild from known-clean sources: Rebuild affected environments rather than cleaning in place. Pin LiteLLM to 1.82.6 or earlier, or to a verified 1.83.0+ release, and verify Docker image signatures with cosign against the project’s published key.
• Hunt for persistence and downstream use: Search source control for tpcp-docs and docs-tpcp repositories, check for the sysmon.py backdoor and its systemd unit, and review cloud, source-control, registry, and cluster audit logs for token use from an unusual IP, geography, or runner after the exposure window.
• Close the second-generation risk: If any package-publishing credential was reachable, treat downstream artifacts as suspect too. The whole point of this campaign was turning one stolen token into the next supply chain compromise.

How to prevent the next AI supply chain breach

Pin dependencies and GitHub Actions to verified hashes, shorten credential lifetime and scope, prefer workload identity over static keys, and continuously inventory the AI assets and dependencies that now sit at the center of your estate.

These controls apply whether or not you appear in the dataset. The LiteLLM breach is a preview of where attacks are heading rather than a one-off.

Pin everything, trust nothing unpinned

The entire chain rode on unpinned installs. Trivy pulled unpinned into LiteLLM’s CI, and LiteLLM pulled unpinned into victims’ builds. Pin dependencies and CI actions to verified hashes. Floating tags are not a control, and a .pth payload that runs at interpreter startup will bypass install-time script protections, so pinning is the control that actually holds.

Move off long-lived static credentials

A static cloud key, SSH key, or publishing token copied during the window stays usable until it is rotated. Shorten credential lifetime and scope, and prefer workload identity over static keys so a copied secret expires on its own.

Treat the AI layer as high-value infrastructure

AI gateways, agent runtimes, MCP servers, and vector stores are becoming the rail junctions of digital operations. They hold credentials for models, databases, and internal tools, they sit on a wide dependency graph, and agentic workflows can act, which widens the blast radius of any stolen access. Conventional attack-surface tools see endpoints and ports while missing model, agent, and workflow context. Inventory these assets and their owners, and monitor CI/CD runtime behavior and third-party AI dependencies continuously.

Why this one matters beyond the victim list. The LiteLLM breach was more than a software supply chain attack that happened to involve an AI product. It showed that compromising an AI control point exposes the identities and systems around it. The next wave will target the AI layer precisely because it is now connected to everything else.

How Can SOCRadar Help?

Incidents like the LiteLLM breach are only partly a patching problem. The exposure that matters sits in third-party code you did not write, in pipelines that run without human review, and in credentials that keep working long after the malicious package is gone. SOCRadar’s Extended Threat Intelligence (XTI) platform covers that gap:

• Supply Chain Intelligence: Monitor vendors, open-source dependencies, and technology providers for compromise, and get alerted when a supplier in your ecosystem appears in a breach or extortion claim before the impact reaches your pipelines.
• Attack Surface Management: Maintain a live inventory of internet-facing assets, technologies, and their owners, including the AI gateways, agent runtimes, and orchestration services that conventional asset tooling misses.
• Dark Web Monitoring: Detect leaked credentials, tokens, source code, and internal documents tied to your organization and its suppliers, which is where harvested CI/CD secrets from campaigns like this one surface for resale.
• Vulnerability Intelligence: Track CVE-2026-33634 and other KEV-listed flaws against the technologies you actually run, with exploitation signals and prioritization instead of raw CVSS.
• Threat Actor Intelligence: Follow TeamPCP (UNC6780) tooling, infrastructure, and campaign evolution in a single profile view, with alerting on new activity that touches your monitored assets.
• IOC Radar: Correlate this campaign’s infrastructure and detect reuse of the same domains, hashes, and indicators in follow-on activity.

Start your free trial

Frequently asked questions

Which LiteLLM versions are compromised?

Versions 1.82.7 and 1.82.8 are the confirmed malicious releases. Version 1.82.6 and earlier, and verified 1.83.0 and later, are clean. Treat any install of LiteLLM on March 24, 2026 between 10:39 and 16:00 UTC as suspect.

Is LiteLLM safe to use now?

Yes, with pinning. The malicious versions were removed from PyPI within the hour and do not appear in the release history. From v1.83.0-nightly onward, LiteLLM Docker images published to GHCR are signed with cosign, so signatures can be verified against the project’s published key before deployment.

I never installed LiteLLM directly. Am I still at risk?

Possibly. The .pth payload executed at Python interpreter startup, so it did not need your code to import LiteLLM. LiteLLM is a transitive dependency of DSPy, MLflow, CrewAI, OpenHands, and Arize Phoenix, among others, so an unpinned install pulled in by one of those during the window was enough.

Does appearing in the exposure dataset mean we were breached?

No. A high-confidence match indicates that a captured file is assessed as originating from your systems. It does not establish that any credential was used. It is a reason to rotate and investigate rather than a confirmed compromise.

Who is behind the LiteLLM supply chain attack?

The activity is attributed to TeamPCP, tracked by Google Threat Intelligence Group as UNC6780 and also known as PCPcat, ShellForce, and DeadCatx3. Google identifies its credential stealer as SANDCLOCK. The wider campaign affected Trivy, Checkmarx KICS, and other software supply chain targets across PyPI, GitHub Actions, Docker Hub, npm, and Open VSX.

Is This Related to the LiteLLM RCE Vulnerability (CVE-2026-48710)?

No, that’s a separate issue. In June 2026, researchers reported a distinct LiteLLM vulnerability (CVE-2026-48710, alongside CVE-2026-42271) involving a Starlette Host Header bypass that let attackers skip authentication and run remote commands. It’s unrelated to the TeamPCP supply chain campaign covered in this article, but if you run LiteLLM, it’s worth checking both. See the full technical breakdown and indicators of compromise in SOCRadar’s IOC Radar report link.

References

1. LiteLLM (BerriAI), “Security Update: Suspected Supply Chain Incident,” Mar. 24, 2026. 
2. The Hacker News, “Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations,” Aug. 12, 2026. 
3. SecurityWeek, “Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack,” Aug. 12, 2026. 
4. FBI, “Cyber Criminal Group TeamPCP,” FLASH-20260702-01, Jul. 2, 2026.
5. Unit 42 (Palo Alto Networks), “TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure,” Mar. 31, 2026.
6. Aqua Security, “Trivy Supply Chain Attack: What You Need to Know.”
7. NVD, “CVE-2026-33634” (CISA KEV, added Mar. 26, 2026).
8. CERT-EU advisory on Trivy supply chain compromise, Mar. 2026.
9. Aqua Security, “Trivy ecosystem supply chain temporarily compromised,” GHSA-69fq-xp46-6×23.
10. Google Threat Intelligence Group, UNC6780 and SANDCLOCK attribution, Apr. 2026.