By If you run Orkes Conductor — or any self-hosted deployment of Conductor OSS — and you have not upgraded to version 3.30.2, you have a CVSS 9.8 unauthenticated remote code execution on your workflow API. Attackers are not waiting. Fortinet blocked nearly 7,000 exploitation attempts between September 2 and 9 alone, with a 132% single-day spike. CVE-2026-58138 lets anyone POST a malicious workflow definition and run arbitrary OS commands on your server — no credentials required.
What Is Orkes Conductor?
Conductor started as Netflix’s internal workflow orchestration engine and went open-source under Apache 2.0. Orkes, founded by Conductor’s original authors, built the enterprise layer on top. The platform is now used by JP Morgan Chase, Tesla, Atlassian, Oracle, American Express, and GE Healthcare — thousands of organizations relying on it to coordinate microservices, AI agents, and long-running business processes. Orkes raised $60M in April 2026 as AI-driven workflow orchestration became central to production AI stacks.
This is not a niche tool. If your organization has bet on durable execution for AI workloads in the past two years, there is a real chance Conductor is in your stack.
How the Exploit Works
Conductor’s INLINE, LAMBDA, DO_WHILE, and SWITCH task types let workflow definitions include embedded JavaScript or Python expressions — lightweight scripting for data transformations, conditional logic, that kind of thing. The evaluator runs these expressions inside a GraalVM context. The problem: that context was configured with HostAccess.ALL, GraalVM’s most permissive setting, giving scripts unrestricted access to Java host objects including Runtime.exec() and ProcessBuilder.
An attacker submits a workflow definition containing a hostile INLINE task. The payload uses Java reflection to invoke a shell command. Conductor evaluates it. The command runs with the privileges of the Conductor process. No authentication required — the workflow API endpoint accepts unauthenticated requests, and Conductor OSS ships with authentication disabled by default.
A public proof-of-concept has been available since early August. Working exploits targeting v3.23.0 are on GitHub and Exploit-DB. The entry bar for attackers is low.
The Exploitation Surge
The vulnerability was patched in June 2026 with version 3.30.2. The PoC dropped in early August. By early September, Fortinet’s FortiGuard telemetry was recording over a thousand blocked exploitation attempts per day. The primary payloads: cryptocurrency miners, reverse shells, and credential harvesting from stored workflow configurations.
That last item matters. Conductor workflow definitions routinely carry service credentials — database passwords, API keys, cloud service tokens — as input variables or metadata. A successful exploit isn’t just a foothold. It’s the keys to everything your workflows touch. If you suspect compromise, rotate all credentials stored in Conductor before doing anything else.
Attack traffic has originated from Germany, Hong Kong, Indonesia, the UAE, and India, suggesting organized campaigns rather than individual opportunists. The exploitation pattern mirrors what FortiGuard documented with Langflow’s CVE-2026-33017 in March: PoC drops, exploitation starts within days, ransomware and mining operations move fastest.
What to Do Right Now
First, determine your version. Check the Conductor dashboard under System → About, or inspect the JAR manifest. Anything from 3.21.21 through 3.30.1 is vulnerable.
Upgrade to 3.30.2 or later. This is the fix. The patch properly sandboxes the GraalVM evaluator context — using a restricted HostAccess policy instead of allowing unrestricted Java host access. Both Orkes Conductor and Conductor OSS 3.30.2+ include the fix.
If you cannot patch immediately:
- Block the workflow API endpoint (
/api/workflow) at your reverse proxy or WAF — allow only from trusted internal IPs - Enable Conductor’s built-in authentication if running OSS (it is disabled by default)
- Disable INLINE and LAMBDA task types at the server configuration level if your workflows don’t use them
- Ensure the Conductor server is not exposed directly to the internet under any circumstances
The Pattern Behind the Pattern
Conductor is the second major AI workflow platform to ship a pre-auth RCE through an embedded scripting evaluator this year. Langflow had the same category of vulnerability in March. The Microsoft Security Blog observed in May that “AI workflow tooling adopted in the past two years is at the same maturity stage Jenkins and Airflow were at ten years ago — but with a richer credential store and faster adoption curve.”
This pattern has a name: embedded scripting convenience traded for security by default. Platforms that offer INLINE script evaluation are choosing developer ergonomics over safe defaults. The safer architectural choice — which Temporal and Apache Airflow made — is to push code execution to external workers that the orchestrator never directly evaluates. The flexibility of scripting directly inside a workflow definition comes at a cost that CVE-2026-58138 is making explicit.
If you run any AI orchestration platform that evaluates user-supplied scripts, this week is a good time to audit its sandbox configuration. “No authentication by default” and “HostAccess.ALL” are a combination the security community has seen end badly, repeatedly, across a decade of similar tools. The platforms are new. The mistake is not.
