Orkes Conductor pre-auth RCE exploited: patch your workflows

If you run workflow orchestration in production, the platform scheduling your pipelines might be handing attackers root on a plate. Orkes Conductor, an open-source workflow engine used by more than 3,000 enterprises, has a critical unauthenticated remote code execution vulnerability under active exploitation right now.

A single unauthenticated POST gives attackers root on the system that orchestrates your entire pipeline, and the fix shipped without a security label for four weeks.

CVE-2026-58138 carries a CVSS v3.1 score of 9.8. Attackers can send a single POST request to an unauthenticated API endpoint and execute arbitrary operating system commands on your Conductor host, often as root. FortiGuard telemetry shows 1,290 attack attempts blocked in the last 24 hours, a 132% jump in daily activity, with 6,696 attempts blocked over the past week, according to FortiGuard Labs. The fix has been available since June, but the patch shipped without a security label, meaning advisory-driven tooling had nothing to flag for nearly a month. If your Conductor instance faces the internet, treat this as a breach investigation, not a patch job.

What exactly is CVE-2026-58138 and how does exploitation work?

Orkes Conductor lets you define workflows with inline script tasks that evaluate JavaScript or Python expressions at runtime. The engine builds these evaluators on a GraalVM context configured with HostAccess.ALL, a setting that effectively disables the sandbox. An attacker can include a malicious expression in an INLINE, LAMBDA, DO_WHILE, or SWITCH task that reflects across to java.lang.Runtime and calls out to the operating system.

The open-source server enforces no authentication by default and leaves its workflow API wide open. As Empirical Security explains, a single unauthenticated POST to the workflow API registers a workflow with a hostile INLINE task and starts it. The commands then run as the Conductor process, which in the default container image is often root. The vulnerability affects Conductor versions 3.21.21 before 3.30.2, according to the NVD entry.

Here is the attack chain in plain terms:

• Attacker sends a POST to /api/metadata/workflow or /api/workflow with a workflow definition containing a malicious JavaScript or Python expression.
• Conductor evaluates that expression in a GraalVM context with HostAccess.ALL, which permits access to the Java runtime.
• The expression uses Java reflection to reach java.lang.Runtime or ProcessBuilder and executes OS commands.
• Those commands run with the privileges of the Conductor process, typically root inside the default container.

Public proof-of-concept exploit code is available, including a working exploit targeting Conductor v3.23.0 and an entry on Exploit-DB, SecurityWeek reported. A verified Nuclei template also exists for detection. The barrier to exploitation is approximately zero for any internet-exposed instance running a vulnerable version.

Why is an orchestrator compromise architecturally worse than a normal app RCE?

A typical application RCE gives an attacker code execution on one host. An orchestrator RCE gives an attacker code execution on the system that commands every other system in your pipeline. That distinction matters enormously for blast radius.

Conductor sits at the center of your workflow graph. It dispatches tasks to workers, reads from and writes to your message queues, connects to your databases, and holds the credentials to reach all of them. When an attacker gets root on your Conductor host, they get the keys to every downstream system the orchestrator touches: queue brokers, databases, cloud APIs, model-provider keys, internal services. This is why the Vibe Coding Security advisory recommends treating any internet-exposed instance as compromised and rotating every credential the orchestrator or its workers held.

Persistence is also nastier than a typical RCE. An attacker who controls the workflow engine can plant a scheduled workflow that re-executes their payload on a timer. You patch the host, but the hostile workflow fires again next cycle. Reviewing workflow definitions created or modified since early August is essential, because persistence in a workflow engine is a scheduled workflow.

This is the same class of risk seen in other AI-adjacent orchestration tools. The Langflow RCE attacks followed the same pattern: an exposed evaluation endpoint, no authentication, and access to the host runtime. The lesson keeps repeating because orchestrators are designed to reach everything by default.

How long has this been exploitable and who is being targeted?

The timeline reveals a gap that should worry anyone running an asset discovery program:

• June 3, 2026: The fix shipped in Conductor 3.30.2, described in release notes only as restricting GraalVM JavaScript further. No security label, no CVE attached.
• June 30, 2026: CVE-2026-58138 was published, nearly four weeks after the fix was available.
• Early August 2026: Proof-of-concept exploit code was published, including an Exploit-DB entry.
• August 21, 2026: Empirical Security identified in-the-wild exploitation.
• September 8 to 9, 2026: Fortinet blocked roughly 1,300 exploitation attempts over two days.
• September 19, 2026: Fortinet released an outbreak alert on the ongoing exploitation.

