Kestra, 10 out of 10: the flaw that does not need to face the internet

On 2 September CISA added seven flaws to its catalog of exploited vulnerabilities. Three are perimeter boxes: two SonicWall appliances and a Sangoma phone system. Another three are services nobody in procurement bought — someone on the team stood them up to move faster. And a seventh that nobody installed at all, because it arrived inside something else. Two of the seven score 10.0 out of 10: one is the SonicWall box, which surprises nobody; the other is a workflow orchestrator, and the reason it opens fits in a single line of code.

The seven of 2 September

We downloaded the whole KEV catalog—the known_exploited_vulnerabilities.json file CISA publishes—and looked at what went in that day. This is the full list, uncut. Read it down the third column, which is where the interesting part sits.

Artifactory is the artifact store: it holds the packages that get deployed and the credentials that push them. Kestra is a workflow orchestrator: its literal job is to execute things with permissions. LiteLLM is the gateway you put in front of language models to centralise OpenAI, Azure or Anthropic keys. All three were stood up by someone inside, all three hold more privilege than the firewall does, and none appears in an inventory of "exposed equipment".

Starlette earns its own column, which is why we gave it one. It is the Python framework many of these applications are built on, and it arrives dragged in as a dependency of FastAPI: nobody chose it, it does not listen on a port of its own, it has no dashboard, no credentials and no default configuration to review. Its problem is of a different kind and probably worse, because it appears on nobody's list of services. It appears, if anywhere, in a dependency file that a tool reviews.

The line

CVE-2026-49869, Kestra's 10.0, has a description you can read in one sitting. The authentication filter lets the public configuration endpoint through without credentials, which is reasonable. What is not reasonable is how it checks that a request is going there:

request.getPath().endsWith("/configs")

It is a suffix comparison, not an exact path match. Any API path whose last segment is configs bypasses authentication entirely. And there is a very interesting one that ends that way: the one that creates workflows. With that, an attacker with no credentials defines a flow, picks the process runner and gets command execution as root inside the worker container, because script execution plugins ship enabled. From a string comparison to root, with no password anywhere in between.

We have written about this family before: it is the control that fails open. A control that, when it does not know what to do, lets you through. The difference between endsWith and an exact match is the difference between "looks like the service door" and "is the service door". A human doorman does not confuse the two. A filter written in a hurry does.

"It is not on the internet" no longer sorts the queue

The Kestra advisory says, in as many words, that the instance need not be internet-exposed: network access to its port, 8080 by default, is enough. And the affected authentication mode—basic—is the one Kestra OSS ships with.

Now put that next to how patching order gets decided today. The directive CISA uses to instruct federal agencies, BOD 26-04 from June 2026, retired the previous regime—two weeks for CVEs from 2021 onwards, six months for older ones—and replaced it with a four-factor model. First of the four is whether the asset is exposed. The other three are catalog inclusion, whether the flaw can be automated, and technical impact. That is where the table's two deadlines come from: three days for five of the entries, fourteen for LiteLLM and Starlette. For what the directive counts as not exposed, the deadline can stretch all the way to "fix it at the next upgrade".

The model is sensible and better than what came before. What breaks is how the rest of us apply it, because "exposed" has become a label we stick on an asset by checking whether it has a public IP, and that check falls a long way short. Exposure is not a property of the machine: it is a property of the path that reaches it. That orchestrator publishing nothing outward sits one hop from the CI runner, from the laptop coming in over a VPN that hands out the whole network, and from any other container on the same host. If any of those can be compromised, your orchestrator is exposed. It is just that the spreadsheet says otherwise.

The four inside fail the same way

With the four entries lined up, what they share is what they are about. None is a memory overflow or an exotic corruption bug: all four touch the code that decides who gets in.

• Artifactory — CISA's entry says that under default configuration an unauthenticated attacker with network access can obtain administrative privileges. By default.
• Kestra — the suffix comparison above. Default authentication mode.
• LiteLLM — in the MCP auth handler's fallback path, a failed key validation could be replaced with an empty authorisation object. Translated: you present a made-up Bearer token and it opens an authenticated session, with which the connected tools can be listed and called. Fixed in 1.84.0.
• Starlette — request smuggling that allows paths to be injected into the host portion and, where authentication depends on the reconstructed URL path, bypassed. It is the most conditional of the four, and CISA's own entry notes it can be chained with CVE-2026-42271.

Four different products, four different teams, the same class of mistake. And in two of the four it is written in those words on the entry: by default. It is a predictable consequence of how these tools get deployed: they go up with a docker compose up to try for an afternoon, they stay, and nobody looks again at the startup section that decides authentication because "it is on the internal network". The compose file of a service that has been running for eighteen months is a historical document almost nobody rereads.

92 days

The fixed release, 1.3.21, shipped on 2 June 2026, and its notes already mention "potential authentication bypass in the authentication filter". The security advisory went out the next day. CISA added it to the catalog on 2 September: ninety-two days. The public CVE record, for that matter, did not appear until 26 June, twenty-four days after the patch was already downloadable.

CISA has done nothing wrong: the catalog admits an entry when there is evidence of exploitation, and that is exactly its stated criterion. The trouble starts when someone uses it as an early warning system, which the catalog has never claimed to be. If KEV sorts your patching queue, for software you install yourself you are behind by design, and here the margin was three months during which the fix was published and downloadable.

The versions, so you do not have to go looking: Kestra is fixed in 1.0.45 and 1.3.21; it affects everything before 1.0.45 and the 1.1.0–1.3.20 branch. LiteLLM, in 1.84.0.

