LiteLLM Supply Chain Attack: Healthcare AI Security

Case Study
April 9, 2026

Healthcare organizations are deploying AI faster than their security programs can keep up. Prior authorization automation, clinical documentation, revenue cycle optimization, claims processing, every implementation depends on open-source libraries that have access to cloud credentials, API keys, and in many cases, PHI.

The proposed HIPAA Security Rule recognizes this exposure. It proposes requiring written technology asset inventories, network segmentation, comprehensive logging, and documentation that controls are effective. The final rule is expected in May 2026 based on the current HHS regulatory agenda, with a 180–240 day compliance window.

On March 24, 2026, a supply chain attack demonstrated exactly why those requirements exist.

Editor’s Note: This case study is based on a real supply chain compromise that occurred in March 2026. All dates, threat actor names, attack techniques, and technical details are sourced from published security advisories and independent research. Armor’s editorial analysis and defensive recommendations are clearly identified throughout.

The Attack

How a Trusted AI Library Became a Weapon

A threat actor group called TeamPCP compromised LiteLLM, a Python library used by AI teams to route requests across LLM providers like OpenAI, Anthropic, and Azure OpenAI. LiteLLM is downloaded roughly 3.4 million times per day. Two malicious versions were published to PyPI using stolen maintainer credentials. The compromised packages were live for approximately three hours before being quarantined.

What the Payload Harvested

Cloud provider credentials (AWS, GCP, Azure)
Kubernetes service account tokens
SSH keys

API keys in environment variables
Database passwords

For healthcare organizations using LiteLLM in AI pipelines, and many are, directly or as a transitive dependency, this library sits at one of the most sensitive intersections in the stack. It’s the routing layer between your application and the LLM provider, with access to:

API keys for every model provider you use
Cloud credentials for the infrastructure it runs on
The data flowing through it which in healthcare often includes PHI

“If your organization can’t answer the question ‘what AI-related packages are deployed in our environment and what credentials do they have access to,’ you have a gap.

Dominick Paynter Cloud Security Architect Armor

Attack Chain Timeline

March 19–23

Trivy
(security scanner)
compromised

March 23

Checkmark KICS
(infrastructure scanner)
compromised

March 24

LiteLLM maintainer credentials stolen via compromised Trivy

March 24
10:39 UTC

Malicious LiteLLM v1.82.7 published to PyPI

March 24
10:52 UTC

Malicious v1.82.8 published with .pth persistence mechanism

March 24
12:30 UTC

Developer discovers compromise by accident, reports to PyPI

March 24
1:38 PM UTC

PyPI quarantines both packages

Phase 1

Security scanner poisoned

TeamPCP compromised Trivy, an open source security scanner, and Checkmarx KICS, an infrastructure scanning tool. The tools organizations use to verify their code was safe became the vector for compromise.

Phase 2

Credentials stolen

LiteLLM’s CI/CD pipeline used Trivy in its build process. The compromised Trivy action exfiltrated LiteLLM’s PyPI publishing token from the GitHub Actions runner. The attackers now had legitimate credentials to publish packages under the real LiteLLM name.

Phase 3

Package weaponized

At 10:39 UTC, the attackers published version 1.82.7 with a malicious payload in proxy_server.py. Thirteen minutes later, they published 1.82.8 with a .pth file that executes automatically every time Python starts, no import required. Simply having the package installed was enough.

Phase 4

Attack caught by accident

A developer discovered the attack when his 48GB Mac stuttered to a halt, CPU pegged at 100%. A bug in the malware, a recursive process storm, made the attack visible. He reported it to PyPI and the LiteLLM maintainers. The packages were quarantined within 40 minutes of his report.

Detection in Practice

Package scanning didn’t catch this because the package was legitimately signed. What catches it is EDR policy, credential access monitoring on sensitive files, outbound connection control on application processes, and file write rules on .pth creation. That’s what Armor’s MDR team tunes.

