ARTICLE ORIGINAL MAG212 CYBER

LLMjacking: Stolen Cloud AI Keys Run Up $1M Bills, LiteLLM Gateway Flaw Exploited

novembre 8, 2026 · El Mostafa Ouchen

Illustration of stolen cloud API keys flowing through an LLM mixer to resellers while a cloud bill meter spikes

Attackers who steal cloud credentials are now spending them on AI model calls rather than on cryptomining. Google Threat Intelligence Group (GTIG) and Mandiant say some victims of this “LLMjacking” were hit with more than $100,000 in fraudulent charges in a single day and up to $1 million in total. The same report says one intrusion used a LiteLLM gateway flaw, labelled CVE-2026-40217, to turn ordinary keys into full admin credentials. The public CVE record for that ID describes a different LiteLLM bug, so defenders should check both issues.

QuoiLLMjacking: stolen cloud and API credentials used to run, and resell, paid LLM inference at the victim’s expense
Signalé2 November 2026 (Google Cloud blog, GTIG/Mandiant); covered by SecurityWeek and The Hacker News on 6 November
VictimesFinance, retail, technology and transport firms in the Americas and Asia Pacific
LossesMore than $100,000 in a single day; up to $1 million in total at some organisations
Platforms in detection guidanceAWS Bedrock, Azure OpenAI / Cognitive Services, Google Vertex AI, LiteLLM gateways, exposed Ollama servers
LiteLLM CVE-2026-40217Google: /key/regenerate user-ID rebind to PROXY_ADMIN, exploited in one intrusion. Official GitHub advisory: custom-code guardrail sandbox escape, fixed in 1.83.10/1.83.11
ActionSet spending caps and quotas, turn on model-invocation logging, alert on logging changes, rotate keys, upgrade LiteLLM to the latest release

Ce qui s'est passé

Mandiant investigated several LLMjacking incidents in 2026 across multiple providers. Unlike cryptojacking, charges can spike within hours; one tracked actor, UNC6993, ran up more than $100,000 on its own. GTIG expects attackers to favour LLMjacking over older forms of resource theft such as cryptomining, and to target exposed API tokens and model-routing middleware.

The stolen access is resold through what Google calls “LLM mixers”: illicit gateways that pool stolen keys and sell model access to subscribers. One reseller, Jet Night, made more than 500,000 LLM API calls in under eight hours, which left one victim with nearly $1 million in token costs. It advertises an “unlimited” plan for about $60 a month. GTIG notes that legitimate equivalents cost $100 to $250 a month, a sign the service runs on stolen keys.

LLMjacking attack chain from stolen credentials through key validation, model enablement, log evasion and LiteLLM escalation to LLM mixer resale, with matching detection events
Diagram: MAG212 CYBER

Comment fonctionne l'attaque

Initial access. The main way in is exposed or stolen cloud identity material: IAM credentials, service-account keys, GitHub personal access tokens and live session tokens. Google describes several variants:

  • UNC6993 got into a cloud instance through a misconfigured service-account key. It also ran a fake application portal where victims pasted a raw JSON payload containing an active access token. The backend replayed the token, which bypassed both password and MFA checks.
  • Another actor used compromised corporate IAM credentials and cloud federation tokens to generate fresh access keys programmatically, which got around MFA.
  • One actor harvested LLM API keys from public GitHub repositories and tested them with single-token requests (max_tokens=1). These stay under volume alerts.
  • Actors also probed exposed Ollama endpoints with /api/create to register their own models on servers they did not own.

Enablement and persistence. In several cases the victim had never turned on the model service. Attackers enabled it, created extra API keys and signed victims up for pay-as-you-go premium models. One actor cycled short-lived service accounts to evade rate limits; others planted backdoor accounts and SSH keys.

Monetization. GTIG believes UNC6993 used the new-api hub to pool stolen keys and balance load. gcli2api turns CLI tools into standard model endpoints. A custom relay, ai-relay, on lookalike domains fed stolen access into the newapi[.]pro resale ecosystem.

