CVE-2026-49869: Kestra OSS Auth Bypass Enables Unauthenticated RCE as Root (CISA KEV)

TL;DR

CVE-2026-49869 is a critical authentication bypass in Kestra OSS that allows an unauthenticated remote attacker to create and execute arbitrary workflows, resulting in remote code execution as root inside the Kestra worker container. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on 2026-09-02 with a remediation due date of 2026-09-05. Patch Kestra OSS to version 1.0.45 or 1.3.21 immediately, or isolate the API from untrusted networks and disable script execution plugins until you can.

What is this vulnerability?

Field	Value
CVE	CVE-2026-49869
Vendor / Product	Kestra / Kestra OSS
Vulnerability name	Kestra OSS OS Command Injection Vulnerability
Weakness (CWE)	CWE-78 (OS Command Injection), CWE-184 (Incomplete List of Disallowed Inputs), CWE-287 (Improper Authentication), CWE-918 (Server-Side Request Forgery)
CISA KEV added	2026-09-02
CISA KEV due date	2026-09-05
Known ransomware use	Unknown
CVSS v3.1 (GitHub Security Advisory)	10.0 Critical — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
EPSS score	0.01917 (78.868th percentile)
Fixed versions	1.0.45 and 1.3.21

Overview

CVE-2026-49869 is a critical authentication bypass and OS command injection vulnerability affecting Kestra OSS, an open-source, event-driven orchestration platform. The flaw resides in the AuthenticationFilter component, which enforces Basic Auth on protected API endpoints. Prior to versions 1.0.45 and 1.3.21, the filter used a suffix match (request.getPath().endsWith("/configs")) to whitelist the public configuration endpoint. Because this check matches any path whose final segment is configs, an unauthenticated remote attacker can bypass authentication entirely by targeting an API route that ends with that string. The vulnerability was assigned a CVSS 3.1 score of 10.0 (Critical) by the GitHub Security Advisory source, with a vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. CISA added CVE-2026-49869 to the Known Exploited Vulnerabilities (KEV) catalog on 2026-09-02, with a remediation due date of 2026-09-05, indicating active exploitation in the wild. The EPSS score is 0.01917 (78.868th percentile), suggesting a moderate probability of exploitation in the next 30 days, though the KEV listing elevates the urgency. Defenders running Kestra OSS in internet-exposed or multi-tenant environments should treat this as an emergency patch scenario.

Kestra is used to orchestrate workflows across data pipelines, infrastructure automation, and business processes. Because it often holds credentials and has broad access to downstream systems, a compromise of the orchestration plane can cascade into many connected environments. The fact that CISA issued a three-day remediation deadline — rather than the usual two weeks — signals that exploitation is not theoretical. Organizations that rely on Kestra for critical automation should assume that any internet-facing instance is at immediate risk and prioritize patching above nearly all other work.

Technical details

Root cause: The AuthenticationFilter in Kestra OSS uses a suffix-based path check to exempt the /configs endpoint from Basic Auth. The code request.getPath().endsWith("/configs") returns true for any request path whose last segment is configs, such as /api/v1/main/configs, /api/v1/executions/configs, or any other route ending with that string. This is a classic CWE-78 (OS Command Injection) compounded by CWE-184 (Incomplete List of Disallowed Inputs) and CWE-287 (Improper Authentication). The vulnerable component is the authentication filter, which is part of the core API layer.

Affected versions:

• All Kestra OSS releases prior to 1.0.45
• All Kestra OSS releases prior to 1.3.21

Attack prerequisites: Minimal. The attacker only needs network access to the Kestra API, no credentials, and no user interaction. The trust boundary is the API gateway or reverse proxy that fronts Kestra; if the API is exposed to the internet or an untrusted network, the boundary is effectively broken.

