· via dev.to (home feed)
Microsoft documents real-world attacks on LiteLLM, RAGFlow and Kestra AI gateways
Microsoft Security Research documents in-the-wild compromises of LiteLLM, RAGFlow and Kestra that stole model API keys, deployed XMRig miners and planted persistence in AI infrastructure.

What happened
Microsoft Security Research has documented real-world compromises of three platforms that commonly sit in the middle of LLM deployments: the LiteLLM gateway, the RAGFlow retrieval system and the Kestra workflow orchestrator. According to a dev.to summary of the report, attackers who reached these internet-exposed management planes stole model provider API keys, database credentials and virtual keys, ran XMRig-based cryptominers and established persistence inside the compromised containers.
The connecting thread is that these systems are hubs for secrets. They hold model keys and database connection strings, and when Docker sockets are mounted they can also see the environment variables of neighbouring containers.
LiteLLM: environment harvesting and database exfiltration
In the LiteLLM compromises, Microsoft assessed the initial command execution as consistent with a chain of CVE-2026-42271 and CVE-2026-48710, though it did not confirm this definitively. Once inside, the attacker read /proc/1/environ, the environment of the container's first process, to collect provider API keys, the LiteLLM master key and the DATABASE_URL connection string.
Using python, curl and wget, the attacker dropped an ELF binary into /tmp, named it like a service and executed it. An XMRig-based miner was deployed and rival miners were removed. The stolen DATABASE_URL was then used to reach the LiteLLM PostgreSQL database and exfiltrate model configurations and virtual keys. Persistence was set up through the service account's authorized_keys file, cron jobs, hidden files and immutable attributes.
RAGFlow: a startup hook that keeps stealing keys
The RAGFlow intrusion began with an out-of-band application security testing callback originating from RAGFlow's own HTTP client, followed days later by code execution in the same service context. Microsoft declined to name the CVE behind the initial breach, even at low confidence.
The attacker planted a hidden Python hook under the application path to alter startup and import behaviour, and wrapped RAGFlow's TenantLLM configuration handling so that API keys and model details for any provider registered after the infection were captured. Normal configuration operations continued throughout, which the report notes makes the compromise hard for regular AI users to notice.
Kestra: authentication bypass and Docker socket abuse
Microsoft assessed CVE-2026-49869, an authentication bypass, as the high-confidence initial vector in the Kestra case. A worker spawned a shell from a malicious workflow. Because the Docker socket was mounted, the attacker enumerated the Config.Env of other containers to gather potential cloud keys, database passwords and API tokens. XMRig was deployed, and outputs from follow-up scripts were stored in Kestra's own KV API.
What defenders should watch for
The report lists concrete indicators: shells, Python, curl or wget launched with AI service processes as their parents; execution from /tmp; references to /proc/1/environ; access to the Docker socket; and changes to authorized_keys, cron entries or application startup files. On the network side, defenders should watch for outbound traffic to OAST domains, command-and-control addresses, raw IPs and mining pools, including services such as sslip.io on non-standard ports. Cloud signals include abnormal model provider usage and billing, unusual connections to Azure Database for PostgreSQL, and odd Kestra workflow or KV operations.
Microsoft also lays out triage categories, separating scanning-only activity from confirmed application-origin execution, secret access, external exfiltration and persistence or resource abuse, so incident responders can judge how far an intrusion progressed.
Suggested mitigations include keeping management planes private behind authentication, patching and source IP restrictions; moving keys out of process environments into dedicated secret stores with least privilege; denying outbound traffic by default; mounting /tmp with noexec; and not exposing Docker sockets to these containers.
Why it matters
AI gateways and orchestration layers are becoming a security perimeter of their own. They concentrate some of the highest-value secrets in a modern stack, since model provider keys translate directly into billing, and a single unpatched CVE can yield provider credentials, database access and a foothold across the container environment. The RAGFlow case shows the damage can also be continuous rather than a one-time theft: keys registered after infection keep leaking until the hook is found. Teams running LLM infrastructure should treat these management planes like production control planes, patched, private and monitored for the process and network patterns described above.
- #security
- #llm
- #ai-infrastructure
- #cve
- #cloud-security