LiteLLM Gateway Flaws Let Attackers Deploy XMRig on AI Infrastructure

Microsoft investigated three separate intrusions into AI infrastructure and found the same pattern in each: attackers went after the gateway, not the model. In the LiteLLM case, the entry point was the proxy that sits between your applications and model providers, and the process that gets compromised is the one holding your API keys.

The chain works in two parts. CVE-2026-42271 is an authenticated command-execution flaw in LiteLLM's MCP stdio test endpoints, which gives an attacker the ability to run commands in the gateway runtime. CVE-2026-48710, a Starlette host-header validation bypass, weakens the authentication boundary in affected configurations, so that command execution can be reached without valid credentials in exposed deployments.

Microsoft assesses with high confidence that initial access in the observed LiteLLM intrusion came through the exposed gateway surface, consistent with that chain. What follows is not subtle. The gateway service process itself becomes the parent for shell commands and Python one-liners, which then read the container environment, pull down a masqueraded ELF binary named to look like a Linux daemon, and start mining.

Attackers deployed

XMRig v6.26.0

with RandomX MSR tuning pointed at a Monero mining pool, consuming host CPU for attacker profit.

Related activity hit a Kestra workflow environment through CVE-2026-49869, a critical authentication-bypass vulnerability that lets an unauthenticated attacker define a malicious workflow using the Process runner and trigger worker-side shell execution.

Two things make this expensive for your organization. AI gateways concentrate model-provider keys, master keys, virtual-key records, database connection strings, and tenant policy in one runtime, so a single compromised process exposes credentials across every downstream application that routes through it. And mining workloads compete directly with inference for CPU, which shows up as degraded response times on the AI services your teams and customers depend on before anyone identifies the cause.

Attack Chain: From Gateway Misconfiguration to XMRig Installation

Once command execution lands inside the gateway process, the first thing the attacker reads is the process environment. In containerized LiteLLM deployments the proxy runs as PID 1, so /proc/1/environ holds the entire secret block for the service: model-provider API keys, the LiteLLM master key, the database connection string, UI credentials, and assorted tokens.

Microsoft's telemetry showed the payload reading that file and filtering for keywords such as master, key, token, and password before shipping the results out. Exfiltration ran through Python urllib, then curl, then wget in sequence, giving the operator fallback paths if one utility was missing or one egress method was filtered.

Payload delivery followed the same redundancy pattern. An inline Python command spawned by the gateway pulled a masqueraded ELF binary from attacker infrastructure, staged it under a temporary path, set the executable bit, and launched it with arguments resembling a Linux service manager. The staged file was named python3 and run with supervisord-style arguments. A second delivery path used a shell downloader with short timeouts, randomized staging paths under /tmp, and the same chmod-and-execute finish.

Stage three was reconnaissance from the second-stage binary. Observed commands fingerprinted the host, ran a silent passwordless-sudo check, inspected listening ports, and swept the process table for competing miners, remote shells, and previously dropped scripts. Attackers doing this are protecting their revenue, and the sweep is one of the most reliable behavioral tells that the intrusion has moved into monetization.

Mining preparation used two artifacts worth naming. The operator loaded the Linux Model-Specific Register module with write access enabled, a modprobe msr allow_writes pattern tied to RandomX CPU tuning, then rewrote crontab to strip entries belonging to rival miners before writing the modified table back. In the Kestra intrusion the miner was XMRig v6.26.0 pointed at the pool auto.c3pool[.]org, launched under nohup and renamed to defeat name-based matching.

The data-tier stage is what separates this from ordinary cryptojacking. A self-contained python3 one-liner re-read the PID 1 environment, parsed DATABASE_URL, imported or installed PostgreSQL support, connected to an Azure Database for PostgreSQL instance, and dumped LiteLLM_ProxyModelTable and LiteLLM_VerificationToken. Output was base64-encoded and pushed out in small chunks to an out-of-band callback endpoint. Those tables hold upstream provider key material, provider endpoints, and proxy-issued virtual keys, so the loss extends to every model account the gateway fronts and every downstream team holding a virtual key.

Persistence closed the chain: an authorized_keys write under a service account, hidden-file relay execution from dot-prefixed paths in /tmp, masqueraded systemd service names, self-relaunch loops, and chattr +i immutable attributes applied to payload directories to resist cleanup.

Network indicators from the campaign include beacons to raw-IP infrastructure on port 81, sslip.io DNS rebinding used to sidestep domain reputation checks, and OAST callbacks to yosemite[.]jp, gobygo[.]net, and oast[.]me. Host artifacts worth pulling in triage are the path fragments /private/python3 and /anonymus/bins_s, the BRIDGE_STANDALONE environment value on the staged binary, cron entries rewritten with a grep filter, and any process whose parent command line contains litellm, ragflow, or kestra but whose child is a shell, interpreter, or downloader. Mapped to ATT&CK tactics, the run covers Initial Access, Credential Access, Execution and Defense Evasion, Persistence, Command and Control, and Impact through resource hijacking.

