LLMjacking: AI API Key Stolen, Victim's Cloud Bill Reaches $1 Million

By , Tim Engineering APIPedia · Published · Updated · 9 min read

Google and Mandiant reveal LLMjacking: AI API keys stolen and then sold cheaply via LLM Mixer, victims billed up to $1 million. This is how it works and how to check it.

APIPedia Cover: LLMjacking, AI API key stolen and victim paying, with peak billing facts card of over 100 thousand dollars per day and 1 million dollars cumulative

LLMjacking is hijacking access to a company's AI model (LLM) using stolen credentials, then reselling the access to other parties while the victim foots the bill. A Google Threat Intelligence Group (GTIG) and Mandiant report on November 2, 2026 noted fraudulent bills of more than $100,000 in one day, and there were victims whose bills reached $1 million.

This report has been widely discussed in the security media and developer community since November 3. The reason is simple: almost all teams now store AI API keys somewhere, either in file .env, in CI, or in a gateway like LiteLLM. This article discusses what happens, how it works, the myths circulating, and check steps you can take today.

What are Google and Mandiant actually reporting?

Throughout 2026, Mandiant responded to multiple LLMjacking incidents in the financial services, retail, technology, and transportation sectors in North America, South America, and Asia Pacific. The main finding: the perpetrator did not work alone. There is a neat division of labor.

  • Early access seekers steal cloud credentials or LLM API keys, or look for model endpoints exposed to the internet.
  • The "LLM Mixer" operator stores the stolen keys behind a gateway, sets the quota, disguises the origin of the request, then sells cheap access to customers on the black market.

The difference with cryptojacking, which drains resources slowly, LLMjacking can cause bills to skyrocket in a matter of hours. BleepingComputer reports that the volume of requests can increase to more than 1,000 requests per second. Because the request uses a valid key, the cloud provider records it as normal usage and bills it to the victim.

How does LLMjacking work, step by step?

Flowchart of an LLMjacking attack in five stages: 1 steal credentials from a public GitHub repo, service account key, session token, or open Ollama endpoint; 2 silent validations with max_tokens=1; 3 enable Bedrock or Gemini API and turn off logs; 4 keys combined in LLM Mixer and sold for about 60 dollars per month; 5 victims footed with bills of over 100 thousand dollars a day to a cumulative 1 million dollars

1. Stealing credentials

According to GTIG, the most dominant entry points are leaked or stolen cloud identities: IAM credentials, service account keys, GitHub Personal Access Tokens, and active session tokens. There are also actors who harvest LLM API keys from public GitHub repositories, and actors who call endpoint /api/create on exposed Ollama servers to register their own models.

The UNC6993 group even created a fake page posing as an application portal. The victim is asked to paste a JSON payload containing an active access token, so that the perpetrator can bypass the password and MFA.

2. Test the lock without getting caught

Before being sold, the key is validated with a very small request, for example max_tokens=1. Usage is almost zero, so it doesn't trigger volume alarms in SIEM or EDR.

3. Enable AI services and persist

In some incidents, the victim's AI services were not even active. The perpetrator used the stolen key to activate the Bedrock or Gemini API, create a new API key, sign up for a Pay-As-You-Go plan, and select a premium model. To survive, they created new IAM accounts, injected SSH keys into VM metadata, and in one case created a service account disguised as an "internal billing optimization utility." There are also perpetrators who turn on GPU instances in several regions and ask for quota increases.

4. Selling via LLM Mixer

GTIG said UNC6993 uses the open source tools new-api and gcli2api to combine stolen keys and share the request load. The most striking example is Jet Night (jet-night.com): one actor supplying stolen keys to this service made more than 500,000 LLM API calls in less than eight hours, and the token fees charged to victims were nearly $1 million. Jet Night offers an "unlimited" plan for around $60 per month, whereas comparable official subscriptions range from $100 to $250 per month. The service also announced several outages on Telegram, which GTIG said likely occurred because victims revoked their keys.

5. Attack the LLM gateway

This section is most relevant for teams installing their own gateways. One advanced group received a validated LiteLLM Virtual Key, then exploited CVE-2026-40217 to elevate the regular key to a master credential PROXY_ADMIN. Anyone who controls the routing layer can see and use all the keys behind it.

What is CVE-2026-40217, and why are the descriptions different?

There are differences between sources that you need to know. The GTIG report describes CVE-2026-40217 as a user ID rebind vulnerability in LiteLLM /key/regenerate endpoints. Meanwhile, the CVE description in public databases (cvefeed/NVD and Red Hat Bugzilla) mentions remote code execution via bytecode rewriting on endpoint /guardrails/test_custom_code, valid for LiteLLM "until 2026-04-08", with a CVSS 3.1 score of 8.8 (High). BleepingComputer follows the second description.

Neither source mentions a specific fix version number. Safe stance: update LiteLLM to the latest release, and restrict access to both endpoints from the internet.

Summary of key figures and facts

AspectFactSource
Report dateNovember 2, 2026GTIG & Mandiant
Peak billingOver $100,000 in one dayGTIG
Cumulative billingUp to $1 million before access is revokedGTIG
Jet Night case500,000+ API calls in < 8 hours, cost almost $1 millionGTIG
Dark package price±$60/month, vs $100–$250 for the official subscriptionGTIG
Spike in requestsCan be more than 1,000 requests/secondBleepingComputer
Exploited gatewayLiteLLM, CVE-2026-40217 (CVSS 8.8)GTIG, cvefeed
Service calledAWS Bedrock, Gemini API, Gemini Enterprise Agent Platform, Azure Cognitive Services, OllamaGTIG

