An exposed LiteLLM gateway hands over every key in PID 1's environment

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].