· via dev.to (home feed)
CVE-2026-58138: unauthenticated RCE in Orkes Conductor exploited in the wild
A CVSS 9.8 flaw in self-hosted Conductor OSS lets unauthenticated attackers execute OS commands through malicious workflow definitions, and exploitation attempts have already been observed.

Attackers are probing unpatched Conductor instances
Orkes Conductor, the open-source workflow orchestration engine used to coordinate microservices and, increasingly, AI agents, is being actively targeted through CVE-2026-58138, a critical remote code execution flaw with a CVSS v3.1 base score of 9.8. According to a dev.to writeup of Empirical Security's analysis, the firm observed exploitation activity in its telemetry on August 21, 2026, and SecurityWeek reported that Fortinet blocked roughly 1,300 exploitation attempts between September 8 and 9. Successful code execution in those attempts has not been publicly confirmed, so the observed activity may include a mix of scanning and genuine exploit delivery.
How the attack works
The root of the problem is that Conductor's Workflow API does not require authentication by default. An attacker with network reachability to an exposed instance can register a workflow definition containing an INLINE, LAMBDA, DO_WHILE, or SWITCH task that embeds a malicious JavaScript or Python expression, then start the workflow.
Those expressions are evaluated in a GraalVM context configured with broad host access, through HostAccess.ALL or allowAllAccess(true). That permits Java reflection and subprocess creation from inside the expression, which translates into operating system command execution running with the privileges of the Conductor process. In the default container image, Empirical Security notes, that process often runs as root.
No user interaction is required, and there may be no visible indicators in the Conductor UI, meaning operators of an exposed instance can be attacked without anything obviously changing on screen.
Affected versions and fixes
The vulnerability affects Conductor OSS versions 3.21.21 up to, but not including, 3.30.2. Exploitation succeeds when two conditions hold: the instance is running a vulnerable version, and the Workflow API is reachable without authentication or network controls in front of it.
The fixes are straightforward to state: update to version 3.30.2 or later, restrict the Workflow API to internal networks, and enforce authentication and authorization for workflow registration and execution.
What defenders should look for
Empirical Security's indicators focus on four areas:
- Workflow definitions that were not created by legitimate users, especially INLINE, LAMBDA, DO_WHILE, or SWITCH tasks whose expressions reference Java reflection, Runtime, ProcessBuilder, or subprocess calls.
- External POST requests to the Workflow API, followed by outbound DNS resolution and retrieval from the Conductor host.
- Child processes such as shells, Python interpreters, or curl spawned by the Java or Conductor process, visible in endpoint or EDR telemetry.
- Audit logs covering workflow definitions, execution history, secret references, and connected APIs in SaaS or cloud environments.
The behavior maps to MITRE ATT&CK T1190 (Exploit Public-Facing Application) and T1059 (Command and Scripting Interpreter). One practical gap: identifying who registered a malicious definition is difficult unless an API gateway or audit logging sits in front of the instance.
Recommended response
For containment, the analysis recommends updating to 3.30.2 or later, blocking external access to the API, isolating compromised instances, and rotating credentials and secrets accessible to Conductor. Confirming actual compromise means correlating malicious workflow initiation with Conductor child processes or command output, and then corroborating any secret access, connection changes, or command-and-control activity with secondary evidence.
Several questions remain open, including how many environments were successfully exploited, which commands were run, who the actors are, how many unique sources and targets are behind the roughly 1,300 blocked attempts, and how far the issue reaches into Orkes Cloud editions and derivative distributions.
Why it matters
Conductor is rarely recognized as a standard asset in enterprise inventories, yet it occupies a privileged position at the center of microservice and AI agent topologies. It holds service credentials and connects to data stores, internal services, and agents, so a single pre-authentication RCE enables lateral movement in proportion to everything the engine can touch. Because instances often ship inside products, containers, and developer-managed environments that security teams do not track, many organizations may be running vulnerable versions without knowing it. That makes discovery, through SBOMs, container inventories, and exposure reviews, just as urgent as patching, and it argues for pairing the update with privilege reduction, network restrictions, and a trim-down of the secrets Conductor holds.
- #security
- #vulnerability
- #orkes-conductor
- #workflow-orchestration
- #rce