Google Threat Intelligence Group (GTIG) and Mandiant published research on “LLMjacking”: attackers who get hold of an organization’s cloud credentials or LLM API keys and use its AI accounts at the victim’s expense. In the incidents Mandiant investigated, fraudulent charges passed $100,000 in a single day and reached $1 million cumulatively at some organizations before access was revoked. Google says that, unlike the slow resource drain of cryptojacking, the bill can spike within hours.
Entry points were mostly ordinary cloud identity failures: exposed or stolen IAM credentials, service account keys, GitHub personal access tokens and active session tokens, plus LLM API keys harvested from public GitHub repositories. Google describes a cluster it tracks as UNC6993 that used a fake application portal to trick users into pasting a raw access-token payload, bypassing passwords and MFA. Stolen access is then resold through “LLM mixer” services that relay customers’ prompts through hijacked keys. In one case Google describes, a single actor made more than 500,000 API calls in under eight hours through the token-routing service jet-night.com, which Google says passed nearly one million dollars in token costs to the victim organization. Google also reports attackers enabling LLM services that were switched off at the time of compromise, creating extra API keys, requesting GPU quota increases, and hosting their own proxy endpoints on victim infrastructure.
Google also describes an attack on the victim’s own LiteLLM gateway: after getting pre-validated virtual keys, a follow-on actor abused a user-ID rebind flaw in the /key/regenerate endpoint, CVE-2026-40217, to turn standard keys into proxy-admin credentials.
How to check if you’re affected
Affected products are cloud accounts where LLM services (for example Bedrock or the Gemini API) are reachable with long-lived keys or broad service-account permissions, and self-hosted LiteLLM gateways. Google’s detection guidance, as written in its report, is to treat any unauthorized enablement of an LLM service in your cloud accounts as a critical event, because in several Mandiant cases the services were not enabled until the attacker turned them on. Practical checks that follow from the report:
- Review your cloud audit logs for new access keys, new service accounts, new IAM users, SSH keys added to project or instance metadata, and newly enabled LLM services you did not approve.
- Look in model-gateway and API logs for very small test requests (the report mentions
max_tokens=1pings) from sources you do not recognize. - Set per-model API quotas and spending caps so a stolen key cannot generate an unbounded bill.
- Scan code repositories for committed API keys and rotate any you find; Google also recommends phishing-resistant MFA, least-privilege roles that exclude LLM services unless needed, and outbound allow-listing.
- If you run LiteLLM, check whether your version includes the fix for CVE-2026-40217. Obsidian Security’s disclosure timeline lists the fix as completed in v1.83.10-stable, released 22 April 2026; confirm against the LiteLLM release notes for your deployment.
Sources
- LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources — Google Cloud Blog
- Google: LLMjacking attacks rack up $1 million in cloud AI charges — BleepingComputer
- Google Warns LLMjacking Attacks Are Costing Some Enterprises Up to $1 Million in Cloud Charges — The Hacker News
- Breaking LiteLLM: From Low-Privilege User to Admin and RCE — Obsidian Security