CVE-2026-49869: Kestra OSS Unauthenticated OS Command Injection via Workflow Creation

Background

Kestra is an open-source data orchestration and workflow automation platform used to schedule, chain, and execute data pipelines, ETL jobs, and automation tasks — a role comparable to Apache Airflow. Kestra OSS, the self-hosted open-source edition, is commonly deployed by engineering teams to orchestrate internal data and infrastructure workflows, often with broad network and credential access to the systems it automates, since workflow engines frequently hold secrets and service-account credentials needed to drive downstream jobs.

CVE-2026-49869 carries the maximum CVSS score of 10.0 because it allows a completely unauthenticated remote attacker to both create and execute arbitrary workflows on a Kestra OSS instance without ever presenting credentials. Since workflows in Kestra can shell out to the underlying operating system as part of normal task execution, the ability to create and run an attacker-controlled workflow is functionally equivalent to unauthenticated remote code execution on the orchestration host — and from there, on anything that host’s credentials can reach.

Technical Mechanism

CISA’s KEV entry lists four associated weaknesses for CVE-2026-49869: CWE-78 (OS Command Injection), CWE-184 (Incomplete List of Disallowed Inputs), CWE-287 (Improper Authentication), and CWE-918 (Server-Side Request Forgery). Read together, these describe a chained flaw rather than a single isolated bug:

1. CWE-287 — Improper Authentication: A workflow-creation or execution endpoint in Kestra OSS fails to properly enforce authentication, allowing requests to reach workflow-management functionality without a valid session or credential.
2. CWE-918 — SSRF: The same or an adjacent code path permits the attacker to direct the server to make requests to arbitrary internal or external targets as part of building or triggering a workflow, which can be used both to reach internal-only services and as a stepping stone toward the injection itself.
3. CWE-184 — Incomplete Denylist: Input intended to constrain what a workflow task may contain (e.g., disallowed task types, shell metacharacters, or script content) is filtered using an incomplete denylist that attackers can bypass with alternative syntax or encoding.
4. CWE-78 — OS Command Injection: Because workflow definitions can include task steps that invoke shell commands, an attacker who can create and execute an arbitrary workflow — bypassing both authentication and the input denylist — can embed a command-injection payload directly into a workflow task, which Kestra then executes on the underlying host operating system.

Attack flow in short: an unauthenticated attacker reaches the workflow-creation API (bypassing auth via CWE-287), submits a workflow definition containing a task whose parameters embed shell metacharacters that evade the incomplete denylist (CWE-184/CWE-78), and triggers execution — at which point Kestra’s task runner invokes the underlying OS shell with the attacker’s injected command, executing with the privileges of the Kestra service process.

Real-World Exploitation Evidence

CVE-2026-49869 is listed in CISA’s KEV catalog, added on 2026-09-02, confirming CISA has evidence of active exploitation of this flaw in the wild — not merely a theoretical risk. CISA’s record lists knownRansomwareCampaignUse as “Unknown,” meaning CISA has not confirmed this specific vulnerability is being used as part of a named ransomware campaign at this time; that should not be read as a guarantee it won’t be used that way, particularly given the unauthenticated, full-RCE nature of the flaw.

No specific threat actor or campaign name has been publicly attributed to exploitation of CVE-2026-49869 in the information available to us. The KEV listing confirms exploitation has occurred in the wild; detailed attribution is not yet public. Kestra’s GitHub security advisory (GHSA-5vc5-wxxq-3fjx) is the authoritative vendor source and should be consulted for any updates on attacker activity.

Kestra is flagged by CISA as an open-source component that may be bundled or embedded within other products, meaning organizations should check not just their own direct Kestra deployments but also any third-party platforms that may ship Kestra OSS internally.

Impact Assessment

Given the unauthenticated, pre-auth nature of this vulnerability and its CVSS 10.0 score, successful exploitation grants an attacker complete compromise of confidentiality, integrity, and availability on the Kestra host:

• Confidentiality: Workflow orchestration platforms routinely store connection secrets, API tokens, and database credentials used to drive downstream automation — all of which become accessible to an attacker with OS-level command execution on the host.
• Integrity: An attacker can modify or create new workflows that run with the same trusted access as legitimate automation, effectively weaponizing the orchestration platform itself to push malicious changes into every system the Kestra instance is authorized to touch.
• Availability: Full command execution allows an attacker to disrupt or destroy the orchestration environment, halting dependent data pipelines and automation.

Sector-specific risk: Because workflow orchestration tools like Kestra sit at the center of data engineering and DevOps automation, a compromised instance is a high-value pivot point into data warehouses, cloud infrastructure APIs, and CI/CD systems that the workflows are configured to reach — elevating the risk well beyond the orchestration server itself.

Affected Versions

The precise affected version range was not included in the KEV data provided to us. Kestra’s GitHub security advisory is the authoritative source for the exact affected and patched version boundaries:

Remediation Steps

CISA’s required action directs applying vendor mitigations per BOD 26-04 risk-based guidance, applying forensics triage requirements, and discontinuing use where mitigation is unavailable.

1. Upgrade Kestra OSS immediately to the patched version referenced in GitHub advisory GHSA-5vc5-wxxq-3fjx.

# Example: check running Kestra version via its CLI/API before and after upgrade
curl -s http://<kestra-host>:8080/api/v1/configs | grep -i version

2. Restrict network exposure of the Kestra API and UI to trusted internal networks or VPN — do not expose workflow-creation endpoints directly to the internet.
3. Enforce authentication at the network edge (e.g., reverse proxy with mandatory auth) as a defense-in-depth layer while patching is rolled out, given the underlying improper-authentication weakness.
4. Rotate all secrets stored within Kestra (connector credentials, API keys, service-account tokens) after patching, given the risk they were exposed during the exploitation window.
5. Audit existing workflow definitions for any unauthorized workflows created during the exposure window, particularly any with shell/script task types.

Detection Guidance

• Review Kestra API access logs for workflow-creation or execution requests originating without an authenticated session, particularly from unexpected source IPs.
• Look for workflow task definitions containing shell metacharacters (;, |, `, $(), &&) in parameters that are not normally used for command construction.
• Monitor process execution on the Kestra host for shell interpreters (sh, bash, cmd.exe) spawned by the Kestra service account with arguments that do not match known, intended workflow tasks.
• Watch for outbound requests from the Kestra host to unexpected internal or external hosts, consistent with the SSRF component of this vulnerability chain.
• Exact signatures should be sourced from Kestra’s own advisory updates and your IDS/EDR vendor’s threat feeds as detail becomes available.

Timeline

References

• Kestra GitHub Security Advisory — GHSA-5vc5-wxxq-3fjx
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• CISA — BOD 26-04 Implementation Guidance: Forensics Triage Requirements
• NVD — CVE-2026-49869