Reported by 7 outlets

Hackers Target LiteLLM, RAGFlow and Kestra AI Infrastructure to Steal API Keys and Mine Crypto

hot0.0

Why this score

Breadth: 2.00 / 2.0 · 7 sources
Authority: 1.20 / 2.0 · best outlet weight
Severity: 5.00 / 5.0 · CVSS + KEV signals
Velocity: 0.00 / 2.0 · updates in 48h
Pickup speed: 0.00 / 0.6 · time to second source
Recency: × 0.00 temporal multiplier
Community: + 0.00 / 1.5 · reddit signal
Score: 0.0 / 10 = base × recency + community

cyberpress.orggithub.comostif.orghorizon3.aicisa.govmicrosoft.comgbhackers.com CVE-2026-42271 CVE-2026-48710 KEV desk first seen 48d ago

Desk analysis

Microsoft Threat Intelligence documented three real intrusions, not proofs of concept: a LiteLLM gateway, a RAGFlow deployment, and a Kestra workflow environment, each ending in credential theft and persistence, with XMRig mining on LiteLLM and Kestra (v6.26.0 against a Monero pool) but not RAGFlow. In the LiteLLM case Microsoft assesses initial access through the public chain of CVE-2026-42271, command execution in the POST /mcp-rest/test/connection and /mcp-rest/test/tools/list endpoints of LiteLLM 1.74.2 through 1.83.6, and CVE-2026-48710, the Starlette BadHost host-header bypass affecting Starlette 1.0.0 and older, which strips the authentication gate entirely. The payload then read /proc/1/environ for provider keys and the master key, dumped the LiteLLM_VerificationToken and LiteLLM_ProxyModelTable tables from an Azure PostgreSQL backend using the harvested DATABASE_URL, wrote an SSH key to a service account, flagged payload directories with chattr +i, and ran XMRig with RandomX msr tuning. The Kestra intrusion is assessed as exploitation of CVE-2026-49869, a critical authentication bypass leading to workflow-origin bash execution and Docker socket enumeration; the RAGFlow case began with SSRF-style probing and ended with a monkey-patched TenantLLM.insert() capturing OpenAI, Azure, Anthropic, and Gemini keys on every new LLM configuration.

The argument to take from this is that a compromised AI gateway is a secrets breach with a compute bill attached: one exposed LiteLLM host yielded provider API keys, the master key, proxy-issued virtual keys, UI credentials, and the database connection string, so the blast radius covers every application routing through the proxy and every provider account those keys can spend. None of the tooling was novel. The LiteLLM advisory published April 21, Horizon3's unauthenticated chain writeup landed June 1, OSTIF's May 26 BadHost disclosure warned the flaw reaches FastAPI, vLLM, LiteLLM, and most OpenAI shim proxies, and CISA added CVE-2026-42271 to the KEV catalog on June 8, so the wave arrived roughly two to four months after public warning. Shared scanning node 45.150.109.151 appears in the telemetry across multiple targeted AI workloads, pointing to opportunistic scanning of internet-exposed management surfaces rather than bespoke targeting. Kestra's own June 3 advisory, GHSA-2q47-568g-9h4f (CVE-2026-53576, Critical 10.0), documents the same failure class reaching root: an anonymous caller creates and runs a workflow with a Process runner shell task in default deployments that mount /var/run/docker.sock, the exact access pattern Microsoft describes in this intrusion.