For that month between the patch and the CVE, advisory-driven feeds had nothing to point at. If your patch program waits for a CVE before acting, you were blind for four weeks. FortiGuard telemetry shows the highest volumes of attack activity originating from Germany, Hong Kong, Indonesia, the United Arab Emirates, and India, suggesting broad opportunistic scanning rather than a targeted campaign against specific victims.

The chart below shows the escalation in FortiGuard blocked attempts over recent periods, with daily activity up 132% and weekly activity up 17% week over week.

What should you do right now if you run Conductor?

First, upgrade. Move to Conductor 3.30.2 or later and restart the service. Do not stop at 3.30.0 or 3.30.1, which shipped only a partial blocklist. The complete fix stops rebuilding the script evaluator on HostAccess.ALL, blocks the reflection and process classes an exploit needs, specifically Runtime, ProcessBuilder, Process, System, and reflection primitives, and disables host class loading, native access, thread and process creation, and file and environment access in the GraalVM context. The Python evaluator no longer runs with allowAllAccess(true).

Second, restrict network access. The open-source server exposes every API endpoint with no authentication. Put Conductor behind a reverse proxy that requires authentication, or a Spring Boot security filter, and take the API off any untrusted network. On builds before 3.30.2 there is no configuration flag that safely disables the INLINE and LAMBDA script evaluators, so network isolation is the lever you have. Restrict who can reach /api/metadata/workflow and /api/workflow.

Third, if your instance was reachable from the internet after early August, treat the host as compromised. Follow your incident response playbook: rotate every credential the orchestrator or its workers held, including queue, database, cloud, and model-provider keys. Review workflow definitions for INLINE, LAMBDA, DO_WHILE, or SWITCH tasks whose evaluatorType is javascript, graaljs, or python and whose expression references getClass, forName, Runtime, ProcessBuilder, or array reflection.

Fourth, monitor for signs of compromise. Watch the Conductor JVM for child processes it should never spawn, such as sh -c or cmd. Run the verified Nuclei template for CVE-2026-58138 to confirm whether your instance is vulnerable or already exploited.

Here is a prioritized checklist:

• Upgrade to Conductor 3.30.2 or later and restart. Do not use 3.30.0 or 3.30.1.
• Isolate the API. Put Conductor behind an authenticated reverse proxy. Remove it from any untrusted network immediately.
• Investigate if the instance was internet-exposed after August 1. Assume compromise and follow your IR playbook.
• Rotate every credential the orchestrator or its workers could access: message brokers, databases, cloud provider keys, model API keys.
• Review workflow definitions created or modified since August 1 for attacker-planted tasks. Look for suspicious INLINE, LAMBDA, DO_WHILE, or SWITCH expressions.
• Monitor the Conductor JVM for unexpected child processes and network connections.
• Validate with the Nuclei template to confirm the patch took effect.

The patch you cannot see is the patch you cannot apply

The four-week gap between the fix and the CVE is the sharpest lesson from CVE-2026-58138. If your patch program depends on advisory feeds to tell it what to patch, you were running vulnerable for a month with no signal. The fix existed. The label did not. Orkes shipped 3.30.2 on June 3 with release notes that mentioned restricting GraalVM JavaScript and nothing else. No CVE, no security advisory, no flag that would surface in a vulnerability scanner.

This is a workflow orchestrator used by more than 3,000 enterprises, running critical pipelines, holding credentials to downstream systems, and often exposed on the default container image as root. The gap between fix and advisory is the gap attackers exploit. The PoC landed in August. Exploitation followed within weeks. If you cannot inventory your Conductor instances, you cannot patch them. If you cannot patch them, you are relying on network isolation that may or may not exist. Find your orchestrators, patch them, and assume the ones you missed are already owned.

Sources

• FortiGuard Labs - Threat Signal Report on Orkes Conductor CVE-2026-58138
• securityweek.com - Critical Orkes Conductor Vulnerability Exploited in Attacks
• research.empiricalsecurity.com - September 2026 CVE of the Month: CVE-2026-58138
• nvd.nist.gov - CVE-2026-58138 Detail
• pranava0x0.github.io - Orkes Conductor advisory
• thehackernews.com - Critical Pre-Auth RCE in Orkes Conductor Workflow Platform Exploited in the Wild