Exploited Kestra flaw bypasses basic authentication

An older flaw now has an exploitation signal

On 2 September, the US Cybersecurity and Infrastructure Security Agency added CVE-2026-49869 to its Known Exploited Vulnerabilities catalogue. CISA describes an operating-system command-injection vulnerability in Kestra OSS which can allow an unauthenticated remote attacker to create and execute workflows without credentials. Catalogue inclusion means CISA has evidence of exploitation in the wild. It records known ransomware use as unknown, which should not be interpreted either way.

Kestra's advisory was published in June, so the vulnerability itself is not new. The current reason to revisit it is CISA's exploitation finding. CISA's remediation deadline applies to relevant US federal agencies, not UK businesses, but it is a strong prioritisation signal for organisations running the affected workflow platform.

Workflow authority determines the consequence

Kestra says the flaw affects Kestra OSS releases up to and including 1.3.20 where basic authentication is enabled, which it identifies as the default authentication mode for OSS. A path-matching error can cause selected application routes to bypass authentication. Because a caller can create and run a workflow through those routes, the vendor says the result can be unauthenticated code execution as root inside the Kestra worker container.

The advisory also describes access to internal services from the worker and unauthorised changes to certain Kestra resources. Practical impact therefore depends on deployment architecture: network reach, mounted data, cloud identity, secrets, enabled plugins and the permissions given to the worker all matter. The vendor did not confirm a direct escape through the Docker socket in its tested configuration, so do not turn container-level execution into an unsupported claim of host compromise.

The primary sources establish exploitation of the vulnerability, not that every affected server has been compromised or how any particular incident unfolded. An internal-only service can still be reachable by an attacker who already has network access. Establish actual routes and controls rather than treating a private address as proof of safety.

Update, reduce reach and preserve evidence

Inventory Kestra OSS in production, development, data platforms and supplier-managed environments. Confirm the running version and authentication mode from the deployed service, not only a repository or image tag. Kestra lists 1.0.45 and 1.3.21 as patched releases for the affected branches; move to an appropriate supported fixed release or later and follow the project's upgrade guidance.

Until updating is complete, restrict the service to the smallest necessary set of trusted users and networks. Review reverse-proxy, firewall and identity controls to confirm they cover every route to the application. This reduces exposure but does not correct the application flaw or establish whether earlier exploitation occurred.

For a vulnerable instance that was reachable, preserve application, proxy, container, orchestration and relevant cloud audit records before patching or routine retention changes them. Then review unexpected workflow creation or execution, configuration changes and access from the worker to other services. If evidence suggests compromise, follow the incident plan and assess exposed credentials and connected systems rather than limiting the review to the Kestra container.

• Locate Kestra OSS services and confirm running versions and authentication modes.
• Update affected branches to an appropriate supported fixed release or later.
• Restrict network reach while remediation and review are under way.
• Preserve relevant evidence before changes remove useful artefacts.
• Investigate workflow activity and connected services in proportion to actual exposure.

The Beekeeper view

A workflow platform is an execution boundary. Its job is to coordinate tasks across systems, so its service identity and network position can make a small authentication mistake consequential. Patching is essential, but treating the server as an ordinary web dashboard misses that authority.

Close the task when the fixed version is verified, unnecessary reach has been removed and every exposed instance has an evidence-based review. The durable control is to give automation workers only the access each workflow needs; that limits the cost of the next software defect as well as this one.