Armor MDR for supply chain detection

Threat Pattern

Why Attackers Are Targeting the AI Supply Chain

TeamPCP didn’t go after random packages. They hit:

A security scanner (Trivy)
An infrastructure scanner (KICS)
An AI model router (LiteLLM)

All three have elevated access to automated pipelines, credentials, and infrastructure.
All three are trusted by default.

AI libraries:

Run with broad permissions
Access API keys and cloud credentials
Operate in CI/CD environments where detection is minimal
Are installed by developers who trust the package ecosystem

The LiteLLM payload passed all standard package integrity checks because it was published using legitimate credentials. No hash mismatch, no suspicious domain, no misspelled package name.

The Detection Gap

The only detection path is runtime behavioral monitoring, watching what the process does after installation, not what it looks like on the way in. That’s the difference between package scanning and managed detection and response (MDR).

Armor MDR catches what scanners miss

What to Do About It

Operational Guidance

The proposed HIPAA Security Rule would require a written technology asset inventory updated annually. LiteLLM was a transitive dependency in many environments, pulled in automatically, never inventoried, running with access to cloud credentials and ePHI data flows.

Pin all dependency versions with cryptographic hash verification

Running pip install litellm without a pinned version is how the compromised packages reached most affected systems. Pinning limits your blast radius to a known, audited version.

HIPAA 2026: Technology asset inventory; vulnerability management

Audit what credentials your AI tools can access

LiteLLM had access to cloud provider credentials, Kubernetes tokens, and API keys. AI routing libraries don’t need access to your entire cloud environment. Isolate them. Apply least-privilege.

HIPAA 2026: Access controls; network segmentation; encryption of ePHI

Inventory your AI dependencies as security-relevant assets.

Under the proposed HIPAA Security Rule, your technology asset inventory needs to include the packages running in your AI pipelines, the API keys they use, and the data flows they touch.

HIPAA 2026: Annual technology asset inventory and network map (mandatory)

Disable auto-mounted Kubernetes service account tokens.

The payload specifically targeted Kubernetes, attempting to deploy privileged pods and extract cluster secrets. Disable automatic token mounting for pods that don’t need cluster API access.

HIPAA 2026: Network segmentation; access controls; least-privilege

Monitor your CI/CD pipelines for unexpected package changes.

The attack entered through the build pipeline. Your CI/CD environment has publishing credentials, cloud access, and the ability to modify what gets deployed. Treat it as production.

HIPAA 2026: Comprehensive audit logging; biannual vulnerability scans

Where to Start

Every organization’s AI footprint, compliance posture, and risk tolerance are different. Armor’s assessment is an informal, consultative conversation to help your team map your current exposure, identify near-term priorities, and determine what support, if any, makes sense for where you are today.

Schedule an assessment

The Bottom Line

The Attack Surface Is New. The Fundamentals Are Not.

Healthcare organizations are adopting AI because the operational benefits are real. But every new dependency is a new trust relationship, and the LiteLLM attack shows what happens when that trust is exploited.

The proposed HIPAA Security Rule exists because regulators reached the same conclusion. The controls that stop supply chain attacks are the controls HHS wants to make mandatory. Asset inventories, network segmentation, encryption, logging, BA verification, incident response, these aren’t new concepts. What’s new is that AI has made them urgent.

“When a trusted package becomes the attack vector, the only thing that catches it is visibility into what’s actually running in your environment.

Dominick Paynter Cloud Security Architect Armor

About Armor

Armor is a global leader in cloud-native managed detection and response. Trusted by over 1,700 organizations across 40 countries, Armor delivers cybersecurity, compliance consulting, and 24/7 managed defense built for transparency, speed, and results. By combining human expertise with AI-driven precision, Armor safeguards critical environments to outpace evolving threats and build lasting resilience. For more information visit our website, follow us on LinkedIn, or request a free Cyber Resilience assessment.