Myth vs fact

  • Myth: "We don't use AI in the cloud, so it's safe." Fact: in some incidents, AI services were not active. The perpetrator himself activated it with stolen credentials.
  • Myth: "If there is a theft, it will definitely be visible from the spike in usage." Fact: the test phase uses request max_tokens=1 which is almost invisible. The new spike appears after the keys are sold, and by then the bill is already running.
  • Myth: "Victims pay $100,000 every day." Fact: that number is the highest peak recorded in a single day, not the average daily cost. Some headlines make it sound more routine.
  • Myth: "Just change the password." Fact: API keys, service account keys, and session tokens remain valid until revoked or rotated. Just changing the password does not stop using a leaked key.

How to check if you have it?

GTIG emphasizes that LLM services suddenly activating without authorization must be treated as a critical security incident. Here's the event log they recommend monitoring.

Table of three event log columns that need to be monitored for LLMjacking detection: AWS CloudTrail InvokeModel, Converse, PutUseCaseForModelAccess, CreateFoundationModelAgreement and DeleteModelInvocationLoggingConfiguration; Azure deployments/write, bulk POST to Chat Completions and diagnosticSettings/delete; Google Cloud ServiceUsage.EnableService, GenerateContent and GetIamPolicy

Check AWS: who opened model access or turned off Bedrock logs?

The following command reads CloudTrail management events (90 day history) in the active region. Repeat for each region you use.

# Event yang membuka akses model atau mematikan logging Bedrock
for ev in PutUseCaseForModelAccess CreateFoundationModelAgreement \
          DeleteModelInvocationLoggingConfiguration PutModelInvocationLoggingConfiguration; do
  echo "== $ev"
  aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=$ev \
    --max-results 20 \
    --query 'Events[].[EventTime,Username,EventName]' --output table
done

# Siapa saja yang membuat access key baru
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --max-results 20 --query 'Events[].[EventTime,Username]' --output table

Check Google Cloud: what new services are activated?

# Daftar aktivasi layanan 7 hari terakhir, cari aiplatform/generativelanguage
gcloud logging read \
  'protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.EnableService"' \
  --freshness=7d --limit=50 \
  --format='table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.resourceName)'

# Layanan AI yang sedang aktif di project ini
gcloud services list --enabled | grep -Ei 'aiplatform|generativelanguage'

Note: model usage events like GenerateContent in Google Cloud are only logged if Data Access logs are enabled, and by default the feature is disabled.

Check the LiteLLM gateway and key leaks in the repo

# Versi LiteLLM yang terpasang (jalankan di host/container gateway)
pip show litellm | grep -i ^version

# Pindai seluruh riwayat git untuk API key yang pernah ter-commit
gitleaks git -v .        # gitleaks v8.19+; versi lama: gitleaks detect -v

While waiting for the update, close the risk endpoint from public access in a reverse proxy, for example Nginx:

# Endpoint yang disebut dalam CVE-2026-40217: hanya untuk jaringan internal
location ~ ^/(guardrails/test_custom_code|key/regenerate) {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://litellm_upstream;
}

What does this mean for developers and businesses in Indonesia?

Cloud bills are calculated in dollars. At an exchange rate of around tens of thousands of rupiah per dollar, a $100,000 bill in a day is equivalent to billions of rupiah, far exceeding the annual AI budget of most startups and digital MSMEs. That's why spending limits are not a formality.

Priority steps summarized from GTIG recommendations:

  1. Save key in secrets manager and auto rotation. Never commit .env.
  2. Least privilege: deny all unneeded permissions, including access to LLM cloud services.
  3. Separate keys per model and environment (dev/prod), so that keys for cheap models cannot call frontier models.
  4. Set a budget and quota per model, complete with alerts.
  5. Scan secrets automatically in GitHub/GitLab, then revoke the leaked key immediately.
  6. Put LiteLLM and similar proxies on the patch schedule, prioritizing CVE-2026-40217.
  7. Use phishing-resistant MFA on cloud consoles and developer platforms.

This trend is also in line with recent incidents targeting AI developer tools, for example a fake Claude Code extension that planted an SSH backdoor and a Postman plugin that was secretly installed in Claude Code and Codex. Credentials on developer machines are now high-value targets.

If you use third-party APIs, including in the APIPedia console, the principles are the same: create separate keys per application, monitor usage logs, and revoke keys that are no longer used.

FAQs

What is the difference between LLMjacking and cryptojacking?

Cryptojacking steals computing power to slowly mine crypto. LLMjacking steals access to paid AI models, and because premium model token prices are high, the bill can skyrocket in a matter of hours. GTIG estimates that perpetrators will increasingly choose LLMjacking because there is a resale market.

Is using cheap "unlimited" AI services dangerous?

Services that sell frontier model access far below the official price should be suspect. GTIG thinks Jet Night, with a package of around $60 per month, can only make a profit using stolen keys. In addition to breaking the law, your prompts and data pass through a criminal's infrastructure.

What is the earliest sign that my keys have been stolen?

Pay attention to very small requests such as max_tokens=1 or zero temperature pings from foreign IPs, AI services suddenly activating, new access keys or service accounts, and logging configuration changes. Cost spikes usually come later.

My key has already been leaked on GitHub. Just delete the commit?

Not enough. Git history and copies (fork, cache) can keep it. The correct step is to revoke or rotate the key on the provider first, check the usage log, then clean the repo history.

Source

Topics:

${c.about}

Tim APIPedia — Tim Engineering APIPedia

Tim engineering di balik APIPedia yang membangun dan memelihara API data Indonesia - ongkir, OCR KTP, data wilayah, BMKG, hingga server MCP - dan menulis panduan integrasinya dari pengalaman langsung.