Orkes Conductor CVE-2026-58138: A Workflow Definition Is All It Takes to Get Root
Security

Orkes Conductor CVE-2026-58138: A Workflow Definition Is All It Takes to Get Root

An unauthenticated attacker can submit a workflow whose inline script task runs OS commands as the Conductor process, often root. Patched in 3.30.2; exploited in the wild since August, not yet in CISA KEV.

orkes conductorremote code executiongraalvmcode injectionworkflow orchestration

Orkes Conductor, the open-source workflow orchestration engine that started life at Netflix and now runs task graphs for microservices and AI agents inside a long list of enterprises, has a pre-authentication remote code execution flaw that attackers are actively working. Tracked as CVE-2026-58138, it lets anyone who can reach the Conductor API register a workflow whose inline script task runs arbitrary operating-system commands as the Conductor process. VulnCheck, the CNA that published the record, rates it 9.8 on CVSS v3.1 and 9.3 on CVSS v4. There is no clever chain here and no memory-corruption primitive to line up. You submit a JSON workflow definition, and the server runs your code.

What Happened

Conductor evaluates small snippets of JavaScript or Python inside workflows through its INLINE task, plus the LAMBDA, DO_WHILE, and SWITCH tasks that share the same evaluator. Those snippets run in a GraalVM polyglot context. The problem was how that context was built: with HostAccess.ALL for the JavaScript evaluator and allowAllAccess(true) for Python. Both settings hand the guest script the keys to the host Java runtime. From inside a supposedly sandboxed expression, an attacker uses Java reflection to reach java.lang.Runtime and call exec(), or constructs a ProcessBuilder directly. The commands run with the privileges of the Conductor process, which in the typical containerized deployment is root.

The open-source Conductor server ships without authentication or access control on its API. Those are features of the commercial Orkes Conductor product, not the OSS engine. So on a default self-hosted install, registering a malicious workflow is unauthenticated. The public proof-of-concept posts a workflow containing a hostile INLINE task to the metadata endpoint, triggers it, then reads the command output back through the workflow status endpoint. It is a clean request-response loop against an API that was never meant to be exposed but frequently is.

VulnCheck's advisory and the NVD record classify the bug as CWE-94, code injection. This is not the first time this exact pattern has bitten Conductor: CVE-2025-26074, published in 2025, described unauthenticated command execution in Conductor 3.21.11 through the same unrestricted access to Java classes. The 2026 fix is the more thorough second attempt at closing a door that was propped open by design.

Who Is Affected

The vulnerable range is Conductor 3.21.21 up to but not including 3.30.2, covering both the conductor-oss community builds and Orkes distributions built on them. If you run a self-managed Conductor server in that range and its API is reachable by an attacker, you are exposed. Internet exposure is the worst case, but any attacker who lands on your internal network and can route to the Conductor API, default port 8080, gets the same unauthenticated code execution. Treating an internal orchestration plane as safe because it is behind the perimeter is exactly the assumption this class of bug punishes.

The uncomfortable part is knowing whether you run it at all. Conductor is frequently embedded as an internal automation backbone rather than adopted as a named product, and Empirical Security, which featured this as its CVE of the month, made the point that many operators do not realize Conductor is running in their stack. That is the difference between a flaw you patch on the day of disclosure and one that sits unnoticed for a quarter. Anyone who has ever tried to keep track of the open-source dependencies that never file a security advisory knows the shape of this problem.

Technical Analysis

The maintainers landed the fix across two commits before the CVE was even public. In May, commit 87a7d96 ("Deny access to some classes in js evaluator, deny host access in python evaluator") replaced the blanket HostAccess.ALL with an explicit denylist blocking Class, ClassLoader, the reflection primitives Method, Field, Constructor, and Array, and the system classes Runtime, ProcessBuilder, Process, System, Thread, and ThreadGroup. The Python evaluator lost its allowAllAccess(true). A follow-up commit, c691e35 ("Restrict graaljs further"), turned off the GraalVM context's allowHostClassLoading, allowNativeAccess, allowCreateThread, allowCreateProcess, allowIO, and allowEnvironmentAccess, and disabled the load, print, and console built-ins that let a script pull in external code. Both commits shipped tests that fire a real reflection-to-Runtime.exec payload and confirm it now fails.

That two-step is the whole lesson of running untrusted code in an in-process language engine: a polyglot sandbox is not a security boundary until you have explicitly taken away host classes, reflection, process creation, native access, and I/O. The default posture of these engines is convenience, not containment. A scripting sandbox is only as safe as its host-access policy, and Conductor's was set to trust everything.

The fix shipped in version 3.30.2, released in early June 2026. The CVE was published on 30 June. A working exploit reached Exploit-DB in early August, and public proof-of-concept repositories followed. That gap, roughly two months between the quiet upstream patch and weaponization, is the window self-hosted operators had to notice and act, and most did not, because nothing forced their hand.

Immediate Actions

Upgrade Conductor to 3.30.2 or later. That is the fix, and there is no partial version of it. If you cannot patch immediately, the mitigations reduce reachability rather than remove the bug: pull the Conductor API off any internet-facing interface, put a authenticating reverse proxy or network allowlist in front of it so unauthenticated workflow submission is no longer possible, and restrict which hosts can reach port 8080. Standing up authentication in front of a service that ships without it is the durable version of this control, not just an emergency stopgap.

Assume compromise if your instance was exposed. Fortinet reported blocking roughly 6,700 exploitation attempts in the first week of September and 1,290 in a single day around 9 September, a 132 percent daily spike, with sources concentrated in Germany, Hong Kong, Indonesia, the UAE, and India. Empirical Security observed in-the-wild exploitation as far back as 21 August, and Previdian logged honeypot hits from late July. If your server ran a vulnerable build while reachable, hunt for unexpected child processes of the Conductor process, review workflow definitions for unfamiliar INLINE tasks, and rotate every credential the process could touch, since code execution as the service account means every secret it holds is now suspect.

Long-Term Outlook

CVE-2026-58138 is the same story as its 2025 predecessor, which tells you the underlying risk is architectural, not a one-off bug. In-process script evaluation with host access is a standing liability, and orchestration platforms that expose an unauthenticated API multiply it. The practical takeaways outlast this single patch: never expose a control-plane API that lacks its own authentication, treat every embedded scripting feature as attacker-reachable code execution until proven sandboxed, and build a way to learn about fixes in the open-source components you depend on before the exploit shows up. Notably, this flaw is not yet on CISA's Known Exploited Vulnerabilities catalog despite confirmed exploitation, so operators waiting for a federal deadline to prioritize it are waiting on the wrong signal.

Sources

  • https://nvd.nist.gov/vuln/detail/CVE-2026-58138
  • https://www.vulncheck.com/advisories/orkes-conductor-unauthenticated-rce-via-graalvm-script-evaluators
  • https://github.com/conductor-oss/conductor/commit/87a7d96aabbb706d6e84f812b93da5165028d18f
  • https://github.com/conductor-oss/conductor/commit/c691e35e768caeb802c9f06ecdd9674c80081af1
  • https://www.securityweek.com/critical-orkes-conductor-vulnerability-exploited-in-attacks/
  • https://www.fortiguard.com/threat-signal-report/6527/orkes-conductor-evaluator-remote-code-execution
  • https://research.empiricalsecurity.com/research/september-2026-cve-of-the-month
  • https://thehackernews.com/2026/09/critical-pre-auth-rce-in-orkes.html