Someone Racked Up Almost $1 Million on a Stolen Cloud AI Key in 8 Hours

One victim organization lost close to a million dollars in token costs in under eight hours. Not to a breach that stole data. To an attacker who logged in with a stolen key and started calling an LLM API, over and over, about 500,000 times, through a service called jet-night.com that was reselling the access before the victim even noticed their bill moving.

That case sits inside a report Mandiant and Google’s Threat Intelligence Group published November 3, covering LLMjacking incidents across financial services, retail, tech, and transportation companies in North America, South America, and Asia Pacific through 2026. The term isn’t new. The scale and the business model built on top of it are.

Why this is worse than cryptojacking

Cryptojacking is slow theft. An attacker plants a miner, it chews a few extra percent of CPU, and a victim might not notice for months because the damage accrues gradually. LLMjacking doesn’t accrue. It spikes. Mandiant documented more than $100,000 in fraudulent charges in a single day in some incidents, and cumulative damage reaching $1 million at others before access got revoked. One named actor, UNC6993, got into a cloud instance through a misconfigured service account key, then used two open-source tools — new-api and gcli2api — to pool stolen credentials into a single gateway and resell access through fake portals built to look like legitimate LLM application frontends.

A detail in the report worth sitting with: in several of the incidents Mandiant investigated, the LLM service itself was turned off at the time of compromise. The attackers didn’t find an exposed, already-running service. They found the credentials to turn one on. That’s a different failure mode than most cloud security teams are tuned to watch for — nobody gets an alert for “a disabled product got enabled” the way they’d get one for anomalous API traffic on something already running.

The resale layer is the part that scales this

What actually makes this a business and not just opportunistic fraud is the appearance of what the report calls LLM Mixers — gateways that aggregate stolen access from multiple victims and resell subscriptions to it. jet-night.com advertised unlimited tokens for around $60 a month, undercutting the roughly $100–250 a legitimate reseller market charges, because the underlying compute was never paid for by the people selling it. GTIG found at least one case of two separate operational clusters working together: one group doing the initial compromise, a different group running the monetization infrastructure. That division of labor is the signal that this has moved past individual opportunists into something closer to an underground supply chain, with the LLM Mixer as the fence.

There’s also a specific exploitation path worth naming because it’s fixable today: CVE-2026-40217, a user-ID rebind bug in LiteLLM’s /key/regenerate endpoint that let an attacker escalate a standard virtual key to a PROXY_ADMIN master credential. If you’re running LiteLLM as a routing gateway — and a lot of teams are, precisely because it’s convenient for exactly this kind of multi-model proxying — that patch isn’t optional homework.

This also changes the ordering of incident response. Most teams treat a leaked credential as a data-exfiltration risk first and a billing risk second, if they think about billing at all. LLMjacking inverts that for any account with LLM access enabled: the financial damage from token abuse can land faster and larger than any data an attacker could realistically exfiltrate through that same credential in the same window. A security team that triages a leaked key by asking “what data can this read” and stops there is measuring the wrong clock. The right question is which of these keys can enable or call a paid inference service, and how fast would that bill move if someone else held the key right now.

What to actually check this week

Most of Google’s own recommendations are the standard cloud-hygiene list: rotate secrets, scan repos for leaked keys, enforce MFA, set budget alerts. All true, none of it specific enough to act on today. Two things in the report are more actionable than that. First, GCP’s Cloud Audit Logging for Vertex AI (aiplatform.googleapis.com) does not log data-access calls by default — you have to turn that on manually, and if you haven’t, you have no record of a Predict or GenerateContent call even happening, legitimate or not. Second, watch for the validation pattern attackers use to test stolen keys without tripping volume-based alerts: single requests with max_tokens=1 or a zero-temperature ping. A spike in those specifically, even at low volume, is a stolen-key test, not normal traffic.

If you run any kind of internal LLM gateway, the practical move isn’t a new tool. It’s an audit: which service accounts can enable a currently-disabled AI service, whether your audit logging for that service is actually turned on, and whether your LiteLLM instance (if you have one) is patched past CVE-2026-40217. None of that requires buying anything. It requires someone checking, which is exactly the step that got skipped at every organization in this report before the bill arrived.

Sources

Google Cloud / Mandiant: The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources (November 3, 2026).