Executive Summary
On October 21, 2026, LiteLLM's release pipeline was compromised, resulting in the publication of malicious package version 1.107.0 to PyPI, Docker Hub, and GHCR. Attackers exploited GitHub CLI OAuth tokens that had been inadvertently logged by Claude Code in LiteLLM's internally exposed AI gateway deployment. Using these stolen credentials, the attacker disabled branch protections, redirected the signing workflow to a lookalike repository, and published a poisoned artifact embedding a credential stealer and a persistent RAT. Within 4.5 hours of exfiltration, attackers began validating stolen AWS credentials and performing LLMjacking reconnaissance against Bedrock and IAM services.
This incident underscores an emerging and underappreciated risk: AI coding assistants and LLM gateway proxies can inadvertently log sensitive authentication tokens, creating a new credential-leak surface. As enterprises accelerate AI adoption, supply-chain attacks targeting AI infrastructure tooling are becoming a primary threat vector, demanding stricter secrets hygiene, pipeline integrity controls, and real-time egress monitoring for developer environments.
Why This Matters Now
AI gateway tools like LiteLLM are now deeply embedded in enterprise CI/CD and cloud workflows, making them high-value supply-chain targets. The logging of OAuth tokens by AI coding assistants such as Claude Code introduces a novel, largely unmonitored credential-exposure vector. With LLMjacking incidents rising and attackers pivoting to AI infrastructure within hours of compromise, organizations must treat AI tooling logs as sensitive assets requiring the same egress controls and secrets hygiene applied to production systems.
Attack Path Analysis
Attackers likely accessed a publicly exposed LiteLLM internal deployment and harvested GitHub CLI OAuth tokens from unprotected AI gateway logs where Claude Code had inadvertently embedded them. Using those stolen credentials, the attacker disabled branch protections, redirected the CI/CD workflow to a lookalike repository, and force-pushed a malicious Python package version containing a credential stealer and RAT to PyPI, Docker Hub, and GHCR. Compromised environments then beaconed hourly to an attacker-controlled C2 domain retrieved via a GitHub dead drop, while stolen AWS instance role credentials and Kubernetes node credentials were validated and used for LLMjacking and IAM enumeration within hours of exfiltration.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
The attacker accessed LiteLLM's publicly exposed internal deployment, suspected to be via a recently patched but unmitigated vulnerability. From this foothold, the attacker retrieved GitHub CLI OAuth tokens that had been inadvertently logged in plaintext by the LiteLLM AI gateway after Claude Code embedded them in response bodies. CNSF Cloud Native Security Fabric controls with inline enforcement and real-time inspection of AI agent traffic could have flagged the anomalous token exposure in log pipelines, while Cloud Firewall (ACF) URL filtering could have blocked unauthorized access to the exposed deployment endpoint.
MITRE ATT&CK® Techniques
Supply Chain Compromise: Compromise Software Dependencies and Development Tools
Unsecured Credentials: Credentials In Files
Command and Scripting Interpreter: Python
Event Triggered Execution: Unix Shell Configuration Modification
Exfiltration Over C2 Channel
Application Layer Protocol: Web Protocols
Valid Accounts: Cloud Accounts
Acquire Infrastructure: Domains
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
PCI DSS 4.0 – Software and Patch Management — Third-Party Components
Control ID: Requirement 6.3.3
NYDFS 23 NYCRR 500 – Monitoring and Access Privileges — Credential and Token Governance
Control ID: Section 500.14(a) and 500.7
DORA (Digital Operational Resilience Act) – ICT Supply Chain Risk Management and Third-Party Dependency Controls
Control ID: Article 9(4)(c) and Article 28(4)
CISA Zero Trust Maturity Model 2.0 – Application Integrity Verification and Workload Isolation
Control ID: Applications Pillar — Pillar 4: Visibility and Analytics
NIS2 Directive – Supply Chain Security Policies and Incident Handling
Control ID: Article 21(2)(a) and Article 21(2)(d)
ISO/IEC 27001:2022 – Secure Software Release Pipeline and Dependency Integrity Controls
Control ID: Annex A 8.30 (Outsourced Development) and A 5.23 (ICT Supply Chain Security)
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
LiteLLM supply-chain RAT and credential stealer directly threaten IT teams managing PyPI/Docker pipelines, exposing AWS, Kubernetes, and CI/CD secrets via exfiltration and LLMjacking requiring Zero Trust Segmentation and egress controls.
Computer Software/Engineering
Software engineering teams using unpinned LiteLLM dependencies face poisoned artifact risks; stolen GitHub CLI OAuth tokens and compromised release workflows demand Inline IPS, Cloud Firewall, and immutable build pipeline enforcement.
Financial Services
Credential harvesting targeting cloud IAM roles, AWS instance metadata, and AI tool secrets exposes financial services firms to LLMjacking and unauthorized account enumeration, violating PCI 4.0 and NIST 800-53 SC-7 controls.
Health Care / Life Sciences
Healthcare organizations running LiteLLM AI gateways risk HIPAA 164.312(e)(1) violations as the RAT exfiltrates browser, developer, and cloud credentials via unmonitored HTTP POST egress to attacker-controlled infrastructure.
Sources
- LiteLLM Suspects GitHub Token Leak in AI Gateway Logs Behind Malicious Package Releasehttps://thehackernews.com/2026/10/litellm-suspects-github-token-leak-in.htmlVerified
- LiteLLM Security Incident October 21 2026 - Official Post-Incident Reporthttps://docs.litellm.ai/blog/security-incident-oct-21-2026Verified
- LiteLLM Compromised in Supply Chain Attack - The Hacker Newshttps://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.htmlVerified
- LiteLLM Hijacked Again - JFrog Security Researchhttps://research.jfrog.com/post/litellm-hijacked-again/Verified
- LiteLLM Compromised: Infostealer and RAT Analysis - Aikido Securityhttps://www.aikido.dev/blog/litellm-compromised-infostealer-ratVerified
- LiteLLM Compromised: Steals Credentials via Dual Persistence Technique - Wiz Researchhttps://www.wiz.io/blog/litellm-compromised-steals-credentialsVerified
- Inside LiteLLM Supply Chain Compromise March 2026 - Trend Microhttps://www.trendmicro.com/en_gb/research/26/c/inside-litellm-supply-chain-compromise.htmlVerified
- LiteLLM GitHub Issue 47826 - Incident Trackinghttps://github.com/BerriAI/litellm/issues/47826Verified
- LiteLLM Security Update March 2026 - Prior Incident Advisoryhttps://docs.litellm.ai/blog/security-update-march-2026Verified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is directly relevant to this incident because the attacker's progression depended on unrestricted access to an exposed AI gateway, uncontrolled CI/CD trust boundaries, and unfiltered egress paths to attacker-controlled infrastructure. Had Zero Trust segmentation and controlled egress policies been in place, the attacker's reachability across pipeline, cloud, and Kubernetes environments would likely have been significantly constrained at multiple stages.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: Inline traffic inspection across the AI gateway boundary could likely have flagged anomalous token patterns in outbound log pipelines, and URL-based access controls may have reduced reachability to the exposed internal LiteLLM deployment from unauthorized external sources.
Control: Zero Trust Segmentation
Mitigation: Identity-aware segmentation policies enforcing least-privilege boundaries around CI/CD workflow permissions could likely have reduced the scope of what a single compromised token was permitted to authorize, constraining the attacker's ability to override branch protections from a stolen credential alone.
Control: East-West Traffic Security
Mitigation: East-west enforcement monitoring workload-to-workload interactions within the CI/CD pipeline could likely have detected the workflow's unexpected redirect to an unrecognized external repository, and service identity controls may have constrained the pipeline's ability to interact with repositories outside approved namespaces or identity boundaries.
Control: Multicloud Visibility & Control
Mitigation: Centralized traffic observability across cloud workloads could likely have identified the repeated periodic outbound calls to the GitHub dead drop as anomalous beaconing behavior, and FQDN-based egress filtering may have reduced reachability to the attacker-controlled C2 domain resolved through the dead drop mechanism.
Control: Egress Security & Policy Enforcement
Mitigation: FQDN-based outbound filtering enforced at the egress boundary could likely have blocked HTTP POST traffic destined for the spoofed litellm[.]dev domain, and inline signature-based inspection may have reduced the likelihood of credential payload transmission reaching attacker-controlled infrastructure undetected.
Had prior CNSF controls reduced the attacker's reachability across the AI gateway, pipeline, and egress boundaries, the pool of harvested credentials reaching the attacker would likely have been smaller, constraining the scope of cloud API access available for LLMjacking and IAM enumeration and reducing the overall blast radius of post-compromise activity.
Impact at a Glance
Affected Business Functions
- AI Gateway and LLM Proxy Services
- CI/CD Release Pipeline Integrity
- Cloud Credential and IAM Security (AWS, Kubernetes)
- Developer Toolchain and Software Supply Chain
Estimated downtime: 2 days
Estimated loss: N/A
The malicious LiteLLM v1.107.0 package deployed a credential-harvesting routine ('privcollect') that collected and exfiltrated system credentials, browser-stored secrets, developer tokens, cloud provider keys (including AWS instance role credentials from CI runners and Kubernetes nodes), and AI tool API keys via HTTP POST to the attacker-controlled domain 'litellm[.]dev/healthcheck'. Post-exfiltration, attackers validated stolen AWS credentials using sts:GetCallerIdentity and performed LLMjacking reconnaissance (bedrock:ListFoundationModels), and in a subset of environments conducted IAM enumeration (ListRoles, ListUsers, ListAccessKeys) and general cloud discovery (ListAccounts, DescribeTrails). Any developer or organization that installed an unpinned LiteLLM package between 11:39 and 13:23 UTC on October 21, 2026, or pulled affected Docker image tags (v1.107.0, latest, main-latest, main-stable) between 11:46 and 14:20 UTC is at risk of full credential compromise across cloud, AI, and developer environments. Financial loss is not confirmed at time of synthesis but exposure of cloud credentials at scale represents high potential for LLMjacking cost abuse and unauthorized resource provisioning.
Recommended Actions
Key Takeaways & Next Steps
- • Apply CNSF Cloud Native Security Fabric inline enforcement and real-time inspection on AI gateway and LLM proxy log pipelines to detect and alert on inadvertent embedding of secrets, OAuth tokens, or credentials in AI agent response bodies before they reach persistent log storage.
- • Enforce Egress Security and Policy Enforcement with strict FQDN allowlisting and outbound traffic controls on all CI/CD runner and Kubernetes node workloads to block unauthorized periodic beaconing to GitHub dead drops and unknown C2 domains, directly disrupting the RAT's hourly payload retrieval loop.
- • Deploy Zero Trust Segmentation with identity-based policy and least-privilege controls across CI/CD pipeline service identities, enforcing that no single GitHub token can simultaneously hold branch protection override rights and workflow trigger permissions, minimizing blast radius from any single credential compromise.
- • Enable Multicloud Visibility and Control with centralized traffic observability across cloud workloads and Kubernetes nodes to baseline normal cloud API call patterns and generate high-fidelity alerts on anomalous sequences such as sts:GetCallerIdentity followed by Bedrock LLM API enumeration, consistent with LLMjacking behavior observed post-exfiltration.
- • Implement Kubernetes Security (AKF) pod-level egress controls and namespace enforcement to prevent compromised CI runner or Kubernetes node credentials from being used to make unauthorized outbound calls to cloud provider IAM and AI service APIs, and ensure all internal LiteLLM deployments are governed by Cloud Firewall (ACF) policies that block public internet exposure of administrative interfaces.