Patch LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later, or block POST /mcp-rest/test/connection and /mcp-rest/test/tools/list at the reverse proxy; move Kestra to 1.3.21 or 1.0.45 or newer and stop mounting docker.sock into orchestration containers. Keep gateway, retrieval, and workflow management surfaces off the internet, put the PostgreSQL tier behind a private endpoint, and rotate provider keys, the master key, virtual keys, and DATABASE_URL credentials for anything that was reachable. Hunt on the published telemetry: gateway ancestry (litellm, ragflow, kestra parent processes) spawning bash, python3, curl, or wget; command lines touching /proc/1/environ, LiteLLM_VerificationToken, or psycopg2; modprobe msr allow_writes; crontab rewrites, authorized_keys appends, and chattr +i. Network pivots: yosemite[.]jp, gobygo[.]net, oast[.]me, 45.150.109.151.sslip.io, raw-IP beacons on port 81, mining pool auto.c3pool[.]org:443, and the C2 pairs 135.125.10[.]56:19888 and 172.232.38[.]92:32991. Blockable file hashes include the /tmp/d ELF f64b88e9318bdf23f2dd119a0ce1dd1bdb3c8cd2e0e1e23ba3ef2e19072b79cc, XMRig samples 49fdcf32bfe837899a84e8938f0d07ae96ddd218a280a09eb60df8d64597bd8f and 3af9f25a4d45bb4f1ec5627cdbc6703cf3b4be75a892162d299d80ddfb266f42, and bridge installer 3d24ac736635e0fa0c5c459c9e18ca09d1ec9a1751a4503130934395609bd7e0.

Two developments would change this assessment. CISA adding CVE-2026-49869 or the RAGFlow candidates (CVE-2026-45312, CVE-2026-28797, CVE-2026-24770, CVE-2025-68700) to the KEV catalog would confirm the wave widened beyond LiteLLM into retrieval and orchestration tiers. A confirmed CVE assignment for the RAGFlow execution path also matters, since Microsoft states only low confidence on which flaw enabled code execution there; pinning the sink would turn the observed SSRF-then-RCE sequence, days apart against the same service, into a signature defenders can actually scan for.

Timeline

original reporting

Hackers Target LiteLLM, RAGFlow and Kestra AI Infrastructure to Steal API Keys and Mine Crypto

cyberpress.org · 47d ago · August 27th, 2026

Hackers are increasingly targeting AI infrastructure to steal API keys, gain access to backend systems, maintain persistence, and mine cryptocurrency . Microsoft has observed attacks against LiteLLM, RAGFlow, and Kestra three platforms that can hold sensitive model credentials, workflow permissions, database connections, and container access. AI gateways, retrieval platforms, and workflow orchestration tools have become high-value targets because they sit between applications, users, data sources, and large language models. A compromise can give attackers access to cloud credentials, provider API keys, internal services, and expensive computing resources. Hackers Hit AI Infrastructure In the LiteLLM case, attackers likely exploited an exposed gateway surface. Microsoft linked the activity to a possible chain involving CVE-2026-42271, a command-execution flaw affecting LiteLLM MCP stdio test endpoints, and CVE-2026-48710, a Starlette host-header validation bypass that could weaken authentication in affected setups. After obtaining execution, the attackers harvested environment variables from /proc/1/environ . These variables can contain model-provider API keys, LiteLLM master keys, database URLs, passwords, and access tokens. LiteLLM gateway compromise – attack chain (Source: microsoft) They also accessed a LiteLLM PostgreSQL database and collected model configuration and virtual-key records. The threat actors then downloaded payloads into temporary directories, used names tha
update from github.com

Authenticated command execution via MCP stdio test endpoints (GHSA-v4p8-mg3p-g94g, CVE-2026-42271)

github.com · 176d ago · April 21st, 2026

Maintainer-published LiteLLM advisory for CVE-2026-42271, rated High 8.7 (CVSS v4), affecting litellm >=1.74.2 and <1.83.7. The POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list endpoints spawned attacker-supplied commands as a subprocess with only a proxy API key required and no role check, so any low-privilege key holder could run commands on the proxy host. Fixed in 1.83.7 by requiring the PROXY_ADMIN role; the stated workaround is to block both endpoints at the reverse proxy.
update from ostif.org

Disclosing the BADHOST Vulnerability in Starlette

ostif.org · 141d ago · May 26th, 2026

