LLM Heist: Hijacking LiteLLM for Traffic Interception, Key Theft, and Tool-Call Injection

What it is

LLM Heist is a red-team technique against LiteLLM, an open-source AI gateway. It needs only a proxy-admin credential such as LITELLM_MASTER_KEY. The attacker rewrites where the victim gateway sends model traffic, so the victim's own gateway delivers its provider keys and every prompt and response to an attacker-run LiteLLM instance. The post's author built a tool, llm-heist, to automate this, but is not releasing it widely. The post says the approach applies in principle to other AI gateways.

How it works

The attack uses documented management functionality, not a vulnerability. Two settings are changed through /model/update:

• api_base is set to the attacker's gateway.
• use_litellm_proxy is set to true, which makes the victim forward to another LiteLLM instance.

Clients keep the same endpoint and virtual key, so developer machines need no changes. The sequence is:

1. Harvest. The victim resolves the real provider key and sends it in the Authorization: Bearer header to the attacker. A custom auth hook on the attacker's gateway records the header and returns a canned response, so clients briefly get bad answers.
2. Provision. The attacker creates model endpoints on their own gateway using the captured api_key.
3. Hijack. The victim's routes are pointed at the attacker. The attacker now forwards real traffic and sees requests and responses.
4. Inject. The async_post_call_success_hook and async_post_call_streaming_iterator_hook callbacks rewrite responses. The post demonstrates injected text and a forged Bash tool call in Claude Code.

The forged tool call is created after inference, so prompt-level defenses never see it. In the demo, the call ran in Claude Code under yolo mode. It does not bypass client-side tool approval otherwise. With HTTPS, the key is visible once the attacker terminates TLS.

Preconditions / Affected

• The attacker needs the master key or an equivalent proxy-admin credential, plus network reach to the admin API. The post names leaked .env files, deployment manifests, secrets in source control, exposed admin UIs with weak authentication, and weak or badly distributed master keys.
• Code execution on the gateway is not assumed, because it would expose provider keys directly. The post lists unpatched instances as another route in: the March 2026 PyPI package compromise that shipped a credential stealer, an Obsidian Security chain from low-privilege user to administrator, and CVE-2026-42271 (authenticated command execution on the host, added to CISA's KEV catalog).
• Monitoring intercepted traffic on the attacker side polls /spend/logs, which needs store_prompts_in_spend_logs: true. This is off by default but can be set on a proxy the attacker owns.

What to do

Detections and mitigations from the post:

• Alert on changes to api_base and use_litellm_proxy, and on new callbacks or guardrails. While a reroute is active, /model/info and the victim UI show the changed api_base.
• Rotate provider keys automatically and regularly.
• Forward gateway audit logs to a SIEM.
• Restrict gateway egress, and restrict provider keys to approved gateway IPs.
• Lock down SSH and admin interfaces, and reconsider exposing LiteLLM to the internet.
• Reconcile provider billing, since independent use of a harvested key produces charges. Set spend limits.
• Patch the host and LiteLLM.

Red-team test cases: find gateways, hunt for admin and master keys (source control, docs, tickets, manifests, CI/CD variables), check whether unpatched instances or the admin API are reachable from networks that should not reach them, and check whether anyone notices a reroute.

Caveats

• The demo ran over HTTP in a lab, and only response modification was shown. The post says the same point could alter requests too.
• The post proposes prompt and response signing by AI labs to detect a gateway in the middle, but this does not exist yet.
• The post gives no LiteLLM version boundaries beyond the named incidents and CVE.