Kestra and Starlette in CISA KEV: CVE-2026-49869 and CVE-2026-48710

On September 2, 2026, CISA added two vulnerabilities to its KEV catalog that hit the tooling of development and data teams rather than classic infrastructure:

NVD has published no score, vector or versions for either at the time of writing. I'm relying on the CISA descriptions and won't invent a fixed version number.

The two products share a trait: they are rarely in IT's inventory. Kestra is installed by a data team to orchestrate its jobs; Starlette isn't even an application, it's a library that arrives as a dependency.

CVE-2026-49869 — Kestra: workflows without credentials

Kestra OSS contains an OS command injection vulnerability that could allow an unauthenticated remote attacker to create and execute arbitrary workflows without credentials.

To grasp the severity, recall what Kestra is: a workflow orchestrator. A Kestra workflow is code execution — it launches scripts, shell commands, containers, queries against databases and cloud services. That's its purpose.

Being able to create and run a workflow without authentication therefore means arbitrary code execution through the product's normal functionality. No sophisticated exploitation technique is needed beyond the initial bypass.

What an orchestrator holds

That's what makes it an attractive target:

• Credentials to everything it orchestrates: databases, data warehouses, cloud storage accounts, third-party APIs — stored as secrets or variables
• Broad network reach: the orchestrator has to reach every data source and destination
• Legitimate schedules: a malicious workflow scheduled hourly looks exactly like a normal one

An attacker controlling Kestra doesn't need to move laterally: the tool was configured to reach everything that matters.

CVE-2026-48710 — Starlette: when the reconstructed path lies

Kludex Starlette contains a HTTP request/response smuggling vulnerability that could allow attackers to inject paths into the host part, prepending the actual path, leading to issues such as authentication bypass when the authentication depends on the reconstructed URL's path. This vulnerability could be chained with CVE-2026-42271.

Why Starlette concerns far more people than you'd think

Starlette is the ASGI toolkit FastAPI is built on — one of the most widely used Python web frameworks. A FastAPI application ships Starlette as a dependency whether the team knows it or not. Real exposure is therefore measured in FastAPI applications, not in "Starlette installs".

The condition that matters

The description is precise about scope: the bypass works when authentication depends on the reconstructed URL's path.

Concretely, the vulnerable code is the code making access decisions from the URL as Starlette reconstructs it — typically a middleware doing something like "if request.url.path starts with /public, let it through". By injecting content into the host part, the attacker makes the reconstructed URL diverge from the path actually routed.

If your access controls rely on per-route dependencies (FastAPI's native mechanism) rather than on path inspection in a middleware, you're probably outside the described scenario. But verify rather than assume.

The chaining with CVE-2026-42271

CISA states the flaw can be chained with CVE-2026-42271, without detailing the latter in the entry. I have no reliable information on what it contributes and won't describe it. Just note the agency considers the combination relevant, which justifies treating Starlette even if your use case looks marginal.

Identifying Your Exposure

Kestra

# Version of an instance
curl -s http://kestra.example.local:8080/api/v1/configs | jq '.version'

# Docker deployment
docker ps --format '{{.Image}}' | grep -i kestra

Starlette — it's a dependency, hunt for it as one

# In each Python environment
pip show starlette | grep -i version

# In a repository: find every application depending on it
grep -rIl --include="requirements*.txt" --include="pyproject.toml" --include="poetry.lock" -iE "starlette|fastapi" .

# In deployed container images
docker run --rm --entrypoint pip <image> show starlette 2>/dev/null | grep Version

The third command matters most: the version that counts is the one pinned in the production image, not the one on the developer's laptop.

Detection

Kestra

• Workflows created or modified that nobody on the team recognises — the most direct signal
• Executions outside the usual schedules
• Script or shell tasks in workflows that had none
• Secret access from recent workflows
• Outbound traffic from the instance to destinations unrelated to declared pipelines

Starlette / FastAPI

• Requests whose Host header contains path characters (/, %2F) — a legitimate Host never does
• 200 responses on protected routes with no valid token in the same request

Mitigation

1. Kestra: update, and never expose it

Apply the vendor's fixed release. Above all: an orchestrator has no reason to be internet-reachable. Put it behind a VPN, enable authentication, restrict network access to the teams that use it.

2. Starlette: update the dependency and rebuild

pip install --upgrade starlette
# then pin the version in requirements / lockfile, rebuild and redeploy the images

Updating the developer workstation fixes nothing in production. The fix only exists once the image is rebuilt and redeployed.

3. Harden access controls

Regardless of the patch: don't make authorization decisions on a path reconstructed from client-controlled headers. Prefer per-route authentication dependencies, and validate the Host header at the reverse proxy against a list of expected hosts.

4. If you conclude Kestra was compromised

1. Isolate the instance
2. Rotate every secret it holds — that's the real scope of the incident
3. Audit workflows and their execution history over a wide window
4. Check the systems the workflows target: databases, warehouses, cloud storage

Why Continuous Monitoring of Engineering Tooling Matters

Data orchestrators, web frameworks, Python libraries: these components escape conventional inventories because they're installed by the teams using them, and because a library like Starlette doesn't even register as software in its own right. Yet two of them just entered the catalog of actively exploited vulnerabilities.

With cveo.tech, inventory your data tools and application frameworks with exact versions, and get automatic alerts whenever a critical CVE affects them.