A high-severity vulnerability in Orkes Conductor is being actively exploited by attackers, security researchers have confirmed. The flaw—CVE-2026-58138—enables unauthenticated remote code execution (RCE) in versions of Conductor prior to 3.30.2, potentially allowing malicious actors to run arbitrary operating system commands.
What’s going on
Orkes Conductor is a workflow orchestration platform that developers use to manage complex, distributed workflows. In vulnerable versions (3.21.21 up to before 3.30.2), it contains a bug in how the workflow API evaluates inline definitions using JavaScript or Python expressions without requiring authentication. The issue arises from GraalVM evaluators configured with either HostAccess.ALL or allowAllAccess(true), which under certain task types—INLINE, LAMBDA, DO_WHILE, SWITCH—can be leveraged to escape sandbox constraints via Java reflection or subprocess invocation. These attack paths let malicious code execute with the full permissions of the Conductor process.
The National Vulnerability Database gauges this risk extremely highly: CVSS version 3.1 rates it 9.8, and version 4 rates it 9.3. That underscores how dangerous unauthenticated RCE bugs are, especially in orchestration platforms that often serve as backbone infrastructure for microservices or critical backend tasks.
Real-world exploitation & impact
Security vendor Fortinet has declared the flaw being exploited in the wild. Attackers send specially crafted workflow definitions to the Conductor API endpoint, embedding JavaScript or Python that abuses the evaluator settings to execute OS commands directly. Telemetry shows a surge in attacks: between September 2 and September 9, 2026, nearly 7,000 exploit attempts were blocked globally. Just from September 8-9, more than 1,290 daily attempts were observed, marking a 132% spike in daily activity. Major source locations include Germany, Hong Kong, Indonesia, the UAE, and India.
Independent honeypot operators also reported detection of real exploitation. One set detected attempts targeting their mock Conductor instances since July 24, 2026, from IPs in France and the U.S. Others have logged incidents as recently as August 21, confirming that threat actors are actively trying to abuse the vulnerability.
Mitigations & what to do now
The only sure fix is to upgrade Orkes Conductor to version 3.30.2 or later, which patches the vulnerability. For environments unable to immediately patch, it’s best to tightly restrict access to the workflow API endpoints, enforce strict network-level controls, and closely monitor inbound workflow definitions. Watch particularly for any unexpected or inline JS/Python expressions, as well as signs of system-level command execution.
Proper remediation also means auditing GraalVM evaluator configurations—avoid using unrestricted HostAccess or setting allowAllAccess(true) unless absolutely necessary and secure. Sandboxing misconfigurations are a common root cause when execution environments are allowed too much power.
What this vul-n reveals is the danger of overprivileged scripting environments in infrastructure platforms. Workflow engines like Conductor are central to modern cloud-native stacks; a single RCE there can ripple outwards, leading to supply-chain risks or cross-tenant compromise.
Organizations running older Conductor versions should prioritize upgrading while boosting detection capabilities. This incident should serve as a warning: even tools meant to simplify back-end orchestration can become serious attack vectors if the trust boundary between workflow definitions and execution environments isn’t airtight. Stay alert, patch fast, and assume that unauthenticated API endpoints are high-risk until proven safe.
