Brief · Both

Attackers are running AI models on stolen cloud accounts, and the victims get the bill

By alkizz · Nov 3, 2026

On Nov 2, Google Threat Intelligence Group (GTIG) and Mandiant published a report on LLMJacking, which is what happens when attackers take over a company's access to AI models and run them on that company's cloud bill. Mandiant handled several of these cases in 2026, across financial services, retail, technology and transportation, in North America, South America and Asia Pacific. The numbers are the part people will share, and they're real: fraudulent charges topped $100,000 in a single day, and some organizations reached $1 million before access was revoked. But the way in is mostly boring, so this is a week of hygiene work and not a reason to panic.

How they get in

According to GTIG, the most common way in is exposed or stolen cloud identity, meaning IAM credentials, service-account keys, GitHub personal access tokens and live session tokens. Attackers check that a stolen key works with tiny max_tokens=1 requests, and GTIG says those sweeps stayed under the victim's EDR and SIEM volume alerts. That makes sense to me, because a one-token request looks like nothing at all until there are thousands of them.

The group GTIG calls UNC6993 got in through a misconfigured service-account key. It also ran a fake portal that got victims to paste a raw JSON payload containing an active access token, and that was enough to get around passwords and MFA. From there it tried to create more API keys and enable services in the victim's cloud projects, and it ran up more than $100,000 in charges.

The detail I'd pay the most attention to is this one: "In multiple incidents that Mandiant investigated, LLM services were not enabled at the time of compromise." So if you're thinking you don't use Bedrock and this isn't your problem, the attackers can enable it for you, and the bill still lands on your account.

Where the stolen access goes

GTIG says the stolen access gets resold through what it calls LLM Mixers, gateways that pool stolen keys. UNC6993 used open-source tools like new-api and gcli2api. Another actor made more than 500,000 API calls in under eight hours to power a token service called Jet Night (jet-night[.]com), which passed nearly one million dollars in token costs to one victim. Jet Night sells an unlimited plan for about $60 a month, against the $100 to $250 that kind of usage would normally cost, and GTIG believes that price only works because stolen keys mean someone else is paying the real bill. GTIG also lists newapi[.]pro as an LLM Mixer.

GTIG expects attackers to increasingly prioritize LLMJacking over older resource theft like cryptojacking, which seems likely to me. Model tokens are easier to resell than stolen CPU time.

The LiteLLM part, and a CVE that doesn't match

GTIG describes a follow-on cluster that acquired pre-validated LiteLLM virtual keys from the group that broke in and then used a "user ID rebind" bug to turn those ordinary keys into full PROXY_ADMIN credentials. That's a /key/regenerate bug (GTIG labels it CVE-2026-40217; that ID's public record describes a different LiteLLM bug). NVD and GitHub's advisory assign CVE-2026-40217 to a sandbox escape in LiteLLM's /guardrails/test_custom_code endpoint, which allows code execution and needs a proxy-admin credential in default setups. I don't know whether GTIG's label is a typo or something else, so I'm naming the bug by what it does and the fix by version.

The regenerate bug itself was real. LiteLLM's fix (PR #27793, backported in PR #27819) says a non-admin caller could rebind their own key's user_id through /key/regenerate and end up with PROXY_ADMIN. The first release with that fix is 1.84.0, from May 14, 2026. LiteLLM's 1.84.0 release notes list the fix, but there's no advisory or stated affected range, and I couldn't find a CVE for it. The current stable release is 1.106.6. Don't land on 1.107.0, which was the trojanized build I covered in the LiteLLM PyPI trojan brief.

If you run LiteLLM older than 1.84.0 (the first release whose notes list the fix) and hand virtual keys to people who aren't admins, treat this as a Panic Meter 4 for you. Anyone holding one of those keys may be able to make themselves an admin, and the fix has been out since May.

If you read my Oct 22 brief on exposed AI endpoints, this is the other half of the same business. That one was about attackers scanning for model servers left open on the internet, and this one is about attackers walking in with stolen cloud keys.

John Hultquist, chief analyst at Google Threat Intelligence Group, summed up the stakes to The Register: "Locking down these resources will not only protect organizations from runaway costs, but also protect the broader community from a deluge of cheap, autonomous attacks."

What to do:

Upgrade LiteLLM to 1.84.0 or later, and preferably to 1.106.6.
- Why: 1.84.0 is the first release with the /key/regenerate rebind fix GTIG describes, per its release notes, and 1.106.6 is the current stable release, which is above the fixed versions in LiteLLM's other published advisories too.
- How: run pip show litellm or check your image tag, then pin to a current release. Skip 1.107.0, the trojanized build covered in the LiteLLM PyPI trojan brief.
Check who holds PROXY_ADMIN in LiteLLM and which keys changed owner.
- Why: the rebind bug let a normal key point at an admin user, so the key kept working but carried admin rights.
- How: list users with proxy_admin, look for virtual keys whose user_id points at an admin they weren't issued to, and regenerate any you can't explain. This is my suggestion from the fix PR, not LiteLLM guidance.
Alert when AI services get enabled or new keys appear.
- Why: in several of Mandiant's cases the LLM services were not enabled at the time of compromise, and UNC6993 tried to create keys and enable services in victims' projects.
- How: my suggestion, not GTIG's exact list. In GCP, alert on ServiceUsage.EnableService for aiplatform. In AWS, alert on PutUseCaseForModelAccess, CreateFoundationModelAgreement and new access keys or users. In Azure, alert on Microsoft.CognitiveServices/accounts/deployments/write.
Set budget alerts and per-model quotas on every cloud account.
- Why: charges topped $100,000 in a day, and some organizations reached $1 million before access was cut.
- How: create a billing budget with alerts on each account, set quotas per model, and cap or deny premium models where nobody needs them.
Block LLM APIs for roles and projects that don't need them.
- Why: GTIG recommends least privilege "including access to Cloud LLM services".
- How: use AWS SCPs, GCP org policies or Azure Policy to block Bedrock, Vertex and Azure OpenAI outside approved projects.
Get keys out of repos and watch for one-token pings.
- Why: stolen tokens, including GitHub PATs, are the main way in, and attackers check stolen keys with max_tokens=1 requests that stay under volume alerts.
- How: turn on secret scanning and push protection, rotate anything that was ever committed, and alert on bursts of very small requests from new IPs or keys in your gateway logs.
Tell staff that no real service asks them to paste a token.
- Why: UNC6993's fake portal collected pasted access tokens and got around passwords and MFA.
- How: say it plainly in your next security reminder, use phishing-resistant MFA like FIDO2 or passkeys, and keep session lifetimes short.
Don't route work through cheap third-party LLM relays.
- Why: GTIG ties services like Jet Night to stolen keys, and a relay sees every prompt and response you send through it.
- How: use model providers directly or a gateway you run yourself.

Sources

← All briefs

Attackers are running AI models on stolen cloud accounts, and the victims get the bill

How they get in

Where the stolen access goes

The LiteLLM part, and a CVE that doesn't match

Want the next one?

Sources

Related

On the checklist

More briefs