Unauthenticated RCE in Kestra OSS: Analyzing CVE-2026-49869

An unauthenticated remote code execution flaw in Kestra OSS, tracked as CVE-2026-49869, presents a maximum-severity threat to organizations utilizing the open-source orchestration platform. Carrying a maximum CVSS v3.1 score of 10.0, the Kestra OSS OS command injection vulnerability allows unauthenticated network attackers to craft and execute arbitrary workflows without valid credentials, completely bypassing standard authentication controls.

Execution Path and Technical Mechanics

Kestra is designed to build and run complex data pipelines, system automation scripts, and cloud infrastructure workflows across distributed execution environments. CVE-2026-49869 arises from systemic failure in API authentication coupled with improper handling of input strings during execution building—encompassing weaknesses in command injection (CWE-78), input filtering (CWE-184), authentication validation (CWE-287), and server-side request forgery (CWE-918).

Because unauthenticated HTTP endpoints allow workflow definition requests to pass through without identity verification, an attacker can submit malicious workflow manifests containing embedded shell commands, arbitrary Python/Bash scripts, or untrusted Docker containers. When the Kestra engine parses and executes these tasks, payloads run under the contextual security privileges of the underlying Kestra worker process.

The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) underscores the severe impact, specifically highlighting Scope Change (S:C). In orchestration management platforms, a scope change means an exploit breaks out of the control plane and directly impacts target workloads, connected cloud APIs, container daemons, and internal databases accessible to the orchestration engine.

Impact and Exposure Profile

While the Exploit Prediction Scoring System (EPSS) measures the 30-day exploitation probability at 0.99% (60.2nd percentile), this score should not lull security teams into deferring remediation. Open-source data orchestration tools exposed directly to the internet represent high-value targets for automated mass-scanning scripts and initial access brokers.

Deployments facing the highest immediate risk include:

• Publicly accessible Kestra OSS instances lacking access controls such as modern Web Application Firewalls (WAF), Zero Trust Network Access (ZTNA), or IP allowlists.
• Deployments where Kestra instances run with elevated local permissions, host-level root access, or write access to the underlying Docker socket (/var/run/docker.sock).
• Environments where Kestra worker nodes hold high-privilege IAM roles or access tokens for AWS, GCP, Azure, or internal key stores.

Remediation and Mitigation

Organizations running Kestra OSS should treat this vulnerability as an urgent patching priority and implement the following measures:

1. Apply Updates: Upgrade Kestra OSS installations immediately. Environments running the 1.0.x release train must update to version 1.0.45 or later. Installations on the 1.1.x, 1.2.x, or 1.3.x release trains must update to version 1.3.21 or later.
2. Isolate Infrastructure: Ensure Kestra UI and API services (typically running on port 8080) are removed from direct exposure to the public internet and placed behind authenticated VPNs or identity-aware proxies.
3. Forensic Inspection: Conduct triage across all Kestra instances by inspecting workflow execution logs, revision history, and newly registered namespaces for unauthorized script execution created prior to patching. If an unauthorized workflow is discovered, treat the associated runner environment and managed credentials as fully compromised.