AI infrastructure on the CISA KEV list means federal patch deadlines now apply to components most organizations cannot find in their own asset inventory. On September 2, 2026, CISA added seven vulnerabilities to the Known Exploited Vulnerabilities catalog, and three of them sit in the AI and machine learning stack. Two matter most for mid-sized firms: CVE-2026-59822, an authentication bypass in Berri LiteLLM’s Model Context Protocol endpoint scoring 8.8, and CVE-2026-49869, an OS command injection in Kestra scoring a full 10.0. Both are being exploited. Neither shows up in the software inventory tooling that finds every other KEV entry, because neither was installed the way software normally is.
The Five Points Worth Acting On This Week
We give clients this short list before anybody opens a patch ticket, because the sequence matters more than the speed.
- Exploitation is confirmed, not theoretical. KEV inclusion requires evidence of active use, and the reported activity includes reverse shells and cryptocurrency miners.
- Kestra’s flaw needs no credentials at all. An unauthenticated remote attacker can create and run arbitrary workflows, which is why it scored 10.0 and drew a three-day federal remediation window.
- LiteLLM’s flaw is the first MCP entry on the list. A fabricated Authorization header triggered an OAuth2 passthrough fallback, so an arbitrary bearer token opened an authenticated session.
- Inventory is the bottleneck. These components arrive through a package manager inside a project repository, so the normal discovery path does not see them.
- The pattern repeats from here. AI components made up nearly half of one KEV batch, and the estates carrying them are the least mapped part of most networks.
Why These Two Entries Are Harder Than a Normal KEV Item
These two entries are harder than a normal KEV item because the remediation step is trivial and the discovery step is not. A typical KEV addition names a product your endpoint agent already reports on, your patch tooling already tracks, and your vendor already ships updates for. The work is scheduling. You know the population, you know the version spread, and you can prove the fix landed.
LiteLLM and Kestra break every part of that chain. Our team has run this exercise across client estates for the last two weeks, and the same thing happens each time: the security lead runs the standard inventory query, gets zero hits, and reports no exposure. Then somebody on the engineering side mentions that the internal chatbot proxies through LiteLLM, and a data engineer says the nightly pipeline orchestration is Kestra. Both were correct. The query was asking the wrong system.
What CVE-2026-49869 Actually Lets Somebody Do
CVE-2026-49869 lets an unauthenticated attacker create and run workflows on your Kestra instance. Kestra is a workflow orchestration platform, which means running arbitrary workflows is the same thing as running arbitrary code with whatever access the orchestrator holds. In most deployments that access is broad, since the whole point of an orchestrator is reaching databases, object storage, and internal APIs on a schedule.
The flaw itself is a string-matching mistake anybody could make. The authentication filter checked whether a request path ended with the word configs, using a suffix comparison rather than an exact match. Any path that happens to end in those characters skipped basic authentication entirely. That is a one-line defect with a maximum severity outcome, and it is a good argument for the position that severity and complexity are unrelated.
The opposing reading deserves space. A CVSS of 10.0 describes the worst reachable case, and plenty of Kestra deployments sit on an internal network behind a VPN with no route from the internet. Those are genuinely lower risk, and telling that team they have a ten-out-of-ten emergency is the kind of alarm that gets security advice ignored. The honest framing is that exposure depends on reachability, and the first question is whether the instance answers from outside. Our vulnerability assessment work starts there rather than with the score.
What CVE-2026-59822 Means for Anything Speaking MCP
CVE-2026-59822 means an attacker can hold an authenticated Model Context Protocol session using a bearer token they made up. LiteLLM acts as a proxy in front of language model providers, giving one API surface across several vendors, and its Streamable HTTP endpoint accepted a fabricated Authorization header. The header triggered an OAuth2 passthrough fallback, the fallback did not validate, and the request reached MCP tooling without a valid key. Versions before 1.84.0 are affected.
MCP matters here beyond this one product. It is the protocol that lets a model reach tools and data sources, so anything sitting behind an MCP endpoint is reachable by whoever gets a session. An organization that put its ticketing system, its file store, and its customer database behind an MCP server for convenience has put all three behind this bug.
There is a reasonable counterpoint that this is early-protocol growing pains and will settle as implementations mature. That is probably true over a few years. It does not help the estate running 1.83 today, and it argues for treating MCP endpoints as internet-facing authentication surfaces with the same review you would give a VPN concentrator, rather than as internal plumbing. We take the same line in vulnerability scanning versus penetration testing: a scanner tells you what it recognizes, and recognition is the limiting factor.
Why Your Scanner Reported Nothing
Your scanner reported nothing because it looks at installed packages, running services, and registry entries, and neither of these components appears in any of those places in the usual way. LiteLLM is a Python library that arrives through pip into a project virtual environment. Kestra frequently runs as a container image pulled by a compose file or a Kubernetes manifest. Both are real production services, and both are invisible to a tool asking the operating system what software is installed.
Container image scanning and software composition analysis do find them, and the organizations already running those tools got an answer within the hour. That is the strongest argument for putting dependency scanning in place, and it is worth making. The gap is that those tools are usually owned by the engineering team as part of a build pipeline, while KEV response is owned by security, so the finding and the mandate sit in different systems with different owners.
Closing that gap is mostly organizational. Get read access to the dependency scan output, map each scanned repository to the service it deploys, and treat that mapping as part of your asset register rather than as engineering trivia. We built this into the process described in how to implement a vulnerability management process, and it is the single change that moves AI components from unknown to tracked.
How to Find Both Components in an Estate You Do Not Fully Map
Finding these components takes three searches, none of which involve a vulnerability scanner. We run them in this order because each one catches a different way the software got in, and the third one catches what the first two miss.
Search one is the dependency files. Grep every repository for litellm in requirements.txt, pyproject.toml, poetry.lock, and any pip freeze output checked into the tree. Record the pinned version next to the repository name. Search two is the container and orchestration definitions. Grep for kestra across Dockerfiles, compose files, Helm charts, and Kubernetes manifests, then check the image tag rather than assuming latest. Search three is the network. Look at what is actually listening, because a developer who spun up a service outside the normal deployment path leaves a port open even when no repository mentions it.
Build the List Before You Build the Ticket
Build the full list before opening a single remediation ticket, because a partial list creates a false finish. The failure we see most often is a team patching the two instances they found, closing the item, and never learning about the third. A closed ticket is read as an all-clear by everyone downstream, and nobody re-runs the search.
Against that, there is a real cost to delay when the exploit is live. Waiting a week for a perfect inventory while an unauthenticated command injection sits exposed is the wrong trade. The way we square it is to patch anything internet-reachable the moment it is found, in parallel with the inventory work, and to keep the tracking item open until the search is done rather than until the first fix lands.
Record the findings somewhere durable. A spreadsheet is adequate. What matters is that the next KEV entry touching this part of the stack starts from a list rather than from nothing, which is the difference between an afternoon and a fortnight. Our IT infrastructure services team keeps that register alongside the conventional asset inventory rather than in a separate document.
Decide What Each Service Is Allowed to Reach
Decide what each AI service can reach, since that is what sets the damage when the next one of these lands. Kestra scored 10.0 partly because orchestrators habitually hold credentials for everything they touch. LiteLLM sits in front of model providers and often holds the API keys for all of them. Both are credential concentrators, and both were deployed by people solving a delivery problem rather than a security one.
Segment them the way you would segment any service holding broad credentials. Put the orchestrator on a network segment that cannot reach the internet outbound except to the specific endpoints it needs, give it per-target credentials rather than one administrative account, and make sure your network management baseline covers it. The work is ordinary and it changes a 10.0 into something survivable.
Fold AI Components Into the Cycle You Already Run
Fold these components into your existing patch cycle rather than treating each disclosure as an incident. The reason is throughput. An incident response costs a team a day and cannot be sustained monthly, while a patch cycle that already includes dependency scanning absorbs a new CVE as routine work. We made the same argument about conventional systems in the patch management gaps SMBs miss and in the vulnerability management risks SMBs miss.
For AI components the cycle needs one addition: a named owner per component. These services frequently have no owner in the asset register because they were stood up by a project team that has since moved on. Without a name attached, the patch ticket has nowhere to go and sits until somebody escalates.
The objection we hear is that naming an owner is bureaucratic overhead on a team already short of hours. In most estates it is the opposite, because the absence of a name is what turns a fifteen-minute upgrade into a three-day thread asking who is allowed to restart the service. We ask for two fields per component and nothing more: the person accountable for its version, and the window in which it can be taken down. Those two facts remove almost all of the delay we observe between a disclosure landing and a fix shipping.
One more practical note on version pinning. Teams often pin an AI dependency to an exact release during a pilot to keep behavior stable, which is sound engineering and also the reason so many estates sit on a vulnerable build months after a fix exists. Pinning is fine as long as somebody reviews the pin on a schedule. Put that review in the same cycle, attach it to the named owner, and the pin stops being a quiet decision nobody revisits.
Frequently Asked Questions
Does the CISA KEV list apply to private companies?
The binding operational directive applies to federal civilian agencies, so a private company is not legally required to meet the deadline. The list is still the best free prioritization signal available, because inclusion means exploitation has been observed rather than predicted. Treat it as a queue-jumping rule for your own patching.
How do I check which LiteLLM version we run?
Look at the dependency file in the repository that deploys the service rather than at the running host. A pip freeze inside the deployed container also works and is more reliable, since it reports what is actually installed rather than what was requested. Anything below 1.84.0 needs the upgrade.
Is Kestra safe if it is only on our internal network?
Internal-only deployment reduces the risk considerably and does not remove it, because an attacker who already has a foothold inside the network faces no authentication at all. Patch it on the normal cycle and treat the internal placement as time bought, not as a fix.
What else should we look for in the same category?
Model proxies, vector databases, workflow orchestrators, and MCP servers form the same class: recently adopted, deployed by engineering, holding broad credentials, and absent from the asset register. Inventory that whole category once and the next disclosure is a lookup.
Who owns AI infrastructure patching?
Ownership should sit with whoever owns server patching, not with the team that built the AI feature. The skills required are patching and inventory rather than machine learning, and splitting it off is how these components ended up untracked.
Who Is Behind This Advice
Our team handles vulnerability response for firms between 10 and 500 employees, which means we spend most of our time on the discovery half of the problem rather than the fixing half. The AI stack has made that imbalance sharper over the past year, since the components are genuinely useful, genuinely widely deployed, and almost never recorded anywhere a security team would look.
Matt Rosenthal, who leads Mindcore, has kept our practice pointed at the unglamorous end of this work: knowing what you run, who owns it, and what it can reach. That is what turns a maximum-severity disclosure into a scheduled task rather than a weekend.
Get Your AI Stack Onto the Same Register as Everything Else
AI infrastructure on the CISA KEV list is a preview rather than an exception. Three of seven entries in one batch came from this part of the stack, the components involved were adopted fast and recorded rarely, and the pattern holds because the adoption is still accelerating. The response that works is not faster patching, it is knowing the population before the next disclosure lands. Run the three searches, write down what you find with versions and owners, patch anything reachable from outside immediately, segment the services that concentrate credentials, and put the whole category into the same cycle that already handles your servers. None of that is novel security work. It is the ordinary discipline applied to a part of the estate that grew up outside it. If you want help mapping what your organization actually runs and who owns each piece, book a free strategy call and we will work through it with your team.