What was done with the access, according to Microsoft

On 26 August, a week before CISA published the batch, Microsoft described three real compromises in AI workloads: LiteLLM, RAGFlow and Kestra. It is worth reading what the attackers did in each, because it dismantles the idea that a compromised orchestrator is "one server down".

• In Kestra: shell execution through the workflow engine, container environment discovery via the Docker socket, a cryptocurrency miner, and data harvesting through the application's own key-value store.
• In LiteLLM: credential harvesting from the gateway process environment, masqueraded binaries, a miner with CPU tuning so it would not stand out, access to the PostgreSQL database behind it, and persistence through SSH keys and cron entries.
• In RAGFlow: a Python hook injected into the application startup path to intercept provider keys as they were configured, and exfiltrate them. OpenAI, Azure, Anthropic and Gemini keys.

The sentence Microsoft sums it up with is worth the click: gateways, retrieval platforms, orchestration services and containerised runtimes "concentrate credentials, data access, model connectivity, and execution privileges, making them some of the most powerful components in the AI stack". Swap "AI stack" for "your network" and it is still true, because an orchestrator does not need to talk to a model to hold the keys to everything.

And the uncomfortable part is worth saying: the aim of nearly all of this was mining cryptocurrency on your electricity bill and taking API keys. There was no encryption and no ransom note. It is exactly the kind of incident you never find out you had, which is worse.

What we would do on Monday

We run self-hosted n8n for internal tasks, so we write this with our own house in front of us, not from the outside. We treat it as a production service: inventoried, with an owner and a maintenance window. These are the seven things we would check, in this order:

• Make the list. What self-hosted software runs on your network that nobody purchased: orchestrators, artifact repositories, dashboards, gateways, AI things, the CI runner. If it comes out of two people's memory rather than an inventory, that is finding number one.
• Give it an owner and a window. One name per service and one day a month when it gets updated. Without that, the rest of this list gets done once and never again.
• Try reaching the port from odd places. From the guest network. From the laptop coming in over VPN. From another container on the same host. The list of places you can reach it from is your real exposure, and it is usually longer than the diagram says.
• Look at the Docker socket. If the container has it mounted, compromising the container is compromising the host. In Kestra that was exactly the discovery path. Remove it unless you genuinely need it.
• Write down which credentials each one holds, what those credentials can reach, and what would happen if someone read all of them at once. On a model gateway holding four providers' keys, that translates into an invoice as well as an incident.
• If you were on a vulnerable version, updating is not enough. Rotate what lived inside and go looking for what Microsoft describes: mining processes, SSH keys you did not add, new cron entries, outbound traffic to mining pools.
• Make sure the alert lands somewhere. A miner shows up in CPU and outbound traffic long before it shows up anywhere else. If nobody looks at that graph, it may as well not exist.

The first two points are the ones that actually change anything, and they are the dullest. We have written about the same problem from other angles twice: when the deployment chain holds the keys to production, and when the AI pilot nobody switched off becomes infrastructure without anyone deciding it should.

When this is not about you

If you have none of these four pieces, do not install them because you read this. A twelve-person practice running Microsoft 365 and a NAS has no workflow orchestrator and does not need one; their version of the same problem is the print server, the camera recorder, or the NAS that doubles as the backup server, and the useful question is still the third one on the list: who can reach that port.

Nor are we going to stretch a batch of seven entries into a trend. Though while we are here, honesty runs both ways: through August the catalog kept adding Langflow, TeamCity, Metabase, Ray, MLflow, Gitea, ownCloud, PaperCut and Artifactory once already, alongside the usual firewalls and operating systems. That supports our argument rather more than 2 September did on its own. It is still five weeks of data, and five weeks does not make a trend; judge it yourself. What we do stand behind with no counting involved is the other part: the Kestra advisory says internet exposure is not required, and that is incompatible with sorting your queue by whether an asset has a public IP.

The question we will leave you with answers itself in ten minutes and requires buying nothing: take the most useful orchestrator, repository or dashboard you have running. From how many places on your network can its port be reached? If the answer is "from everywhere", the score of its next CVE stops mattering very much.

Sources: the list of the seven entries from 2 September 2026, their products, dates added and deadlines come from CISA's KEV catalog downloaded on 6 September 2026 (version 2026.09.04) from the public catalog; the description of CVE-2026-82329 about Artifactory's default configuration is quoted from there too. The technical details of CVE-2026-49869 (the suffix comparison in the authentication filter, root execution in the worker container, versions 1.0.45 and 1.3.21, the 10.0 score and the fact internet exposure is not required) come from the Kestra security advisory, published on 3 June 2026. The date and quoted phrase from the 1.3.21 release (2 June 2026) come from its release notes; the 26 June date is that of the public CVE record, not the advisory. Those for CVE-2026-59822 (the empty authorisation object in the fallback path and version 1.84.0) come from the LiteLLM advisory. The four-factor model and the deadlines come from directive BOD 26-04, June 2026. The three compromises and the quoted sentence come from "When AI infrastructure becomes the target", Microsoft Security Blog, 26 August 2026. What we do not claim: we do not say how many Spanish companies run these pieces, because we do not know; we do not attribute the compromises to any particular group; the "perimeter / inside / dependency" classification in the table is ours and does not come from CISA; and the reading that the 2 September batch marks a shift in attack surface is a reading of a single day, stated with the caution that deserves.