CISA's exploited-vulnerabilities list now includes LiteLLM, Kestra and Starlette

What happened

CISA added seven CVEs to its Known Exploited Vulnerabilities (KEV) catalog in the second week of September 2026, according to a post on dev.to. Three of them affect software that is now common in self-hosted AI setups: LiteLLM, Kestra and Starlette.

KEV is not a theoretical watchlist. An entry means CISA has evidence that a vulnerability is being exploited against real targets. The same batch, per the post, also covered SonicWall SMA 1000 appliances, Sangoma Switchvox VoIP systems and JFrog Artifactory — conventional enterprise targets. The difference, the author argues, is that administrators of those products tend to know they are running critical infrastructure, while many people running LiteLLM treat it as a convenience layer.

The three flaws

The LiteLLM flaw is an unauthenticated admin endpoint that discloses the proxy's full configuration, including every provider API key it routes traffic for — OpenAI, Anthropic, Azure, Cohere and others. Because LiteLLM's entire purpose is to sit between applications and LLM providers, managing keys, rate limits and model routing, one unauthenticated request to the admin panel can expose all of those credentials at once.

Kestra received a remote code execution flaw in its workflow execution engine. Kestra has become popular for building AI pipelines, and the vulnerability allows arbitrary command execution through crafted workflow definitions — anyone who can submit a workflow to an exposed instance can take over the underlying server.

Starlette, the ASGI framework underneath FastAPI, has a server-side request forgery flaw that lets an attacker make the server issue requests to internal network resources. The post estimates that FastAPI is the default web framework for roughly 70 percent of self-hosted AI model servers, which means anyone serving a model through FastAPI is running Starlette underneath it.

The attack chain

The post lays out a consistent exploitation sequence against unpatched deployments:

1. Discovery through Shodan and Censys scans for default ports — LiteLLM on 4000, Kestra on 8080, FastAPI/Uvicorn servers on 8000 — frequently with no authentication configured.
2. Exploitation via the LiteLLM admin panel, a crafted Kestra workflow, or Starlette SSRF, yielding data exfiltration or code execution.
3. Credential harvesting. The first file attackers read, the post says, is /proc/1/environ, which holds every environment variable the container's init process started with. Because AI tooling documentation routinely shows secrets passed as environment variables, the file typically yields provider keys, database URLs and cloud credentials in plaintext.
4. Persistence through SSH authorized_keys entries, cron jobs or reverse shells.
5. Monetization: deploying a cryptominer such as XMRig, particularly on GPU-equipped hosts, or selling harvested keys into the resale market for stolen LLM credentials.

According to the author, the chain from initial scan to a working cryptominer takes under an hour against an unpatched, unauthenticated deployment, and only minutes with automated tooling.

Hardening recommendations

Patching the specific CVEs is step one, but the post argues it will not be enough, because the same deployment patterns recreate the same attack surface with the next set of bugs. The recommendations:

• Require authentication on every admin surface: LiteLLM's admin API key support, Kestra's role-based access control, or an authentication proxy in front of model servers that lack native auth.
• Move secrets out of environment variables into a secrets manager such as HashiCorp Vault, AWS Secrets Manager or Docker secrets.
• Where environment variables are unavoidable, run processes as a non-root user, keep /proc/*/environ unreadable to the application, and mount /proc with hidepid=2.
• Harden containers with dropped capabilities, read-only filesystems and no-new-privileges settings.

Why it matters

A KEV listing means active exploitation has been confirmed, not theorised. What makes these entries unusual is the target profile: components that act as central choke points for an entire AI stack, yet are often deployed with the care of a weekend project. A LiteLLM instance sees every prompt, response and provider key in an environment. A compromised Kestra server can rewrite workflows to exfiltrate data or pivot to every service it holds credentials for. FastAPI model servers frequently sit next to vector databases, RAG pipelines and internal knowledge bases. The operating assumption behind many of these deployments — that staying on a local network is protection enough — has already failed in production, per the post, and the scanners indexing these services do not distinguish between a homelab and an enterprise deployment.