LLMjacking is the theft of access to paid AI models. An attacker gets hold of an AI provider key, or cloud credentials that can call a hosted model, then uses or resells that access while the victim pays the bill. Sysdig’s threat research team described the attack under that name on May 6, 2024. In October 2026 it became routine.
Wiz’s “Black October” research, published October 30, 2026 and updated November 2 and 3, tracks incidents at 12 AI developer platforms in about a month; two stolen enterprise keys it traced ran about 800,000 and 1.7 million calls on Amazon Bedrock, which Wiz estimates likely cost over $100,000 at list price. Separately, a trojanized LiteLLM release stole provider keys on October 21.
Most of the defense comes down to where keys live and how far one stolen credential reaches, which is what our cloud penetration testing examines, from $6,800 with a free retest.
At a glance
| Question | Answer |
|---|---|
| What happened | Platform breaches, a poisoned Python package, malicious npm packages and phishing harvested AI provider keys and cloud credentials, which were then used for model access |
| Who is affected | Anyone who stored AI keys in an affected platform’s environment variables, installed LiteLLM 1.107.0 or tensorlake 0.5.144, or holds long-lived Bedrock or Gemini credentials |
| What to do | Revoke and reissue keys at the provider, rotate cloud credentials, scope keys, set spend alerts, keep AI servers off the internet |
| How to spot it | Model listing across regions, model calls from a new network or identity, billing changes and sudden spend |
What LLMjacking is and why attackers want AI keys
AI keys turn into money with almost no extra work: they can be used directly, sold, or plugged into a reseller offering cheap model access, and the bill goes to the key owner. In both Bedrock cases it investigated, Wiz says the token usage “resembles resold coding-agent traffic”. It links key-testing activity to two resale operations it calls “momo” (llm-routing.com) and Xingjiabi, while noting it cannot definitively tie either one to the original breaches or to the bulk abuse. Cloud credentials work just as well, because one AWS identity with Bedrock permissions can reach several model families.
Railway and OpenCode both said they believed attackers wanted keys for “distillation”, training a competing model on a stronger model’s output. TechCrunch notes skeptics who call that link unproven, so treat it as the platforms’ belief.
Black October: the AI developer platform breaches
| Platform | Incident date, per Wiz |
|---|---|
| Fireworks AI | October 6 |
| Andromeda | October 9 |
| Zeabur | October 14 |
| Lightning AI | October 15 |
| OpenCode | October 16 to 17 |
| Railway | October 20 |
| Warp | October 23 |
| CommandCode | October 28 |
| Northflank | October 30 |
| Brev (NVIDIA), added later | October 4 to 20 |
| Chainstack, added later | October 29 to 31 |
| Trigger.dev, added later | November 1 |
Wiz found no single vulnerability linking the incidents; entry points ranged from stolen credentials to build infrastructure, a third-party vendor and a legacy system. The common thread is what attackers looked for once inside: stored environment variables, especially ones that grant AI access.
Zeabur
According to Zeabur’s preliminary report, the attacker used AWS keys and admin tokens for a shared Kubernetes cluster that Zeabur had kept unencrypted in a private config repo. One token was created on January 10, 2024 with no expiry, the tokens were missed by an August rotation, and the cluster admin interface was reachable from the internet.
On October 14 and 15, 2026, the attacker read 3,218,965 environment-variable records covering 321,810 accounts, ran commands in 865 customer database services and signed in as root on 101 GCP servers. No alert fired during more than 16 hours of attacker activity; a user’s report started the investigation. Zeabur will shut down on December 31, 2026, which it calls an operational decision.
Railway
Railway’s preliminary report describes privilege escalation in its build infrastructure on October 20, then access to CI credentials, then decryption of a subset of customer environment variables. Railway puts the ceiling at 1.85% of workspaces with some variables possibly exposed. Railway rebuilt its builders as single-tenant, rolled its keys and notified upstream providers. Customers should rotate sensitive variables set before October 21, remove public network access to databases, and review GitHub and container registry audit logs.
OpenCode
Attackers reached an older system behind the hosted OpenCode Console and took the provider keys of 1.4% of Console users, according to TechCrunch. Some users saw charges in the hundreds of dollars, a few above $1,000. Anthropic and Google blocked the exposed keys; OpenAI is refunding. The open-source CLI was not affected.
The lesson across all three: a key works until the provider that issued it revokes it. Deleting the variable from a hosting dashboard does not stop someone who already copied it.
LiteLLM 1.107.0: the supply-chain route to the same keys
On October 21, 2026, a malicious LiteLLM 1.107.0 reached PyPI, and the Docker Hub and GHCR tags v1.107.0, latest, main-latest and main-stable pointed at compromised images. LiteLLM’s incident post gives the PyPI window as 11:39 to 13:23 UTC, with image tags fixed by 14:20; Wiz’s timings differ slightly. The bad images carry a valid signature from LiteLLM’s previous signing key, so a signature check alone does not prove an image clean.
According to Wiz Research, the package installs .pth and sitecustomize hooks that run on every Python start. The stealer takes browser, AWS, GCP and Azure credentials, OpenAI, Anthropic and Cohere keys, SSH and GPG keys, shell history and the provider keys in LiteLLM’s own database, and sends them to the lookalike domain www.litellm[.]dev. About 4.5 hours later, Wiz saw stolen AWS role credentials being validated and checked for Bedrock access, which it calls consistent with LLMjacking.
Root cause, per LiteLLM. In its October 23 root cause analysis, which it calls the canonical record, LiteLLM says an administrative key for an internal agent platform was committed to a public repository on May 27 and never revoked. On October 10 the attacker used that key to retrieve a GitHub organization owner’s GitHub CLI token from the platform’s API. With that token and two maintainers’ tokens, the attacker overrode branch protection, pointed the release workflow at a lookalike fork, passed the production approval gate and deleted workflow records. LiteLLM says its earlier theory that tokens leaked from internal deployment logs was inaccurate. Our CI/CD pipeline security guide covers the release-workflow controls involved.
Indicators (from Wiz): IPs 168.100.8[.]57 and 165.227.201[.]8, the file /tmp/.pc_once_72129118c59f5636c0bb, the environment variable PRIVCOLLECT_ACTIVE=1 and an X-Token exfiltration header.
What to do. Pin to 1.106.2, or a later release signed with LiteLLM’s new key (the first appeared October 24), and rebuild from scratch. If 1.107.0 ran on a host with internet access, LiteLLM says to assume exfiltration succeeded: rotate the host’s cloud role, every provider key in the LiteLLM database, the master and virtual keys and the database password, then search CloudTrail for identity checks (GetCallerIdentity) by the host’s role near the install time, and for that role’s credentials appearing outside your own network.
Other ways AI keys were stolen in October
tensorlake npm 0.5.144 (October 8)
Socket flagged tensorlake 0.5.144 eleven minutes after publication. A preinstall hook ran a worm at install time that stole npm and GitHub tokens, cloud, Vault and Kubernetes credentials, SSH keys, .env files, and Claude, Cursor, Kiro, Windsurf and Zed configurations and MCP files, then republished the victim’s own packages. Cleanup order matters: a persistent monitor watches the stolen GitHub token, and revoking the token while it runs can wipe the home directory. Remove the gh-token-monitor persistence first, then revoke.
Apex Accelerator npm packages (October 12)
Elastic Security Labs found @apexacc/cli, a fake AI coding assistant, and @apexacc/audit, a fake MCP “security audit” server, aimed at crypto founders. The CLI overwrites OPENROUTER_API_KEY and OPENROUTER_BASE_URL, so prompts and code reach the attacker while the tool still shows OpenRouter, and it registers a persistent rogue MCP server.
Google Ads phishing to a GCP takeover (October 20)
Wiz describes search ads leading administrators to a fake Google login that relayed credentials and MFA codes. The attacker enabled the Gemini API in existing low-usage projects, deleted the org policy restricting IAM membership to company domains and added external billing admins. Victims saw charges of tens to hundreds of thousands of dollars within 24 to 48 hours. Our GCP penetration testing guide covers the related org policy and IAM checks.
Exposed AI servers
The PoeLLM botnet, reported by Black Lotus Labs and covered by BleepingComputer on October 7, compromised more than 3,400 servers, including exposed LiteLLM and Ollama instances, to mine cryptocurrency rather than to steal keys, which shows how exposed these tools are. One of its exploits targets LiteLLM CVE-2026-42271, which has been in CISA’s Known Exploited Vulnerabilities catalog since June 8, 2026. Symantec’s report on a “Skynet mode” LLMjacking agent logged more than 127,000 honeypot requests, mostly model-endpoint reconnaissance and spraying of stolen keys. A model server without authentication is a free account for whoever finds it.
When the agent leaks the cloud credentials itself
In Zenity’s “AgentCorruption” research, published October 8, a prompt injection could lead an Amazon Bedrock AgentCore agent’s HTTP tool to fetch its own role credentials from the instance metadata service. The default execution role reached other agents, conversation history, container images and Secrets Manager across the account’s region. AWS says this is documented behavior and execution roles should get only what they need. Zenity found the default role substantially restricted by September 29, 2026. No CVE was assigned.
Wiz’s incident response team described an intrusion on October 19 whose confirmed entry points included an exposed Kafka UI, and which spread across AWS, GCP and Kubernetes with activity reaching “hundreds or thousands of actions per hour”. Microsoft also reported Storm-0940 using the ARTEX agentic AI framework to attempt sign-ins to more than 2,250 downstream customer tenants after the ConnectWise compromise, covered in our October 2026 exploited vulnerabilities roundup.
Our AWS penetration testing guide explains the metadata and IAM paths involved. Where agents run in a cluster, a Kubernetes penetration test, one cluster from $6,800, traces the path from a pod to the cloud account.
How stolen keys are tested, and how to spot it
Datadog Security Labs documented the checks attackers run on a stolen AWS key:
- An identity check to confirm the key works and which account it belongs to.
- Listing foundation models, region by region.
- Listing inference profiles.
- A tiny test prompt, capped at a few output tokens.
- Sometimes, a check of promotional billing credits.
Datadog also describes KMON_NOC, a credential-harvesting platform seen since August 31, 2026, which pulls out Bedrock API keys (AWS_BEARER_TOKEN_BEDROCK) separately.
Signals worth alerting on:
- Bedrock calls from a new network, or from an identity with no history of AI use.
- Model catalog enumeration across several regions.
- New long-term Bedrock keys with no expiry date.
- Service quota increase requests.
- On GCP: changes to the domain-restriction org policy, new external billing members, new Gemini API enablement and spend caps being hit.
Wiz lists these addresses as testing stolen keys between October 18 and 30: 23.106.46.239, 38.246.114.118, 104.243.32.50 and 31.57.201.201. Use them to start an investigation rather than as a blocklist.
What to do now
| Action | Why | Source |
|---|---|---|
| Revoke and reissue keys at the provider | Deleting a variable from a platform does not stop a copied key | TechCrunch |
| Rotate Railway variables set before October 21, and follow every other affected platform’s notice | Platform environment variables were the target | Railway |
| LiteLLM: pin a clean version, hunt the indicators, rotate host credentials and stored provider keys | 1.107.0 stole both | LiteLLM |
| tensorlake: remove the monitor, then revoke tokens | Revoking first can trigger a wipe | Socket |
| Scope Bedrock keys to the inference profiles and models you use, and alert on new long-term Bedrock keys and quota requests | Limits what a stolen key reaches and flags abuse early | Datadog and Wiz |
| Set spend caps and alert on cost surges for Gemini and Bedrock | Victims saw tens to hundreds of thousands of dollars in 24 to 48 hours | Wiz |
| Enforce IMDSv2 with a hop limit of 1 and restrict egress for AI workloads and agent tools | Blocks metadata credential theft and outbound abuse | Symantec |
| Keep model servers, gateways, Kafka UI and similar tools off the internet, with authentication on every endpoint | PoeLLM infected over 3,400 exposed servers | BleepingComputer |
| No long-lived admin tokens in repositories; alert on control-plane access | A never-expiring token let the Zeabur attacker in, and 16 hours of activity raised no alert | Zeabur |
Scoping alone is not enough: Wiz’s second Bedrock key was limited to US inference profiles and still ran about 1.7 million calls. The account-level controls underneath all of this are in our cloud security best practices.
How a cloud penetration test checks this
A test answers the question these incidents raise: if one key or workload is stolen, what can the attacker reach and spend? We check:
- Where keys live: repositories, CI variables, environment variables, images and PaaS dashboards, looking for long-lived keys and tokens with no expiry.
- Model access: which identities and keys can call hosted models such as Bedrock or Gemini, and how they are scoped.
- Org policies: domain restrictions and the project hierarchy.
- Agent sandboxes: whether metadata and credential endpoints are reachable from an agent’s tools, and what the role behind them can do, using benign requests.
- Pipelines: paths from CI to production credentials.
For a configuration review without exploitation, our cloud security assessment is a read-only review from $4,200. LLM gateways, agents and the applications built on them are covered by AI penetration testing, from $4,500. For the agent and MCP flaws disclosed the same month, see our Claude Code and MCP vulnerabilities roundup.
A cloud penetration test is fixed in writing before work begins: see what a cloud penetration test costs, from $6,800 for one account, with a free retest of what you fix.
Frequently asked questions
What is LLMjacking? Using someone else’s access to paid AI models, through stolen provider keys or cloud credentials. The attacker uses or resells the access, and the key owner pays.
What was “Black October”? Wiz’s name for the run of breaches at AI developer platforms in October 2026, including Zeabur, Railway, OpenCode, Fireworks AI and Warp. Attackers went after stored environment variables, especially AI provider keys.
Which LiteLLM version is safe? 1.106.2 was the last release before the malicious 1.107.0. LiteLLM has since published releases signed with a new key, starting October 24, 2026. Check LiteLLM’s incident post for the current list and key fingerprint.
Does deleting a leaked key from my hosting platform stop abuse? No. The key works until the provider that issued it revokes it. Revoke it with the provider, then issue a new one.
How can I tell if my Bedrock credentials are being abused? Watch CloudTrail for the identity check and cross-region model listing that usually come first, then for Bedrock calls from new networks or identities, new long-term Bedrock keys, quota increase requests and unexpected spend.
Fixed price, fixed scope, free retest. Scope your cloud penetration test and get the price in writing.
Written by
Invadel Team
Senior penetration testers writing from real engagements, the same team that scopes, tests, and reports for our clients. About Invadel →
