The Workflow Engine Let Attackers Write Their Own Jobs

The vulnerability, CVE-2026-49869, is not a vague permissions problem. Kestra’s authentication filter used a suffix check for paths ending in /configs. That meant unrelated API routes could inherit the same exemption simply by using configs as their final path segment.

One word at the end of a URL bypassed authentication

Kestra intended to expose only its legitimate configuration endpoints without Basic Authentication. Instead of comparing the complete route, the filter accepted any request whose path ended with /configs.

An attacker could therefore create or overwrite a workflow named configs through an exempted flow route. A second unauthenticated request could trigger that workflow through another route ending in the same word. Kestra ships with shell, Python, Node.js and other script-execution plugins, so the malicious workflow could run attacker-controlled commands as root inside the worker container.

The same weakness also exposed destructive and covert options. The vendor advisory says an attacker could write key-value data, delete selected workflows or dashboards, erase targeted logs and combine the bypass with Kestra’s unrestricted HTTP template function for server-side request forgery. In a cloud deployment, that SSRF path could reach metadata services and expose workload credentials.

CISA says attackers are already using it

CISA added CVE-2026-49869 to its Known Exploited Vulnerabilities catalogue on 2 September 2026. Federal civilian agencies were given until 5 September to apply vendor guidance. The catalogue marks known ransomware-campaign use as unknown, but requires forensic triage.

Microsoft separately documented a compromised Kestra environment and assessed with high confidence that initial access likely came through this vulnerability. Telemetry showed workflow-origin shell sessions followed by container discovery, XMRig deployment and data collection.

The Docker socket made one deployment worse

The vulnerable request does not automatically escape the worker container. Kestra’s own advisory says its test container did not mount /var/run/docker.sock and that a direct socket escape was not confirmed in that default setup.

Microsoft’s real-world case had a different configuration. The compromised worker could access a mounted Docker socket, enumerate other containers and inspect their environment arrays for cloud keys, database passwords and API tokens. The distinction matters: root inside the worker is the guaranteed vulnerability impact, while cross-container exposure depends on how Kestra was deployed.

What defenders should do now

• Upgrade the 1.0 release line to 1.0.45 or later and the 1.3 line to 1.3.21 or later.
• Remove direct internet exposure from Kestra’s API and management interface. Limit access to authenticated administrative networks.
• Do not mount the Docker socket into the worker unless the design requires it. If it is present, treat compromise as potentially extending to every reachable container.
• Search for workflows, namespaces, dashboards, key-value entries or log operations using configs as the final path segment or object name.
• Investigate shell, Python or Node.js processes spawned by the Kestra worker, unexpected workflow creation, XMRig artifacts and unusual access to container environment data.
• Rotate credentials available to the worker or exposed through container environment variables when vulnerable infrastructure was reachable.

The bigger lesson

Workflow engines are control planes disguised as productivity tools. Their purpose is to execute tasks and connect systems. When an authentication exception can be expanded through a naming trick, the attacker inherits that authority before supplying a single credential.

Sources: Kestra’s security advisory, Microsoft Security’s investigation, and CISA’s KEV data repository.