AI Gateway Exploitation: How Attackers Are Targeting LiteLLM, RAGFlow, and Kestra to Steal Your Model Provider Keys

AI gateway exploitation means attackers break into the tools that sit between company applications and AI model providers. They then steal the provider keys stored there. This post covers LiteLLM, RAGFlow and Kestra. CISA added the LiteLLM flaw CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 8, 2026. Fixed versions exist for all three tools.

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. This layer is made of the gateways, orchestration platforms, and retrieval engines that sit between company applications and model providers. Three platforms are at the center of this shift: LiteLLM, RAGFlow, and Kestra.

The strategic logic of this shift is simple. An AI gateway concentrates every model provider API key, every database connection string, and every configured secret in a single process. These cover a firm’s entire LLM infrastructure. 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 goals. They share a common pattern. Public-facing AI infrastructure parts were deployed without network-level access controls, or were treated as lower-security tooling. They then became entry points for credential theft, lateral movement, and resource hijacking.

Why Is AI Gateway Exploitation 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 several kinds of secrets:

• API keys for every model provider the firm uses.
• Database connection strings for its configuration and virtual key storage.
• 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 at once, without any lateral movement or privilege escalation. When the gateway runs on a hosting platform, those values also sit with the platform, which is what the Railway security incident of October 2026 put at risk.

The Single Point of Failure Problem

Security architecture principles stress removing 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. It creates exactly the high-value concentrated target that advanced attackers prioritize. Brandefense’s INT-2608-e7a5 review recommends that firms treat AI gateways as Tier-0 infrastructure. They should get the same security controls as identity providers and certificate authorities. The typical current state is a major and growing company risk. AI gateways are deployed as development tooling, with internet-facing exposure and default configurations.

LiteLLM: CVE-2026-42271 Chained With CVE-2026-48710 (CVSS 8.8 and 6.5, scored separately)

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. This makes it the highest-value target in the AI infrastructure layer. A separate attack in October 2026 shipped LiteLLM 1.107.0 with a credential stealer; see our LiteLLM 1.107.0 response checklist.

Root Cause: Subprocess Injection via MCP Test Endpoints

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

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. The attacker manipulates the Host header so that it satisfies the middleware’s pattern matching without matching a legitimately trusted host. When this bypass is applied to LiteLLM’s authentication middleware, the API key verification step is skipped.

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.

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

RAGFlow’s MinerU parser processes uploaded ZIP archives without validating file path parts 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.

Stage 2: Startup Hook Injection for Persistent Credential Harvesting

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

The hook overwrites an application module that executes during service initialization. It therefore runs again every time the RAGFlow service restarts. It captures any provider credentials configured through the application’s normal interface.

This creates a persistent intelligence collection method 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 major. 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 give ongoing access to models, quota, and any company 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. Attackers did not exploit a parsing vulnerability or injection point. They used a fundamental logic error in Kestra’s authentication filter implementation.

Root Cause: One Line, Maximum Severity

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

Docker Socket Escalation: From Container Root to Host Compromise

Kestra’s official docker-compose.yml is the deployment setup most production users adopt. It mounts the Docker daemon socket (/var/run/docker.sock) into the Kestra worker container. CVE-2026-49869 grants root access inside the worker container. 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 therefore direct.

The Professionalization Signal: AI-Assisted Malware Development

Payload analysis across all three campaigns found a pattern that Brandefense attributes to AI-assisted development in the malware tooling. It has four traits:

• Robust cross-platform error handling.
• Organized and commented imports.
• Modular function structure designed for portability.
• Consistent variable naming conventions across all campaign artifacts.

Humans write traditional malware under time pressure. It often shows signs of haste: inconsistent style, minimal error handling, hardcoded values, and poor documentation. The payload files found in the LiteLLM, RAGFlow, and Kestra campaigns show the opposite. They have a clean style, full try/except blocks, and descriptive comments. These suggest either an advanced team or AI-augmented development. This professionalization greatly 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 right response.

Indicators of Compromise (INT-2608-e7a5)

What Should You Do Now, and How Do You Detect It?

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

Patch Status

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 parts. 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, set up 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

How Brandefense Detected and Tracks This Campaign

Brandefense produced the intelligence behind this analysis (INT-2608-e7a5). It came from monitoring underground forums, analyzing attack infrastructure, and correlating with technical vulnerability research. This intelligence was delivered to Brandefense platform subscribers as operational intelligence before it appeared in public threat reporting.

RELATED READING

From Shadow IT to Shadow AI: Clawdbot (Moltbot/Openclaw) and the Rise of Unmanaged Agent Gateways: 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: 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?: 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: the visibility gap that keeps AI gateways outside the asset inventory in the first place.