LLMjacking 2026: How Stolen Cloud API Keys Became a $1 Million AI Fraud Problem
Executive Summary
Executive Summary In 2026, Google's Threat Intelligence Group and Mandiant documented a surge in LLMjacking attacks, in which two coordinated threat clusters compromise enterprise cloud LLM infrastructure by stealing API keys, harvesting exposed endpoints, and reselling unauthorized access through proxy services called LLM mixers. One campaign tied to the service jet-night.com generated nearly $1 million in fraudulent token charges against a single victim organization, with some enterprises absorbing more than $100,000 in illegitimate cloud costs in a single day. Attackers also exploited CVE-2026-40217 in LiteLLM to execute arbitrary code, deployed reverse proxies, and established persistent backdoor access within compromised cloud environments.
LLMjacking represents a rapidly maturing criminal economy around stolen AI infrastructure. As enterprises accelerate cloud AI adoption, exposed API keys and over-permissioned service accounts create immediate financial and operational risk. The emergence of underground LLM mixer marketplaces signals that credential-based AI resource hijacking is becoming a commoditized threat vector, demanding urgent attention to IAM hygiene, secrets management, and AI-specific egress controls.
Why This Matters Now
Why This Matters NowEnterprise spending on cloud AI is accelerating in 2026, making unprotected LLM API keys a high-value target. LLM mixer marketplaces now offer stolen AI access for as little as $60 per month, commoditizing the attack. With fraudulent charges reaching $1 million per victim and request rates exceeding 1,000 per second, organizations face both catastrophic financial exposure and reputational damage if cloud AI governance is not treated as an immediate security priority.
Attack Path Analysis
Attack Path AnalysisLLMjacking attackers gained initial access by scanning for publicly exposed LLM endpoints and stealing API keys from unprotected machines and code repositories, then escalated privileges by discovering additional credentials stored in secret managers, logs, and databases within the compromised cloud environment. They moved laterally across cloud services to identify and abuse additional LLM service accounts, established persistent command-and-control infrastructure by deploying unauthorized reverse proxies and agentic workloads inside the victim's own cloud, and exfiltrated value indirectly by routing stolen API keys through LLM mixer services to resell AI compute access. The cumulative impact was fraudulent cloud billing exceeding $1,000,000, service degradation, and unauthorized use of victim infrastructure as a commercial AI proxy platform.
Kill Chain Progression
Kill Chain ProgressionThis 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
DescriptionAttackers scanned for publicly exposed LLM API endpoints and harvested valid credentials including API keys, GitHub tokens, service account keys, and active session tokens from unprotected repositories and machines. CVE-2026-40217, a remote code execution vulnerability in LiteLLM's custom-code guardrail testing endpoint, was also exploited to gain initial code execution on LLM serving infrastructure.
Related CVEs
Related CVEsCVE-2025-27496
CVSS 3.3LiteLLM contains a server-side request forgery and arbitrary code execution vulnerability via the custom-code guardrail testing endpoint, allowing unauthenticated remote attackers to execute arbitrary code on the server hosting LiteLLM proxy infrastructure.
Affected Products:
BerriAI LiteLLM – < 1.63.11
Exploit Status:
exploited in the wild
MITRE ATT&CK® Techniques
MITRE ATT&CK® TechniquesUnsecured Credentials: Credentials In Files
Valid Accounts: Cloud Accounts
Account Manipulation: Additional Cloud Credentials
Command and Scripting Interpreter: Python
Exploit Public-Facing Application
Web Service: Bidirectional Communication
Resource Hijacking
Impair Defenses: Disable Cloud Logs
Potential Compliance Exposure
Potential Compliance ExposureMapping incident impact across multiple compliance frameworks.
PCI DSS 4.0 – Management of System and Application Accounts / MFA for All Access
Control ID: Requirement 8.6.1 / 8.3.6
NYDFS 23 NYCRR 500 – Access Privileges / Multi-Factor Authentication / Monitoring
Control ID: 500.7 / 500.12 / 500.14
DORA (Digital Operational Resilience Act) – ICT Security Controls / Logging and Monitoring / ICT-Related Incident Reporting
Control ID: Article 9 / Article 10 / Article 17
CISA Zero Trust Maturity Model 2.0 – Continuous Identity Validation and Least-Privilege API Access
Control ID: Identity Pillar: Credential Management / Application Pillar: API Security
NIS2 Directive – Risk Management Measures: Access Control, Asset Management, Incident Handling
Control ID: Article 21(2)(a)(b)(e) / Article 23
ISO/IEC 27001:2022 – Privileged Access Rights / Information Access Restriction / Use of Cryptography / Threat Intelligence
Control ID: Annex A 8.2 / 8.3 / 8.24 / 5.7
Sector Implications
Sector ImplicationsIndustry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
LLMjacking attackers exploit stolen cloud API keys and exposed LLM endpoints, generating $1M in fraudulent charges; IT organizations face critical IAM, secrets management, and multicloud visibility gaps enabling credential abuse.
Financial Services
Fraudulent cloud AI charges exceeding $100,000 daily from stolen API keys expose financial services firms to unbudgeted liability, compliance violations under NIST.800-53 and PCI 4.0, and shadow AI governance failures.
Internet
LLM mixer proxy infrastructure like Jet Night resells hijacked cloud AI access at scale; internet platform operators face agentic workload abuse, unauthorized reverse proxies, and CVE-2026-40217 exploitation risks.
Computer/Network Security
Security vendors must address cloud credential abuse, egress policy enforcement gaps, and shadow AI detection; validated capabilities like CNSF and multicloud visibility directly map to LLMjacking kill chain disruption priorities.
Sources
Sources- Google: LLMjacking attacks rack up $1 million in cloud AI chargeshttps://www.bleepingcomputer.com/news/security/google-llmjacking-attacks-rack-up-1-million-in-cloud-ai-charges/Verified
- LLMjacking: Monetizing Compromised Cloud Modelshttps://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-modelsVerified
- CISA Known Exploited Vulnerabilities Cataloghttps://www.cisa.gov/known-exploited-vulnerabilities-catalogVerified
- NVD - CVE-2025-27496https://nvd.nist.gov/vuln/detail/CVE-2025-27496Verified
- LiteLLM Security Advisories - BerriAI GitHubhttps://github.com/BerriAI/litellm/security/advisoriesVerified
- Google Threat Intelligence Group - Threat Researchhttps://cloud.google.com/blog/topics/threat-intelligenceVerified
Frequently Asked Questions
Frequently Asked QuestionsCloud 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 LLMjacking because attackers depended on unrestricted access to publicly reachable LLM endpoints, free lateral movement across cloud services, and uncontrolled egress paths to operate their proxy infrastructure. Enforcing identity-aware segmentation and controlled egress would likely have reduced the attacker's reachable surface and constrained the blast radius well before fraudulent billing reached seven figures.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: Applying a Zero Trust perimeter around LLM serving workloads would likely have reduced the number of directly reachable endpoints available to external scanners, constraining the attacker's ability to discover and interact with live API surfaces without authenticated, policy-approved network paths.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation would likely constrain the attacker's ability to pivot from a compromised LLM workload into adjacent services holding credentials, reducing the scope of reachable secret stores, databases, and IAM-adjacent resources available from that initial foothold.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement would likely reduce the attacker's ability to move freely between cloud services and regions, constraining credential-based pivoting to only those service-to-service paths explicitly permitted by policy rather than anything reachable within the cloud tenant.
Control: Multicloud Visibility & Control
Mitigation: Multicloud visibility and policy control would likely surface unauthorized workload deployments and constrain their ability to bind externally accessible listener ports, reducing the reachability of attacker-deployed reverse proxies to outside subscribers and limiting the viability of the victim environment as persistent C2 infrastructure.
Control: Egress Security & Policy Enforcement
Mitigation: Egress policy enforcement would likely constrain outbound LLM API traffic to approved destinations and volumes, reducing the attacker's ability to relay high-volume subscriber requests through victim infrastructure to external mixer services without triggering policy-based restrictions on unapproved egress paths.
Had earlier segmentation and egress controls reduced attacker reachability and constrained lateral movement, the cumulative financial impact and scope of infrastructure repurposing would likely have been materially smaller, with fewer LLM endpoints reachable for abuse and fewer outbound relay paths available for high-volume token consumption.
Impact at a Glance
Affected Business Functions
- Cloud AI/ML API Services and LLM Inference Workloads
- Cloud Billing and Cost Management
- Identity and Access Management (IAM) / Secrets Management
- Cloud Infrastructure Operations and Compute Resource Allocation
Estimated downtime: 3 days
Estimated loss: $1,000,000
Compromised cloud service account keys, LLM API keys, GitHub tokens, and active session tokens were exfiltrated and abused. Attackers accessed secret managers, logs, and internal databases within victim cloud environments. Backdoor accounts and injected SSH keys enabled persistent unauthorized access. Sensitive cloud credentials and infrastructure configurations were exposed to threat actors operating LLM mixer services, enabling ongoing fraudulent token consumption and potential exposure of proprietary AI prompts and inference data processed through hijacked endpoints. Cumulative fraudulent charges reached $1,000,000 per organization, with single-day losses exceeding $100,000.
Recommended Actions
Key Takeaways & Next Steps
- • Apply Zero Trust Segmentation and identity-based policies (ZTMM.Network, NIST.800-53.AC-6) to enforce least-privilege access to LLM API endpoints, ensuring no workload or service account holds standing permissions to cloud AI services beyond its explicit operational need, and use SmartGroups or namespace-level controls to isolate AI inference workloads from general compute.
- • Deploy Egress Security and Policy Enforcement (ZTMM.Data, NIST.800-53.SC-18) with FQDN filtering and outbound traffic controls to detect and block unauthorized API relay traffic destined for known LLM mixer infrastructure such as jet-night.com and newapi[.]pro, preventing victim infrastructure from being used as a commercial proxy platform.
- • Enable Multicloud Visibility and Control (ZTMM.CrossCutting.Visibility, NIST.800-53.AU-6) with centralized audit logging across all cloud tenants to baseline normal LLM API call volumes and alert on anomalous spikes, sudden credential checks against secret managers, or unauthorized activation of agentic workloads and reverse proxy services.
- • Leverage Cloud Native Security Fabric (CNSF) inline enforcement capabilities (ZTMM.CrossCutting.Automation, NIST.800-53.SI-4) to apply real-time inspection and distributed policy controls that can identify shadow AI deployments, unauthorized LLM endpoint exposure, and prompt-injection or API-abuse patterns before they generate billable consumption at scale.
- • Use Cloud Firewall (ACF) with AI-assisted traffic discovery and East-West Traffic Security controls (ZTMM.Network, NIST.800-53.SC-7) to restrict workload-to-LLM-service communication paths, enforce API usage limits at the network layer, and detect inter-region or cross-account pivoting that indicates credential-based lateral movement across the cloud LLM environment.
