One file read carries the LiteLLM case. PID 1 inside the container is the service process, so `/proc/1/environ` is the gateway's configuration exactly as it was handed over at startup: provider API keys, master keys, and `DATABASE_URL` in one blob [2]. That last string is what turns a credential read into a credential inventory. With it, the attacker connected to LiteLLM's PostgreSQL and harvested and exfiltrated model configurations and virtual keys [5]. The keys your teams were issued through the gateway are in scope, not only the upstream keys the gateway holds for itself [22].
Read the confidence gradient before the mitigations. Microsoft evaluates the LiteLLM initial access as consistent with a chain of CVE-2026-42271 and CVE-2026-48710, while saying it is not definitively confirmed [1]. For RAGFlow it declines to name a CVE at all, even at low confidence [10]. Only Kestra gets a high-confidence vector, the authentication bypass CVE-2026-49869 [11]. That is one confident entry point across three platforms [25].
The RAGFlow tradecraft is the part worth studying. A hidden Python hook is placed under the application path to alter startup and import routes [8], and the TenantLLM configuration handling is wrapped so that any LLM provider registered after infection leaks its key [9]. Nothing visibly breaks; configuration operations keep working normally while new keys are stolen [15]. The detection signal there is outbound traffic that follows a key registration, not a file hash [16].
Kestra fails in a different direction. A malicious workflow spawns a shell in a worker [12], and a mounted Docker socket lets the attacker enumerate `Config.Env` of other containers for cloud keys, database passwords and API tokens [13]. Persistence, meanwhile, went to the service account's `authorized_keys`, cron, hidden files, and immutable attributes [6]. Immutable attributes mean your cleanup script exits zero and deletes nothing.
Microsoft's control list is four separate deployment decisions. Each lands on a specific step. Keeping the management plane private with authentication, patching and source IP restrictions removes the reach [19]. Moving secrets into a dedicated store instead of the process environment devalues the `/proc/1/environ` read [20][2]. Mounting `/tmp` with `noexec` breaks the drop of an ELF binary executed under a service-like name [21][3], but not the Python hook, which needs no temp file because it runs inside an interpreter that is already up [8]. Not mounting the Docker socket contains the Kestra pivot [21][13]. Default-deny egress is the expensive one, and also the one that stops mining pool and OAST traffic [21][24].
These observations only transfer to your deployment if the management plane is reachable from outside, keys sit in the process environment, `/tmp` is executable, the Docker socket is mounted, and outbound traffic is unrestricted [18]. The mining payload itself is the cheap part; an XMRig-based miner was deployed and competing miners removed [4], and in the Kestra case script output was parked in the platform's own KV API [14]. I would fix reach first and the environment block second, because `/proc/1/environ` and `Config.Env` are the same weakness read from two sides [2][13].