Business and Operational Impact of Compromised AI Infrastructure

The clearest financial hit comes from your own model-provider accounts. Microsoft's telemetry showed that in the RAGFlow case, every LLM API key configured after infection was silently exfiltrated, giving the operator unauthorized use of provider accounts at their direction. Your usage bill keeps arriving as normal, and the consumption on it is not all yours.

The mining side of these intrusions charges you in a different currency. Kestra hosts ran XMRig v6.26.0 with RandomX MSR tuning against a Monero pool, consuming host CPU for attacker profit. On a workflow worker or an inference-adjacent node, that CPU is the same capacity your model routing, document parsing, and batch jobs depend on.

What your users see is latency. Requests that used to return in a predictable window start queuing, retrieval jobs stack up behind mining threads, and orchestration tasks miss their scheduled windows. If you have published response-time commitments to internal business units or external customers, sustained resource hijacking puts those commitments at risk, and the cause is not obvious from an application dashboard that only reports request volume.

Because the miner was launched with nohup to survive shell exit, the drain does not stop when a session closes or a job finishes. This is recurring theft of paid compute, running against your cloud bill every hour the payload stays resident. Organizations typically discover it through cost anomalies or performance complaints rather than a single alert, which stretches the billable window considerably.

Persistence widens that window further. In the RAGFlow intrusion, api/__init__.py was backdoored to load a hidden hook file on every service start, surviving container restarts. The reflex fix for a slow container, restarting it, does nothing here, and your team may believe the issue is resolved while credential interception continues.

For regulated environments, the exposure runs deeper than compute. The Kestra activity used the mounted Docker socket to enumerate Config.Env arrays across all running containers, collecting embedded cloud, database, and API secrets. A single compromised orchestration container therefore becomes a disclosure event covering every other workload sharing that runtime socket, which is a very different notification analysis than a single application breach.

Consider what actually flows through these systems. A gateway sees the prompts your staff and applications send, a retrieval platform holds the documents you indexed, and both may carry client records, case material, contract terms, or health data depending on your sector. If your regulator or your client contracts require you to identify what was accessible during a compromise, you need to be able to answer that question about prompt content and indexed corpora, not only about databases.

Then there is the cleanup cost. Microsoft observed payload directories made immutable with chattr +i to resist removal, SSH keys written to service accounts, and cron entries created for durable access. Remediation means rebuilding container images, rotating every provider key, virtual key, and database credential the runtime could reach, and reviewing provider billing for unauthorized consumption.

Those rotations have their own operational cost. Every application that authenticated through the gateway needs new key material, and any dependency you miss fails at the moment you cut the old credentials over.

Detection and Immediate Response Actions for LiteLLM Deployments

Start with process ancestry on every host running a LiteLLM gateway. Any shell, interpreter, or downloader whose parent is the gateway service process is worth treating as an incident until proven otherwise, because in this intrusion the gateway runtime became the parent for the entire follow-on chain. Microsoft's hunting guidance calls that relationship the earliest high-value pivot.

Within the first few hours, sweep for the specific artifacts the operators left behind rather than generic miner signatures:

• Command lines containing modprobe msr allow_writes, which loads the Model-Specific Register module with write access for RandomX CPU tuning and has almost no legitimate use on a production server.
• Executables staged under randomized temporary paths and launched with service-manager arguments, including /tmp/python3 invoked with supervisord-style parameters, /private/python3, /anonymus/bins_s, and the BRIDGE_STANDALONE environment value.
• Crontab rewrites that pipe through grep -v, the pattern used to strip competing miners before writing modified cron data back.
• chattr execution and append operations against authorized_keys under service accounts, which produced the durable access path in this case.
• Reconnaissance markers such as a silent passwordless-sudo check and listening-port inspection run from the gateway lineage.

Pair that with egress review. Look for outbound sessions to auto.c3pool[.]org, beacons to raw-IP infrastructure on port 81, hostnames resolving through sslip.io (used to sidestep reputation checks), and out-of-band callbacks to yosemite[.]jp, gobygo[.]net, and oast[.]me. A single match against gateway ancestry plus secret-access terms plus outbound traffic should be handled as a confirmed compromise.

Over the next day or two, apply the fixed releases listed in the vendor advisories for CVE-2026-42271 and CVE-2026-48710 across every LiteLLM instance, and for CVE-2026-49869 on any Kestra deployment you run. Patching alone does not undo credential exposure. Rotate the upstream provider keys, the master key, UI credentials, and the PostgreSQL connection string that the gateway process held, then revoke and reissue proxy virtual keys. Query your database audit logs for reads against LiteLLM_ProxyModelTable and LiteLLM_VerificationToken, and for connections that imported psycopg2 from an unexpected host.

Restrict the gateway while you do it. Move the backing database behind a private endpoint with firewall rules that permit only the proxy service account, and switch gateway egress to deny-by-default with an FQDN allowlist covering your model providers and nothing else. Block direct connections to raw-IP destinations and non-standard ports at the same control point. Management and admin interfaces should not be reachable from the internet at all.

