As reported by BleepingComputer, Google's Threat Intelligence Group (GTIG) and Mandiant have documented a surge in LLMjacking attacks — large language model hijacking — that have generated fraudulent cloud AI charges exceeding $1 million at affected organizations, with some bleeding over $100,000 in a single day. This is not a hypothetical risk anymore; it is an active, monetized criminal economy.

Cloud Security Alert: As reported by BleepingComputer, Google's Threat Intelligence Group (GTIG) and Mandiant have documented a surge in LLMjacking attacks — large language model hijacking — that have generated fraudulent cloud AI charges exceeding $1 million at affected organizations, with some bleeding over $100,000 in a single day.

Why This Matters

LLMjacking represents a new abuse category that sits at the intersection of credential theft, API security, and cloud cost management. Traditional breach economics revolved around data exfiltration or ransomware encryption. LLMjacking is different: the attacker monetizes your compute consumption directly. You may never lose a single customer record, yet still face a six-figure bill because someone resold your API capacity through a proxy service charging $60/month for "unlimited" AI access.

The economics are brutal. A single stolen API key can generate over 1,000 requests per second. At enterprise LLM token pricing, that burns through budgets at extraordinary speed. And because the usage appears legitimate from the provider's perspective — the requests use valid credentials — there is no fraud flag until someone reviews the bill or monitoring alerts.

The Threat Landscape: Two Clusters, One Supply Chain

GTIG identifies two operational layers:

  • Access brokers — scan for exposed LLM endpoints and steal credentials from unprotected systems, including GitHub tokens, session tokens, and secrets stored in databases or logs.
  • LLM mixers — proxy services (like Jet Night and newapi[.]pro) that aggregate stolen keys and resell unauthorized access at deep discounts. These are effectively AI-scale unauthorized resellers.

The identified threat cluster UNC6993 appears to operate gateway tooling that aggregates and rotates stolen keys to distribute request load — a classic illicit proxy infrastructure model.

CVE-2026-40217: The LiteLLM Weakness Compounding the Risk

Particularly concerning is the exploitation of CVE-2026-40217, a vulnerability in LiteLLM that enables arbitrary code execution via the custom-code guardrail testing endpoint. LiteLLM is widely used as a proxy gateway to unify access across multiple LLM providers, meaning a single vulnerable instance can expose an organization's entire AI API surface.

AttributeDetail
CVECVE-2026-40217
Affected ProductLiteLLM (proxy/server component)
VectorCustom-code guardrail testing endpoint — arbitrary code execution
ImpactRemote code execution on the LLM gateway host
Active ExploitationYes — observed in LLMjacking campaigns per GTIG/Mandiant
Patch StatusCheck LiteLLM GitHub repository for updated releases; restrict access to the guardrail testing endpoint immediately as a workaround

The combination of stolen credentials and an RCE in a widely-deployed AI gateway means attackers can pivot from financial abuse to full infrastructure compromise — creating backdoor accounts and injecting SSH keys for persistence.

Who Is Most at Risk

  • Enterprises with public-facing LLM APIs or AI proxy gateways exposed to the internet.
  • Organizations using LiteLLM or similar open-source LLM proxy tools without network segmentation.
  • Teams storing API keys or service account credentials in source code repositories, CI/CD pipelines, or unprotected configuration files.
  • Cloud-heavy environments where AI usage billing is decentralized or not closely monitored.

Shield53 Recommendations

Immediate Actions

Shield53 Recommendations
Patch LiteLLM now if deployed. If you cannot patch immediately, disable or restrict network access to the custom-code guardrail testing endpoint. Ensure the proxy management interface is not internet-exposed.
Audit and rotate all LLM API keys, especially those stored in GitHub repos, CI/CD variables, or local development environments. Use a secrets manager — not plaintext config files.
Set billing alerts at your AI cloud provider. Configure anomaly detection on token consumption — any spike beyond 2x your rolling average should trigger an immediate page.
Restrict API keys with least privilege. Apply IP allowlists where supported. Disable keys that are unused or associated with deprecated projects.
Hunt for indicators of compromise: look for unexpected service account creation, new SSH keys added to authorized_keys files, and anomalous outbound traffic to unfamiliar proxy domains.

Strategic Defenses

  • Implement zero-trust access for AI gateways — all LLM proxy interfaces should sit behind identity-aware proxies with MFA, not exposed directly.
  • Adopt rate limiting and quota enforcement at the API key level to cap blast radius if a key is compromised.
  • Conduct a secrets hygiene audit across repositories, infrastructure-as-code, and container images. Tools like GitHub Advanced Security or TruffleHog can surface exposed credentials before attackers do.
  • Treat AI API keys as tier-1 secrets in your IAM program — equivalent to cloud root credentials, not developer convenience tokens.

The LLMjacking economy is still maturing, but the signals are clear: AI infrastructure is now a prime target. Organizations that fail to treat LLM credentials and gateways with the same rigor as traditional cloud admin access will continue subsidizing anonymous reseller profits — or worse, wake up to a full infrastructure compromise traced back through a neglected AI proxy.