CISA added seven CVEs to the Known Exploited Vulnerabilities catalog in the second week of September 2026. Three of those target infrastructure that anyone running self-hosted AI has probably deployed: LiteLLM, Kestra, and Starlette. If you are running an AI proxy, an orchestration engine, or a FastAPI-based model server, your stack is now on the same federal vulnerability list as SonicWall and Sangoma appliances.
The difference is that SonicWall admins know they are running critical infrastructure. Most self-hosters running LiteLLM do not.
CISA's KEV catalog is not a theoretical risk list. Every entry represents a vulnerability that has been confirmed exploited in the wild. Adding something to KEV means CISA has evidence that attackers are actively using it against real targets.
The September additions include CVEs targeting SonicWall SMA 1000 series appliances, Sangoma Switchvox VoIP systems, and JFrog Artifactory. Those are familiar enterprise targets. The three that should concern the AI self-hosting community are different.
LiteLLM picked up a CVE for an unauthenticated admin endpoint that exposes the proxy's full configuration, including every API key it routes traffic through. LiteLLM is an AI gateway proxy. Its entire purpose is to sit between your applications and LLM providers, managing keys, rate limits, and model routing. A single unauthenticated request to the admin panel dumps every provider key the proxy knows about. OpenAI, Anthropic, Azure, Cohere. All of them.
Kestra caught a CVE for a remote code execution flaw in its workflow execution engine. Kestra is a workflow orchestration tool that has become popular for building AI pipelines. The vulnerability allows arbitrary command execution through crafted workflow definitions, which means an attacker who can submit a workflow to your Kestra instance owns the underlying server.
Starlette has an SSRF vulnerability that allows attackers to make the server issue requests to internal network resources. Starlette is the ASGI framework underneath FastAPI, which is the default web framework for roughly 70% of self-hosted AI model servers. If you are serving a model through FastAPI, you are running Starlette.
Once an attacker gets code execution on an AI infrastructure server, the first file they read is /proc/1/environ. This file contains every environment variable that was set when the container's init process started. For AI infrastructure, that almost always includes API keys.
$ cat /proc/1/environ | tr '\0' '\n'
OPENAI_API_KEY=sk-proj-abc123...
ANTHROPIC_API_KEY=sk-ant-api03-xyz...
LITELLM_MASTER_KEY=sk-litellm-master...
DATABASE_URL=postgresql://admin:password@db:5432/litellm
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
This is not a hypothetical output. It is what researchers consistently find when they exploit these vulnerabilities in lab environments that mirror real deployments. The pattern is the same every time: API keys, database credentials, cloud provider secrets, all sitting in plaintext in the process environment.
Docker Compose files and Kubernetes manifests routinely pass secrets as environment variables because the documentation for every AI tool shows it that way. The LiteLLM quickstart guide tells you to export your API keys as environment variables. So does the RAGFlow setup guide. So does every Ollama + Open WebUI tutorial on YouTube.
The security model for these deployments is "it is on my local network, so it is fine." The CVEs now in the KEV catalog prove that this assumption has failed in production.
The attack pattern researchers have documented against self-hosted AI infrastructure follows a consistent sequence.
Step 1: Discovery. Shodan and Censys scans for default ports. LiteLLM runs on port 4000 by default. Kestra on 8080. FastAPI/Uvicorn model servers on 8000. None of these default configurations require authentication.
Step 2: Exploitation. Unauthenticated admin panel access (LiteLLM), crafted workflow submission (Kestra), or SSRF to internal services (Starlette). The attacker gets either data exfiltration or code execution, sometimes both.
Step 3: Credential harvesting. Read /proc/1/environ. Dump the database if credentials are available. Exfiltrate every API key the service knows about.
Step 4: Persistence. Write an SSH public key to ~/.ssh/authorized_keys. Drop a cron job. Install a reverse shell. Standard post-exploitation, nothing AI-specific about this step.
Step 5: Monetization. Two paths. The first is deploying XMRig or another cryptocurrency miner on the compromised host, especially if it has a GPU. The second is selling the harvested API keys, which feeds directly into the LLMjacking economy where stolen Claude and OpenAI keys are resold on Telegram.
The entire chain from initial Shodan scan to working cryptominer takes less than an hour against an unpatched, unauthenticated deployment. Automated tooling cuts it to minutes.
Here is the conceptual problem with how the self-hosting community treats AI infrastructure.
Your LiteLLM proxy is not a convenience layer. It is a Tier-0 control plane. Every API call from every application in your environment routes through it. Every provider API key is stored in it. Every prompt, every response, every tool call passes through its request pipeline. If an attacker owns your LiteLLM instance, they own your entire AI stack.
Kestra orchestrating your AI workflows is not a cron replacement. It is a workflow execution engine with the ability to run arbitrary code, make network requests, and interact with every service in your pipeline. An attacker who compromises Kestra can modify your workflows to exfiltrate data, inject malicious prompts, or pivot to any service that Kestra has credentials for.
Your FastAPI model server is not a dev tool. It is a production endpoint serving inference requests, potentially with access to vector databases full of proprietary documents, RAG pipelines connected to internal knowledge bases, and function-calling capabilities that interact with real systems.
The disconnect is that people deploy these components with the operational posture of a personal project and the access level of critical infrastructure. No authentication on the admin panel because "it is behind my firewall." No secrets management because "environment variables are fine for dev." No monitoring because "who is going to attack my homelab."
The attackers scanning Shodan do not know or care that you think of it as a homelab.
Patching the specific CVEs is step one. It is not sufficient. The pattern will repeat with the next set of vulnerabilities because the underlying deployment practices create the same attack surface every time.
Authentication on everything. No unauthenticated admin panels. No "internal only" endpoints exposed without at least basic auth. LiteLLM supports API key authentication for its admin interface. Use it. Kestra supports role-based access control. Enable it. Put your model servers behind an authentication proxy if they do not support auth natively.
Secrets out of environment variables. Use a secrets manager. HashiCorp Vault, AWS Secrets Manager, even Docker secrets are better than export OPENAI_API_KEY=sk-... in a compose file. If you must use environment variables, at minimum ensure /proc/*/environ is not readable by the application user. Run the process as a non-root user. Mount /proc with hidepid=2 to prevent cross-process environment snooping.
services:
litellm:
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
read_only: true
tmpfs:
- /tmp
Network segmentation. Your AI proxy should not be on the same network segment as your database server, your NAS, or your home network. VLAN isolation at minimum. A dedicated subnet for AI infrastructure with explicit firewall rules governing what can talk to what. The Starlette SSRF vulnerability is dangerous specifically because it lets an attacker pivot from the AI server to internal network resources. Segmentation limits the blast radius.
Monitoring that actually alerts. Log every admin panel access. Alert on authentication failures. Monitor for new SSH keys in authorized_keys files. Watch for unexpected outbound connections, especially to mining pools or Telegram API endpoints. If your AI server suddenly starts making requests to xmr.pool.minergate.com, you want to know about it before your electricity bill does.
Container isolation. Run AI services in containers with minimal capabilities. Drop all Linux capabilities and add back only what the application actually needs. Use read-only root filesystems. Mount volumes as read-only where possible. This does not prevent exploitation, but it makes persistence harder and limits what an attacker can do after initial access.
The operational standard should match the access level. If your AI proxy has API keys worth thousands of dollars and access to every prompt your organization sends, it deserves the same security posture as your database server. Not your side project's docker-compose.
If you want production-ready deployment configs for AI agent infrastructure with security baked in, I put together 25 YAML configurations at numbpilled.gumroad.com/l/openauto. Covers container hardening, network isolation, and monitoring for multi-agent deployments.