CVE-2026-40217: two different descriptions

According to Google, a follow-on cluster took Virtual Keys from the initial-access actor and attacked the victim’s LiteLLM gateway. It exploited a user-ID rebind flaw in the /key/regenerate endpoint to turn standard Virtual Keys into full PROXY_ADMIN master credentials. Google calls this CVE-2026-40217. Its post gives no CVSS score and no affected or fixed versions, and neither does SecurityWeek.

The public records for CVE-2026-40217 describe something else. LiteLLM’s GitHub advisory GHSA-wxxx-gvqv-xp7p (7 May 2026) and Red Hat’s CVE page describe a sandbox escape in the custom-code guardrail (POST /guardrails/test_custom_code). The advisory lists the affected range as litellm versions 1.81.8 up to but not including 1.83.10. Its patched-version field says 1.83.10; its text says 1.83.11. That bug needs a proxy-admin credential by default, which is exactly what Google says the rebind provides. We found no LiteLLM advisory or release note that mentions /key/regenerate or a user-ID rebind. We cannot confirm the affected or fixed versions for the bug Google describes, or whether Google’s CVE label is a mistake. Treat the version guidance below as covering the documented sandbox escape only.

Indicators and detection

Google’s main rule: treat any unauthorised enablement of an LLM service as a critical event. Its log events:

Platform / logAbuse (invocation)Recon and enablementEvasion and anomalies
AWS CloudTrail (bedrock.amazonaws.com)Converse, InvokeModel, InvokeModelWithResponseStreamListFoundationModels, ListInferenceProfiles, GetFoundationModelAvailability; unlocks via PutUseCaseForModelAccess, CreateFoundationModelAgreementGet/Put/DeleteModelInvocationLoggingConfiguration (disabling by a non-IaC principal is high severity); spikes in ThrottlingException, ValidationException, ResourceNotFoundException; SDK user agents such as claude-cli, aws-sdk-rust, aws-sdk-go-v2 (examples to review, not malicious IOCs)
Azure Activity and Diagnostic logs (Microsoft.CognitiveServices)High-volume Completions / Chat Completions POSTs (diagnostic logs); accounts/deployments/writeaccounts/read, accounts/deployments/readMicrosoft.Insights/diagnosticSettings/read, /write, /delete
GCP Cloud Audit Logs (aiplatform.googleapis.com)PredictionService.Predict, GenerateContent, StreamGenerateContent (Data Access logs, off by default)ServiceUsage.EnableService; ListModels, ListEndpoints, ListPublisherModelsGetIamPolicy, ConfigServiceV2.ListSinks, GetSink

Network IOCs. Google’s IOC table lists two LLM mixer domains: jet-night[.]com et newapi[.]pro. More are in a VirusTotal GTI collection. The Hacker News separately reported Bedrock-key resale sites llm-routing[.]com et xingjiabiapi[.]org (apparently from Wiz research) and four key-testing IPs: 23.106.46[.]239, 38.246.114[.]118, 104.243.32[.]50 et 31.57.201[.]201. These are not in Google’s table and THN names no source for the IPs; treat them as single-sourced.

MAG212 starting points, not vendor-supplied. These queries are our own. Test and adapt field names, log groups and time windows first.

AWS CLI: list recent changes to Bedrock logging and model access (run in each region you use).

# MAG212 starting point
for ev in DeleteModelInvocationLoggingConfiguration PutModelInvocationLoggingConfiguration \
          PutUseCaseForModelAccess CreateFoundationModelAgreement; do
  aws cloudtrail lookup-events --region us-east-1 \
    --lookup-attributes AttributeKey=EventName,AttributeValue=$ev \
    --start-time "$(date -u -d '-14 days' +%FT%TZ)" \
    --query 'Events[].[EventTime,EventName,Username]' --output table
done

CloudWatch Logs Insights, run on a CloudTrail log group: find Bedrock error spikes and the principals and user agents behind them.