Why it leads to RCE: Because Kestra ships with script execution plugins (plugin-script-shell, plugin-script-python, etc.) enabled by default, the authentication bypass directly leads to OS command injection. An attacker can craft a workflow that uses these plugins to execute arbitrary commands. The CVSS vector indicates Scope Changed (S:C), meaning the vulnerability can affect resources beyond the vulnerable component, such as the underlying host or other containers. The combination of CWE-78, CWE-184, CWE-287, and CWE-918 (Server-Side Request Forgery) suggests multiple weaknesses are present, but the primary exploit path is the auth bypass leading to command execution.

Network exposure: The Kestra API typically listens on HTTP/HTTPS (commonly port 8080). Any instance reachable from an untrusted network — including internal networks with weak segmentation — should be considered exposed.

Impact

Successful exploitation results in complete compromise of the Kestra worker container and potentially the underlying host. Because the script execution plugins run as root by default, an attacker gains root-level command execution inside the container. This can lead to:

• Confidentiality: Full read access to all data processed by Kestra, including workflow definitions, secrets, credentials, and any data passed through workflows. Attackers can exfiltrate sensitive information from the orchestration platform.
• Integrity: Attackers can modify, create, or delete workflows, inject malicious tasks, and alter the behavior of automated pipelines. This can cascade into downstream systems that Kestra orchestrates.
• Availability: Attackers can disrupt or destroy workflows, delete data, or use the compromised container as a pivot point for further attacks, including ransomware deployment.
• Lateral movement: With root access inside the container, an attacker may escape to the host or move laterally to other services in the same network, especially if the container has privileged access or mounted volumes.

Business exposure is high for organizations using Kestra for critical automation, data pipelines, or infrastructure orchestration. The CISA KEV listing and the three-day remediation deadline underscore the severity and active exploitation. Defenders should assume that any internet-exposed Kestra instance is at immediate risk.

Exploitability

CVE-2026-49869 is listed in CISA KEV, confirming that it has been exploited in the wild. The EPSS score is 0.01917 (78.868th percentile), which indicates a moderate probability of exploitation in the next 30 days relative to other vulnerabilities, but the KEV status removes any doubt about active targeting. No public proof-of-concept code is referenced in the source material, but the flaw is straightforward to exploit: an attacker only needs to send a crafted HTTP request to an API path ending in /configs. The absence of a public PoC does not reduce risk; the KEV listing and the three-day federal deadline are the strongest signals that defenders should act immediately.

KEV vs CVSS vs EPSS

Signal	What it measures	Action for this CVE
CISA KEV	Known exploitation in the wild	Treat as emergency; patch by 2026-09-05 per CISA directive.
CVSS v3.1	Technical severity (10.0 Critical)	Confirms maximum impact; prioritize above most other work.
EPSS	Probability of exploitation in 30 days (0.01917, 78.868th percentile)	Moderate probability, but KEV status overrides; do not deprioritize.

Exploitation steps (defensive triage)

Defensive triage framing only; no weaponized payloads.

