CISA adds exploited LiteLLM and Kestra flaws to KEV catalog as AI gateways become targets

CISA's exploited-vulnerability list now names AI components

On September 2, 2026, CISA added seven flaws to its Known Exploited Vulnerabilities (KEV) catalog, and two of them came from a relatively new corner of the enterprise stack: LiteLLM, an AI gateway that proxies requests to language model providers, and Kestra, a workflow orchestration platform. According to a dev.to analysis of the update, this was the first time AI infrastructure components showed up in the catalog as actively exploited targets, listed alongside the VPN and web-framework bugs that usually dominate such releases. A KEV entry means CISA has evidence that a flaw is being abused in the wild, and it carries patching deadlines for US federal agencies — a strong hint for everyone else to move quickly too.

What the two flaws allow

The LiteLLM issue is tracked as CVE-2026-59822, an improper authentication bug rated 8.8 on the CVSS scale. The Kestra issue, CVE-2026-49869, is an operating-system command injection carrying the maximum CVSS score of 10.0. Neither product is a classic perimeter appliance. As the dev.to post explains, both are application-layer services that organizations deploy to route model traffic and coordinate data pipelines, and that changes the stakes considerably: these systems routinely hold API keys for model providers, databases, and other downstream services. A successful attack can therefore yield a haul of credentials, not just a disrupted workload.

How much is actually reachable

To size the problem, the author queried the ZoomEye search engine on September 19, 2026, using service fingerprints. A query for LiteLLM returned 34,412 internet-facing matches, while Kestra returned 126. For comparison, Langflow — another AI-adjacent platform — matched 18,448 hosts, and the analytics tool Metabase, which has also surfaced in exploitation reporting, matched 115,725. The post includes an important caveat: these figures count assets matching a fingerprint, not instances confirmed to be vulnerable or compromised.

The gap between the two AI-infrastructure numbers is itself instructive, the analysis argues. LiteLLM's larger footprint reflects how commonly AI gateways are deployed as shared services, reachable by many internal clients and, in some cases, by the public internet. Kestra's smaller count does not make it safer, because a single exposed orchestration platform with command-execution potential is a serious risk on its own.

What operators should do now

The dev.to post sets out a short playbook. Treat AI infrastructure as a sensitive asset class rather than internal plumbing: gateways and orchestrators hold credentials and should not be exposed to the internet. Patch the KEV-listed components promptly. Rotate model provider keys if a gateway may have been reachable, since stolen credentials are the main fallout of this class of attack. Require authentication on every caller and log that access. Finally, fold AI services into routine exposure monitoring — query for them externally, compare the results against asset inventory, and treat any unexpected match as a finding that needs attention immediately.

Why it matters

The KEV listing is a marker that the attack surface has formally widened to include the AI layer. Gateways like LiteLLM sit at a choke point where model keys, database credentials, and workflow tokens converge, so a single compromise compounds quickly across everything those credentials touch. With tens of thousands of fingerprint-matched LiteLLM deployments visible online, a fair number of organizations likely do not realize their AI tooling is publicly reachable at all. Defenders who already run exposure management for VPNs, firewalls, and web frameworks now have a concrete reason to extend the same scrutiny to the services that make up their AI stack.