# MAG212 starting point
fields @timestamp, eventName, userIdentity.arn, sourceIPAddress, userAgent, errorCode
| filter eventSource = "bedrock.amazonaws.com" and ispresent(errorCode)
| stats count(*) as errors by userIdentity.arn, sourceIPAddress, userAgent, errorCode, bin(1h)
| sort errors desc
| limit 50

CloudTrail does not record request bodies, so max_tokens=1 sweeps are easier to spot in Bedrock model-invocation logs. Run this on the invocation log group if logging is enabled.

# MAG212 starting point - Bedrock invocation log group
fields @timestamp, identity.arn, modelId, output.outputTokenCount
| filter output.outputTokenCount <= 1
| stats count(*) as tinyCalls by identity.arn, modelId, bin(10m)
| sort tinyCalls desc

KQL for Microsoft Sentinel / Log Analytics: new model deployments and diagnostic-setting changes. The Activity Log generally records writes and deletes but not reads.

// MAG212 starting point
AzureActivity
| where TimeGenerated > ago(14d)
| where OperationNameValue in~ (
    "MICROSOFT.COGNITIVESERVICES/ACCOUNTS/DEPLOYMENTS/WRITE",
    "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/WRITE",
    "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE")
| project TimeGenerated, Caller, CallerIpAddress, OperationNameValue, ActivityStatusValue, _ResourceId
| order by TimeGenerated desc

GCP Logging filter: Vertex AI enablement and inference calls. Inference calls appear only if Data Access logs are on.

# MAG212 starting point
gcloud logging read '
  (protoPayload.methodName="google.api.serviceusage.v1.ServiceUsage.EnableService"
   AND protoPayload.resourceName:"aiplatform.googleapis.com")
  OR (protoPayload.serviceName="aiplatform.googleapis.com"
   AND protoPayload.methodName=~"PredictionService\.(Predict|GenerateContent|StreamGenerateContent)")
' --freshness=7d --format='table(timestamp,protoPayload.methodName,protoPayload.authenticationInfo.principalEmail)'

Que faire maintenant

Items 1 to 6 summarise Google’s recommendations. Items marked as MAG212 recommendations are our own.

  • 1. Cap spending. Set per-model API quotas and spending caps, and scope API keys by model, environment and usage so that a basic key cannot call expensive frontier models.
  • 2. Clean up keys. Use centralised secrets management with automatic rotation, run secret scanning on GitHub and GitLab, and deny LLM-service permissions to identities that do not need them.
  • 3. Use phishing-resistant MFA across identity providers, cloud consoles and developer platforms. MAG212 note: the token-paste portal also shows that MFA does not protect a token once it is issued, so keep token lifetimes short.
  • 4. Log and alert. Treat any change to model-invocation logging or diagnostic settings as high severity, enable GCP Data Access logs for Vertex AI, and alert on max_tokens=1 or zero-temperature validation pings.
  • 5. Patch gateways. Include LiteLLM and other model proxies in patch management. MAG212 recommendation: run at least 1.83.11 for the documented guardrail sandbox escape, preferably the current release, and block /guardrails/test_custom_code at the reverse proxy if you do not use it.
  • 6. Restrict access. Rate-limit per client with a WAF, allow-list egress where you can, and find shadow LLM deployments, including Ollama servers reachable from the internet.
  • MAG212 recommendation: assume LiteLLM keys are exposed. If a LiteLLM gateway faces untrusted users, rotate the master key and all Virtual Keys. Review key-regeneration activity and unexpected owner or role changes.
  • MAG212 recommendation: set billing alarms. Set cloud budget alerts well below a normal day’s model spend; losses reached six figures within hours.

What we still don’t know

  • Which LiteLLM versions contain the /key/regenerate rebind flaw, which version fixes it, and whether CVE-2026-40217 is the right identifier for it.
  • Victim count and total losses; Google gives per-incident figures only.
  • The original source of the four key-testing IPs reported by The Hacker News.

Related on MAG212 CYBER

Sources

Written and edited by El Mostafa Ouchen for MAG212 CYBER. Facts verified against the sources above as of 8 November 2026.