For the longer term, record a normal CPU utilization baseline per gateway and worker node so mining shows up as a deviation instead of a user complaint. Mount temporary directories non-executable where your workloads tolerate it, and alert on any execution from world-writable paths. Log and inspect DNS so subdomain-encoded callbacks are visible. Because the payload targeted service-account keys and provider credentials, Adlumin watches authentication behavior against those accounts across environments Capstone manages, surfacing logins and key use that do not match the gateway's normal pattern. Issue per-team virtual keys with spend limits and hold upstream keys in a managed secret store instead of process environment variables.

Patching and Hardening LiteLLM Gateways Against Command Injection

Patch the exposed surface first. LiteLLM's CVE-2026-42271 and CVE-2026-48710 only produce unauthenticated code execution when they are chained, so applying the fixed release listed in the LiteLLM and Starlette project advisories for your deployed versions closes the path from both ends. Fixing one and deferring the other leaves either an authenticated execution primitive or a weakened authentication boundary in place.

The same patching discipline applies to the other two workloads Microsoft investigated. Kestra's CVE-2026-49869 is a critical authentication bypass that lets an unauthenticated attacker with network access skip the login mechanism entirely, define a workflow using the Process runner, and get shell execution on the worker. For RAGFlow, Microsoft did not attribute the intrusion to a specific flaw, but the publicly documented candidates covering the relevant versions are worth tracking against your build:

• CVE-2026-45312 and CVE-2026-28797, authenticated Jinja2 server-side template injection in the prompt generator and Agent workflow components.
• CVE-2026-24770, a MinerU parser path-traversal issue permitting arbitrary file overwrite and follow-on code execution.
• CVE-2025-68700, a Canvas CodeExec sandbox bypass tracked as GHSA-8xw3-v6c2-j84j.
• CVE-2025-69286, an account-access weakness that can make authenticated functionality reachable in some configurations.

Several of those require authentication, which matters for your prioritization. If a separate account-access weakness is also present in your version, the authenticated flaws become reachable by an outside attacker, and the practical exposure changes.

When a maintenance window is not available, cut the attacker's options inside the runtime. Run the gateway container with a read-only root filesystem and a writable path only where the application genuinely needs one. Drop CAP_SYS_ADMIN and any capability the proxy does not require, which removes the ability to load kernel modules for CPU tuning. Mount temporary directories with noexec where operationally feasible, and remove curl and wget from the gateway image so a staged downloader has fewer working retrieval methods.

Give the proxy its own dedicated service account with no interactive login and no shared credentials. Limit its PostgreSQL grants to the specific objects it queries, and place the database behind a private endpoint with restrictive firewall rules so a leaked connection string is not usable from arbitrary internet hosts. Issue per-team virtual keys with spend limits instead of distributing the master key, and hold upstream provider keys in a managed secret store rather than the process environment. If a gateway has been exposed, rotate every credential associated with it.

SentinelOne detects the dropper staging and second-stage execution described in these chains across managed environments, including files written to world-writable paths and binaries relaunched under service-style names.

Egress filtering is the control that limits damage after everything else fails. Apply deny-by-default outbound rules and allowlist only the model-provider and service endpoints your applications actually call. Block direct connections to raw-IP hosts and non-standard ports, route permitted traffic through an FQDN-filtering firewall or inspecting proxy, and log DNS so out-of-band callbacks and subdomain-encoded beacons are visible. A miner that cannot reach a pool earns nothing, and an exfiltration routine that cannot resolve its callback domain returns no keys.

Key Actions and Ongoing Vigilance

Microsoft's three investigations covered different products with different entry points, and the attacker objectives were the same in each: credential collection, durable access, and compute monetization. That consistency is the useful takeaway for you. If your organization runs a model gateway, a retrieval platform, or a workflow orchestrator, the risk does not depend on which vendor you picked.

Treat these systems by the role they play rather than by the application they run. A gateway that holds provider keys, a retrieval service that stores tenant model configuration, and an orchestrator with a mounted container runtime socket all concentrate the same kinds of assets in one runtime. Microsoft's guidance is to inventory your exposed AI management surfaces and restrict who can reach them administratively. That single step tells you how much of this pattern applies to you.

Two details are worth carrying forward. In the RAGFlow case, the outbound callback from possible SSRF-style probing arrived several days before code execution in the same service context, so the early signal and the compromise were separated by a meaningful gap. And several payloads across these intrusions showed organized imports, explicit timeout handling, and dependency fallbacks, which makes them more portable across Linux and container environments than typical one-off shell scripts.

Across all three workloads, telemetry showed credential collection, durable access mechanisms, and resource monetization, even though the execution path differed by product.

Assume some of your AI deployments may already be affected. Credential interception and gateway compromise produce no user-visible failure, and the first place the cost surfaces is your provider consumption and host CPU.