CVE-2026-49869: Kestra OSS OS Command Injection Vulnerability
Kestra OSS contains an OS command injection vulnerability that could allow an unauthenticated remote attacker to create and execute arbitrary workflows without credentials.
Overview
Kestra OSS contains an authentication bypass flaw in its AuthenticationFilter that allows any unauthenticated remote attacker to create and execute arbitrary workflows. The filter uses a suffix match on the request path to whitelist the public configuration endpoint, so any API route ending in the segment 'configs' skips Basic Auth entirely. Because Kestra ships with shell and script execution plugins active by default, an attacker who reaches the Kestra port can chain workflow creation with execution to run arbitrary OS commands as root inside the worker container. Versions before 1.0.45 and versions from 1.1.0 before 1.3.21 are affected.
Vulnerability details
The root cause is an incomplete path-matching allowlist in AuthenticationFilter. The filter calls endsWith('/configs') to identify the public configuration endpoint and skip Basic Auth, but a suffix match is not an exact match. Any API route whose final path segment is 'configs' satisfies the check, including the FlowController's PUT route for creating workflows and the ExecutionController's POST route for triggering them. This is a CWE-287 authentication bypass compounded by a CWE-184 incomplete allowlist: the intended whitelist covers one endpoint but the implementation covers an unbounded set of routes sharing the same suffix.
An attacker with network access to the Kestra port (default 8080 or 32776) sends two unauthenticated HTTP requests. First, a PUT to the flows endpoint with a YAML workflow definition containing attacker-controlled shell commands using the built-in plugin-script-shell or plugin-script-python task types, both installed by default. Second, a POST to the executions endpoint triggers the workflow. The Kestra worker spawns a container and executes the commands as uid=0 (root). The attacker can then retrieve full command output from the execution logs. A secondary path allows SSRF against internal services, including cloud metadata endpoints, via the Pebble template engine's unfiltered http() function.
Severity and impact
Exploitation status
This vulnerability is confirmed as actively exploited in the wild — it is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Detection and monitoring
- Monitor HTTP server logs for unauthenticated PUT requests to paths matching the pattern /api/v1//flows//configs or POST requests to /api/v1//executions//configs with no Authorization header present. These routes have no legitimate unauthenticated callers.
- Audit Kestra execution logs for workflow IDs named 'configs' in any namespace, particularly those containing task types io.kestra.plugin.scripts.shell.Commands, io.kestra.plugin.scripts.python.Script, or io.kestra.core.tasks.scripts.Bash created outside normal deployment pipelines.
- Alert on worker container spawns (Docker events or container runtime logs) that originate from executions with no corresponding authenticated session in the Kestra audit trail, especially containers that exit with stdout containing system file content such as /etc/passwd output.
Remediation
Additional hardening
- Upgrade Kestra OSS to version 1.0.45 (for the 1.0.x line) or 1.3.21 (for the 1.1.x through 1.3.x line), which replace the suffix match with an exact path check in AuthenticationFilter.
- Restrict network access to the Kestra port (8080 and 32776) to trusted internal hosts or a VPN boundary. The advisory confirms the instance does not need to be internet-facing for exploitation; any attacker with network reach can exploit this.
- Audit installed script execution plugins and remove any not required for production workflows (plugin-script-shell, plugin-script-python, plugin-script-node, and others). Reducing the available task types limits the RCE surface if the auth bypass is reached.
- Review Kestra worker container privileges and, where operationally feasible, configure containers to run as a non-root user to reduce the impact of command execution if a bypass is exploited before patching.
Key dates
References
- https://github.com/kestra-io/kestra/security/advisories/GHSA-5vc5-wxxq-3fjx
- https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
- https://nvd.nist.gov/vuln/detail/CVE-2026-49869
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-49869
Frequently asked questions
Does CVE-2026-49869 affect my FedRAMP authorization?
If Kestra OSS runs inside your authorization boundary, CVE-2026-49869 affects your Federal Risk and Authorization Management Program (FedRAMP) authorization directly. This vulnerability is listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, and its remediation deadline of September 5, 2026 has already passed. An unpatched KEV inside your boundary is an assessor finding. An overdue one is visible to both your assessor and your sponsoring agency. At this point, you remediate it or formally document the mitigation and the delay.
How does Knox help me handle CVE-2026-49869?
Knox does not patch your software. Remediating Kestra OSS is your responsibility under the FedRAMP shared-responsibility model. What Knox provides is the pre-authorized, single-tenant boundary to remediate within, along with continuous compliance monitoring and audit-artifact coverage that support your documentation for the next assessment cycle. Applying the fix is yours to own. Managing your compliance posture while you do it is not something you have to handle on your own.
How does Knox's monitoring help with vulnerabilities like this?
Knox's automated continuous monitoring platform watches your environment for newly disclosed vulnerabilities and compliance issues on an ongoing basis. For a vulnerability like CVE-2026-49869, that means exposure surfaces during continuous monitoring rather than only when an assessor flags it at a scheduled review. You see the problem earlier, when you still have time to act.
How do I get FedRAMP authorized with Knox?
Knox runs a FedRAMP-as-a-Service platform. It gives SaaS vendors a pre-authorized cloud boundary on AWS, Azure, and GCP. Your application inherits 60-80% of the required security controls. You reach FedRAMP authorization in about 90 days for roughly 90% less than the traditional $3.5M path. Book a meeting and Knox will map your path to authorization.
CVE-2026-49869's remediation deadline of September 5, 2026 has passed. What happens now?
An unremediated CVE-2026-49869 is already a Plan of Action and Milestones (POA&M) item. A growing POA&M list is precisely what turns a routine continuous-monitoring review into a difficult conversation with your sponsoring agency. Closing it out now and documenting the circumstances around the delay is what keeps your authorization intact and the agency relationship on solid footing.
Ready to achieve FedRAMP authorization in 90 days or less?
Schedule a meeting to discuss scope, parse readiness, and map your company’s accelerated path to FedRAMP authorization.
_Horizontal_RGB.png)