1. Reconnaissance: Identify internet-exposed Kestra OSS instances by scanning for the Kestra API or web interface. Check for versions prior to 1.0.45 or 1.3.21.
2. Exposure check: Determine whether the Kestra API is reachable from untrusted networks. Review firewall rules, reverse proxy configurations, and cloud security groups.
3. Log hunt: Search Kestra server logs for HTTP requests to API paths ending in /configs from unexpected source IPs, especially those without an Authorization header. Look for POST requests to /api/v1/*/configs or similar.
4. Workflow audit: Review recently created or modified workflows for script tasks using shell or Python plugins. Check for anomalous workflow names or execution patterns.
5. Process inspection: On the Kestra worker host, look for child processes of the Kestra Java process, particularly sh, bash, python, or curl.
6. Patch verification: After upgrading to 1.0.45 or 1.3.21, confirm the version and re-test that the /configs endpoint requires authentication for non-public paths.
7. Credential rotation: If compromise is suspected, rotate all secrets, API keys, and credentials accessible to Kestra workflows.
8. Forensics triage: Follow CISA’s BOD 26-04 Forensics Triage Requirements for any confirmed or suspected exploitation.

Indicators of compromise

Defenders should hunt for the following:

• Network: HTTP requests to API paths ending in /configs from unexpected source IPs, especially those that are not the legitimate configuration endpoint. Look for POST requests to /api/v1/*/configs or similar.
• Logs: Kestra server logs showing workflow creation or execution events from unauthenticated sessions. Search for AuthenticationFilter bypass patterns or anomalous workflow names.
• EDR: Process execution inside the Kestra worker container, particularly sh, bash, python, or curl spawned by the Kestra Java process. Look for child processes of the Kestra worker.
• Behavioral: Sudden creation of new workflows with script tasks, especially those using shell or Python plugins. Unusual outbound network connections from the Kestra worker.
• File system: New files in /tmp, /var/tmp, or Kestra's working directories. Modified or new workflow YAML files.
• Authentication: Absence of Basic Auth headers in requests that should be authenticated. Monitor for requests to /configs endpoints with no Authorization header.
• Container: Unexpected root processes, new cron jobs, or modified startup scripts inside the container.
• Cloud: If Kestra runs in cloud environments, look for unusual API calls from the instance's IAM role or service account.

Mitigation and workarounds

• Immediate patching: Upgrade Kestra OSS to version 1.0.45 or 1.3.21 (or later). These versions fix the suffix match by using an exact path match for the /configs endpoint.
• Vendor guidance: Follow the official Kestra security advisory GHSA-5vc5-wxxq-3fjx for detailed instructions.
• Compensating controls: If patching is not immediately possible, restrict network access to the Kestra API using a reverse proxy or firewall. Ensure that only trusted IPs can reach the API. Disable or restrict script execution plugins if they are not essential.
• Authentication hardening: Enforce strong authentication and consider adding an additional authentication layer (e.g., OAuth2 proxy) in front of Kestra.
• Least privilege: Run Kestra containers as non-root users and limit container capabilities. Avoid mounting sensitive host directories.
• Monitoring: Enable detailed audit logging and monitor for the indicators listed above.
• CISA BOD 26-04: Follow the directive's guidance for prioritizing security updates and forensics triage requirements. For cloud services, apply the applicable guidance or discontinue use if mitigations are unavailable.

Community reactions

The vulnerability has garnered significant attention due to its critical severity and CISA KEV listing. Security media outlets have highlighted the ease of exploitation and the fact that no public PoC is required, as the flaw is straightforward. The Kestra community and maintainers have released patches promptly, and the GitHub Security Advisory provides a clear description. Discussions on platforms like Twitter and Reddit emphasize the importance of not exposing Kestra instances to the internet and the risks of default-enabled script plugins. Some defenders have shared detection rules and hunting queries. The CISA KEV addition with a three-day deadline has prompted urgent patching efforts across federal agencies and private organizations.

FAQ

Q: Is CVE-2026-49869 in CISA KEV? A: Yes, CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-02.

Q: What is the CISA remediation due date? A: The due date is 2026-09-05, giving federal agencies and their vendors three days to remediate.

Q: Is this vulnerability exploitable over the internet? A: Yes, if the Kestra API is exposed to the internet or an untrusted network, an unauthenticated attacker can exploit it remotely.

Q: Which Kestra products and versions are affected? A: Kestra OSS versions prior to 1.0.45 and prior to 1.3.21 are affected.

Q: How can I verify that my Kestra instance is patched? A: Check the Kestra version in the UI or API. Ensure it is 1.0.45 or 1.3.21 (or later). Then test that API paths ending in /configs (other than the legitimate public endpoint) require authentication.

Q: What should I do if I cannot patch immediately? A: Restrict network access to the Kestra API, disable script execution plugins if possible, and monitor for the indicators of compromise listed above. Follow CISA BOD 26-04 guidance for compensating controls.

Related resources

• Kestra 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 Entry for CVE-2026-49869
• Wiz Vulnerability Database: CVE-2026-49869