Hackers pull AI proxy keys straight out of memory

For 90 days Wiz Threat Research left a set of AI services exposed on the internet and watched what came for them. What arrived was not generic scanning. Attackers turned up knowing exactly which Python object holds a LiteLLM proxy's master key, and read it out of the running process rather than off disk, because on LiteLLM that key never touches a file.

Yaara Shriki set out the telemetry in Wiz's report, published on August 27, 2026, drawn from honeypots running LiteLLM, Flowise, LangChain, Langflow, ChromaDB, Ollama and Node-RED.

Why an AI proxy is worth more than a web server

A single LiteLLM proxy can hold keys for every model provider it routes to, and often runs with cloud IAM permissions and links to internal services, so one compromise reaches everything behind it. Agents are also built to accept outside input and act on it. Wiz's State of AI in the Cloud report found that 90% of cloud environments run self-hosted AI software, so this is not a niche surface.

A test button that runs whatever you type

The busiest entry point was CVE-2026-42271, a command injection in LiteLLM's MCP server test endpoints, added to CISA's exploited-vulnerabilities catalog in June 2026. Those endpoints let an operator check a tool server configuration before saving it, and the command field went straight to subprocess execution. Attackers submitted a fake configuration whose command field was a Python script: it fetched a ZIP from hxxp://185[.]62[.]1[.]8/mon/mon[.]zip, unpacked a Monero miner named gmon into /tmp/.dbus-cache/, launched it detached, then deleted the directory while the process kept running from the open file handle. The script also returned a valid handshake, so the connection test reported success. Wiz notes that external researchers have linked the Qilin ransomware group to exploitation of this chain, combined with a Starlette host header bypass, CVE-2026-48710, for unauthenticated code execution.

The honeypots also caught exploitation of CVE-2026-59822, an authentication flaw Wiz's own researchers found in LiteLLM's MCP gateway earlier this year, where a failed token check returns an unrestricted session object rather than a rejection. A one-character bearer token is enough.

Pings from an agent that should not ping

Against LangChain, Flowise, OpenWebUI and Node-RED, the honeypots logged what Wiz calls blind prompt injection: instructions buried in ordinary requests that tell the agent to run an operating system command whose only visible effect is a DNS lookup to an attacker-controlled callback domain. Wiz did not capture the prompt itself and says its published example is a reconstruction consistent with the observed process tree, not a recovered payload. Sessions that worked ended with XMRig dropped at /usr/src/node-red/xmrig, a path picked to blend into the Node.js process tree.

A miner hiding in a .claude folder

The camouflage is the detail defenders should sit with. On the Langflow honeypot an attacker staged a miner at /app/data/.claude/ and renamed the binary unicorn, because on a machine running AI tooling a .claude directory looks like it belongs there. The same sessions enumerated LiteLLM config paths and, on instances still using the default master key sk-1234, asked the proxy to name its own backend model, to decide whether to steal the key or just burn the inference quota.

Assume unauthenticated AI tools are compromised

Wiz's guidance is blunt: most of these tools ship with no authentication, so treat "unauthenticated on the internet" as "compromised". Inventory every AI service as production infrastructure, scope IAM permissions narrowly, block outbound egress where you can, and alert on process ancestry that makes no sense, such as an AI server spawning a shell. Wiz also argues that attackers on open-source AI infrastructure often move ahead of CVE assignment, weaponizing fixes as soon as they land in code, so waiting for a maintenance window is the wrong posture.

Indicators from the report, defanged: 185[.]62[.]1[.]8 and 94[.]26[.]106[.]29 for binary staging, 185[.]84[.]98[.]85 for miner command and control, and mining infrastructure at pool.hashvault[.]pro and crazyeltonproxy[.]top. On disk, /tmp/.dbus-cache/ and droppers at /tmp/x86_64 and /tmp/amd64.

The cryptomining is the least interesting part, since it is the cheapest thing anyone can do with a stolen server. What should worry defenders is that whoever built this tooling read the source of the software they were attacking, and knew where the keys live better than most of the teams running it. The bug count in AI tooling has climbed all year, and the attention has caught up.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Detection coverage

Read the full analysis on IntelFusions