OSTIF published expanded details on CVE-2026-48710, a host-header input-sanitization flaw in Starlette that bypasses authentication with a single character. OSTIF warned that slow uptake of patched Starlette versions and exposed live services were a serious concern, and that the bug hits a wide swath of Python LLM infrastructure including FastAPI, LiteLLM, vLLM, most OpenAI shim proxies, MCP servers, agent harnesses, and model-management UIs.
update from horizon3.ai

CVE-2026-42271 Chained with CVE-2026-48710: LiteLLM Unauthenticated RCE

horizon3.ai · 134d ago · June 1st, 2026

Horizon3 researchers validated that CVE-2026-42271, originally disclosed as authenticated command injection in LiteLLM's MCP test endpoints, can be chained with CVE-2026-48710 (Starlette BadHost bypass, dependency tree including Starlette 1.0.0 or older) for unauthenticated remote code execution on LiteLLM 1.74.2 through 1.83.6, assessing the chain as CVSS 10.0. Their timeline records the April 20, 2026 disclosure of CVE-2026-42271, the May 8, 2026 fix in LiteLLM 1.83.7, the May 26, 2026 BadHost disclosure, and their June 1, 2026 validation.
update from github.com

Unauthenticated RCE via /configs path-suffix auth-filter bypass (GHSA-2q47-568g-9h4f, CVE-2026-53576)

github.com · 133d ago · June 3rd, 2026

Kestra's Critical 10.0 advisory for CVE-2026-53576: the REST API authentication filter treated any request path ending in /configs as the public instance-config endpoint, so an anonymous caller could create a flow carrying a Shell task and trigger it, executing as root inside the Kestra container and pivoting through the /var/run/docker.sock mounted by the official docker-compose file. Affects Kestra OSS up to 1.3.20; patched in 1.3.21 and 1.0.45. Published June 3, 2026, crediting reporter Jan Kahmen of turingpoint.
update from cisa.gov

CISA Adds Two Known Exploited Vulnerabilities to Catalog

cisa.gov · 128d ago · June 8th, 2026

CISA added CVE-2026-42271, the BerriAI LiteLLM command injection vulnerability, to the Known Exploited Vulnerabilities catalog on June 8, 2026 based on evidence of active exploitation, alongside CVE-2026-50751, a Check Point Security Gateway improper authentication vulnerability. Federal agencies were given the standard KEV remediation deadline to patch or discontinue use.
update from microsoft.com

When AI infrastructure becomes the target: Securing gateways and control points

microsoft.com · 48d ago · August 26th, 2026

In this article AI workloads are becoming high-value control points Case study 1: LiteLLM gateway compromise Case study 2: RAGFlow compromise Case study 3: Kestra compromise Mitigation and protection guidance MITRE ATT&CK techniques observed References Learn more AI is creating a new layer of enterprise infrastructure. These systems concentrate credentials, data access, model connectivity, and execution privileges, making them some of the most powerful components in the AI stack. That concentration of trust is also creating new opportunities for attackers. The intrusion paths varied, but the objectives were strikingly similar. Attackers sought to steal credentials, establish persistence, and monetize compromised compute resources. The individual techniques matter, but the broader pattern matters more. Across these cases, attackers treated AI infrastructure as a control plane where credential theft, host compromise, and downstream data access can converge. As organizations continue to deploy AI systems, these platforms are becoming high value targets that deserve the same security scrutiny as other critical enterprise infrastructure.
update from gbhackers.com

Hackers Are Targeting AI Servers to Steal API Keys and Hijack Computing Power

gbhackers.com · 47d ago · August 27th, 2026

The appeal is clear. AI gateways often centralize OpenAI, Azure, Anthropic, Gemini, and other provider API keys; retrieval platforms hold […] The post Hackers Are Targeting AI Servers to Steal API Keys and Hijack Computing Power appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform .

Covered in

digest 2026-08-27