On September 2, 2026, CISA added CVE-2026-49869 to the Known Exploited Vulnerabilities (KEV) catalog, confirming what defenders dread most: an unauthenticated OS command injection in Kestra OSS is being actively exploited in the wild. The flaw allows a remote attacker — no credentials required — to create and execute arbitrary workflows, which in a workflow orchestration platform means arbitrary command execution on the underlying host with the privileges of the Kestra service.
This is not a theoretical risk. Kestra is an open-source workflow orchestration and scheduling platform used by data engineering, platform, and DevOps teams to automate pipelines — which means it routinely holds cloud credentials, database connection strings, API keys, and SSH secrets in its flow definitions and secret store. A compromise here is not a single-host event; it is a springboard into your entire automation and data infrastructure.
If you run Kestra OSS anywhere in your environment — especially anything reachable from the internet — treat this as an active incident until proven otherwise. Per CISA BOD 26-04 (Prioritizing Security Updates Based on Risk) and the accompanying Forensics Triage Requirements, organizations must apply vendor mitigations on the mandated timeline, evaluate every asset for internet exposure, and discontinue use of the product if mitigations are unavailable.
Technical Analysis
What Is Affected
- Product: Kestra OSS (open-source workflow orchestration platform)
- Vulnerability type: OS Command Injection (CWE-78)
- Attack vector: Network, unauthenticated
- Impact: Remote attackers can create and execute arbitrary workflows without credentials — effectively unauthenticated remote code execution on the Kestra host
- Deployment models at risk: Standalone JAR, Docker containers, and Kubernetes (Helm) deployments — the vulnerability is in the application layer, so containerization does not meaningfully contain it (Kestra workers frequently mount the Docker socket or run with broad Kubernetes service-account permissions)
- Exploitation status: Confirmed active exploitation — listed in the CISA KEV catalog as of 2026-09-02
At time of writing, consult the official Kestra security advisories and release notes for the exact fixed version applicable to your deployment track; the KEV entry and CISA listing reference vendor instructions as the authoritative source. Do not wait for a CVSS score to drive urgency — KEV inclusion supersedes scoring debates.
Why This Bug Class Is So Dangerous in Kestra
Kestra's entire purpose is to execute tasks: shell scripts, Python, container jobs, API calls. A workflow definition is, by design, a structured way to say "run this command on this host." An unauthenticated path to the flow creation and execution APIs (typically exposed on the Kestra webserver, default TCP 8080) collapses the entire security model:
- Recon: Attacker scans for exposed Kestra instances (HTTP responses identifying the Kestra UI/API on 8080 or a reverse-proxied port).
- Access: No login required — the vulnerable endpoint accepts unauthenticated requests.
- Execution: Attacker submits a crafted workflow containing shell/script tasks; Kestra's worker executes it as the service account (
kestra,rootin default containers, or the Kubernetes pod identity). - Post-exploitation: Theft of secrets from the Kestra secret store and environment variables, lateral movement via cloud instance metadata (IMDS), persistence via new flows, cron-style triggers, or dropped binaries.
In default Docker deployments, many operators mount /var/run/docker.sock so Kestra can launch container tasks — which means host-level container escape is one command away. In Kubernetes, over-privileged service accounts turn this into a cluster compromise.
Detection & Response
Hunt on two planes: (1) evidence that the Kestra API was abused to create/execute flows, and (2) evidence that the Java/Kestra process spawned unexpected child processes. The second is your highest-fidelity signal — Kestra legitimately executes tasks, so context matters, but the Kestra host spawning shells, downloaders, or reconnaissance tooling outside expected job profiles is a strong indicator.
Sigma Rules
---
title: Kestra Host Spawning Suspicious Shell or Downloader
id: 4f2b8c1a-7e6d-4a9f-b3c5-9d1e2f8a7b6c
status: experimental
description: Detects the Kestra service (Java process) spawning shells, script interpreters, or download utilities on the orchestration host — a high-fidelity indicator of CVE-2026-49869 exploitation via malicious workflow execution.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-49869
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/03
tags:
- attack.execution
- attack.t1059
- attack.t1190
- cve.2026-49869
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\java.exe'
- '\javaw.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\rundll32.exe'
condition: selection_parent and selection_child
falsepositives:
- Kestra workflows legitimately invoking scripts — baseline known-good flows and filter on expected CommandLine patterns
level: high
---
title: Linux Kestra Worker Spawning Recon or Download Utilities
id: 8d3e5f2b-1a4c-4b7d-9e6f-2c8a3b5d7e9f
status: experimental
description: Detects Java (Kestra service) on Linux spawning shells, downloaders, or post-exploitation utilities consistent with arbitrary workflow execution via CVE-2026-49869.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-49869
- https://attack.mitre.org/techniques/T1059.004/
author: Security Arsenal
date: 2026/09/03
tags:
- attack.execution
- attack.t1059.004
- attack.t1105
- cve.2026-49869
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith: '/java'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/socat'
- '/python'
- '/python3'
- '/perl'
- '/base64'
- '/id'
- '/whoami'
- '/uname'
condition: selection_parent and selection_child
falsepositives:
- Legitimate Kestra shell/script tasks — correlate with flow execution logs and known job schedules; unexplained executions outside defined flows are the signal
level: high
---
title: HTTP Request to Kestra Flow or Execution API from External Source
id: 2b7c9d4e-5f6a-4e8b-a1c3-6d9e4f2a8b7c
status: experimental
description: Detects inbound HTTP requests to Kestra API endpoints used to create flows and trigger executions — the attack surface abused by CVE-2026-49869 for unauthenticated workflow execution.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-49869
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/03
tags:
- attack.initial_access
- attack.t1190
- cve.2026-49869
logsource:
category: webserver
detection:
selection_uri:
cs-uri|contains:
- '/api/v1/flows'
- '/api/v1/executions'
- '/api/v1/main/flows'
- '/api/v1/main/executions'
selection_method:
cs-method:
- 'POST'
- 'PUT'
- 'PATCH'
condition: selection_uri and selection_method
falsepositives:
- Legitimate CI/CD and automation clients creating/executing flows — filter to trusted source IP ranges and service accounts; external or unknown sources on these endpoints are high priority
level: medium
KQL — Microsoft Sentinel / Defender
The following hunts for Kestra abuse using process telemetry (Defender for Endpoint on the Kestra host or its containers) and network/web telemetry ingested via CEF/Syslog. Tune ParentProcessName to your deployment (Java runtime name may vary by image).
// Hunt 1: Kestra Java process spawning suspicious children (MDE-instrumented hosts)
let Lookback = 14d;
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName in~ ("java", "java.exe", "javaw.exe")
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","sh","bash","dash",
"curl","curl.exe","wget","nc","ncat","socat",
"python","python3","perl","certutil.exe","mshta.exe","base64")
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, FileName,
ProcessCommandLine, AccountName, RemoteIP, ReportId
| order by TimeGenerated desc;
// Hunt 2: Unauthenticated-style API hits against Kestra flow/execution endpoints (CEF/Syslog web logs)
let Lookback = 14d;
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where RequestURL has_any ("/api/v1/flows", "/api/v1/executions")
| where RequestMethod in ("POST", "PUT", "PATCH")
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
Hits=count(), Methods=make_set(RequestMethod), URLs=make_set(RequestURL)
by SourceIP, DestinationHostName
| where Hits > 0
| order by Hits desc;
// Hunt 3: Outbound connections FROM the Kestra host to rare external destinations (post-exploitation C2/exfil)
let Lookback = 14d;
let KnownGood = dynamic(["repo.maven.apache.org","github.com","docker.io","registry-1.docker.io"]);
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName in~ ("java","sh","bash","curl","wget","python","python3")
| where RemoteIPType == "Public"
| where not(RemoteUrl has_any (KnownGood))
| summarize Connections=count(), Ports=make_set(RemotePort), Processes=make_set(InitiatingProcessFileName)
by DeviceName, RemoteIP, RemoteUrl
| order by Connections desc;
Velociraptor VQL — Endpoint Hunt
Deploy this as a hunt across suspected Kestra hosts to triage for post-exploitation: unexpected child processes of Java, recently dropped executables in temp/working directories, and active outbound sockets from shell interpreters.
-- CVE-2026-49869 triage: Kestra host post-exploitation sweep
LET suspicious_procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)^(sh|bash|dash|curl|wget|nc|ncat|socat|python3?|perl)$'
AND CommandLine =~ '(?i)(http://|https://|base64|/dev/tcp|chmod \+x|/tmp/|/dev/shm/)'
LET java_children = SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(sh|bash|cmd\.exe|powershell|curl|wget)'
AND Ppid IN (SELECT Pid FROM pslist() WHERE Name =~ '(?i)java')
LET dropped_files = SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/tmp/*', '/dev/shm/*', '/var/tmp/*', '/opt/kestra/**/tmp/*'])
WHERE Mtime > now() - 1209600
AND NOT IsDir
LET outbound = SELECT Pid, Name, RemoteAddr, RemotePort, Status
FROM netstat()
WHERE Name =~ '(?i)(sh|bash|curl|wget|nc|python)'
AND RemoteAddr !~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)'
SELECT * FROM suspicious_procs
UNION ALL SELECT * FROM java_children
Verification & Hardening Script (Bash)
Run on Kestra hosts (or against your orchestration inventory) to identify exposure, confirm the running version, and apply immediate compensating controls while patching is scheduled.
#!/usr/bin/env bash
# CVE-2026-49869 - Kestra OSS exposure check and interim hardening
set -euo pipefail
echo "=== [1] Identify running Kestra instances ==="
docker ps --format '{{.Names}} {{.Image}} {{.Ports}}' 2>/dev/null | grep -i kestra || echo "No Kestra containers found via docker"
ps aux | grep -i [k]estra || echo "No standalone Kestra process found"
echo "=== [2] Check listening port 8080 exposure ==="
ss -tlnp 2>/dev/null | grep -E ':8080' || echo "Port 8080 not listening"
echo "=== [3] Confirm version (compare against vendor advisory for CVE-2026-49869 fix) ==="
docker exec $(docker ps -qf "ancestor=kestra/kestra" 2>/dev/null | head -1) \
java -jar /app/kestra.jar --version 2>/dev/null || \
echo "Query image tag: docker images | grep kestra — verify against Kestra release notes"
echo "=== [4] INTERIM: Block external access to Kestra API (allow only trusted admin CIDR) ==="
TRUSTED_CIDR="10.0.0.0/8" # <-- set to your admin/CI network
sudo iptables -C INPUT -p tcp --dport 8080 -s "$TRUSTED_CIDR" -j ACCEPT 2>/dev/null || \
sudo iptables -I INPUT -p tcp --dport 8080 -s "$TRUSTED_CIDR" -j ACCEPT
sudo iptables -C INPUT -p tcp --dport 8080 -j DROP 2>/dev/null || \
sudo iptables -A INPUT -p tcp --dport 8080 -j DROP
echo "iptables rules applied: 8080 restricted to $TRUSTED_CIDR"
echo "=== [5] Audit Kestra flow/execution logs for unexpected unauthenticated executions ==="
docker logs $(docker ps -qf "name=kestra" 2>/dev/null | head -1) 2>/dev/null | \
grep -Ei 'POST /api/v1/(flows|executions)' | tail -50 || \
grep -Ei 'POST /api/v1/(flows|executions)' /var/log/kestra/*.log 2>/dev/null | tail -50 || \
echo "Review Kestra server and reverse-proxy logs manually for flow-creation API calls"
echo "=== [6] Kubernetes deployments: check for over-privileged service accounts ==="
kubectl get clusterrolebinding -o wide 2>/dev/null | grep -i kestra || echo "No clusterrolebinding for kestra (good)"
echo "DONE. Patch per vendor advisory, then re-enable external access only behind authentication."
Remediation
- Patch immediately. Apply the fixed Kestra OSS release per the vendor's instructions referenced in the CISA KEV entry for CVE-2026-49869. Confirm your exact fixed version in the official Kestra GitHub security advisory / release notes for your deployment track before upgrading, and follow CISA BOD 26-04 mandated timelines — KEV-listed vulnerabilities are not "patch Tuesday" items; they are incident-response items.
- If you cannot patch: take it offline or wall it off. Per BOD 26-04 guidance, discontinue use of the product if mitigations are unavailable. At minimum, remove all internet exposure, place the Kestra UI/API behind an authenticating reverse proxy or VPN, and restrict TCP 8080 (or your configured port) to trusted CI/CD and admin CIDRs — the script above applies an interim iptables control.
- Inventory internet exposure now. BOD 26-04 places asset-exposure evaluation squarely on stakeholders. Query your ASM/EASM tooling and Shodan/Censys exposure for Kestra fingerprints. Anything answering on a public IP must be patched, proxied behind authentication, or shut down today.
- Enable Kestra authentication. If your OSS instance was running without configured auth, enable basic authentication / OIDC in
application.yml(micronaut.securitysettings) as a compensating layer — but understand this does not replace patching a confirmed-exploited injection flaw. - Hunt before you assume clean. Because exploitation is confirmed in the wild and the bug is unauthenticated, apply the Forensics Triage Requirements referenced by CISA: review Kestra execution history for flows you did not create, audit flow/execution API logs for unknown source IPs, and run the KQL/VQL hunts above across the host and its egress. Check for unexpected triggers, new users/secrets access, and child processes of the Java service.
- Assume secrets are compromised. If a Kestra instance was internet-exposed and unpatched during the exploitation window, rotate every secret the platform can reach: Kestra secret store entries, cloud IAM keys, database credentials, registry tokens, and any environment variables injected into workers. Rotate Kubernetes service-account tokens and review RBAC bindings for the Kestra namespace.
- Reduce blast radius going forward. Run Kestra workers without the Docker socket mounted where feasible; use rootless containers; scope Kubernetes service accounts to namespace-only, least-privilege roles; segment the orchestration host from data-plane networks; and send Kestra application and execution logs to your SIEM so flow-creation API calls are permanently auditable.
Bottom Line
CVE-2026-49869 is the worst-case profile for an orchestration platform: unauthenticated, remotely exploitable, actively abused, and sitting on a system whose entire job is to run commands and hold credentials. Patching is the floor, not the ceiling — exposure review, compromise assessment, and secret rotation are mandatory for any instance that was reachable during the exploitation window. Treat every exposed Kestra host as potentially compromised until your hunts say otherwise.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.