- The Mess: Orkes Conductor versions 3.21.21 through 3.30.1 contain an unauthenticated RCE caused by unsandboxed GraalVM script evaluation. A crafted workflow can cross from JavaScript or Python expressions into OS command execution.
- The Damage: An exposed Conductor API can become a remote shell on the workflow server without requiring an account.
- The Fix: Upgrade to Conductor 3.30.2 or later and restrict network access to the workflow API immediately.
Workflow engines are supposed to execute instructions.
That is the whole point.
The problem starts when an attacker gets to write those instructions without authentication.
That is what makes CVE-2026-58138 nasty.
Orkes Conductor versions from 3.21.21 through 3.30.1 are affected by an unauthenticated remote-code-execution vulnerability involving GraalVM script evaluators. The vulnerability received a CVSS 3.1 score of 9.8 Critical and a CVSS 4.0 score of 9.3 Critical. The fix landed in version 3.30.2.
And there is a public working exploit.
The workflow definition becomes the payload
Conductor lets clients define workflows containing different task types.
Some tasks can evaluate JavaScript or Python expressions.
That functionality is useful when the expression remains inside a properly restricted execution environment.
The vulnerable implementation did not provide that boundary.
The affected GraalVM contexts could be configured with unrestricted host access, including HostAccess.ALL or equivalent full-access behavior. An attacker-controlled expression could then reach Java classes and ultimately execute operating-system commands.
Conceptually:
Unauthenticated HTTP request
|
v
Malicious workflow definition
|
v
INLINE / LAMBDA / DO_WHILE / SWITCH
|
v
GraalVM evaluator
|
v
Host JVM access
|
v
java.lang.Runtime
|
v
OS command execution
There is no password in that chain.
That is the problem.
The vulnerable versions are old enough to be everywhere
The affected range is:
3.21.21 <= version < 3.30.2
The fixed release is:
3.30.2
The vulnerability was publicly disclosed on June 30.
Since then, exploit material has appeared publicly, including a functional reproduction kit and Exploit-DB tooling.
That changes the defensive calculation.
This is no longer:
“Someone found a theoretical code-execution path.”
It is:
“Someone documented the path, published the PoC and demonstrated command execution.”
The attack does not need a fancy exploit chain
The public research demonstrates the basic attack flow:
1. Reach Conductor API
↓
2. Submit malicious workflow
↓
3. Register workflow
↓
4. Start workflow
↓
5. GraalVM evaluates attacker-controlled expression
↓
6. JVM host access is reached
↓
7. OS command executes
The exploit repositories demonstrate unauthenticated workflow registration and execution against vulnerable Conductor installations.
That makes Internet exposure particularly dangerous.
An attacker does not need to compromise an application that talks to Conductor first.
The Conductor API itself becomes the entry point.
GraalVM was supposed to be the sandbox
This is the interesting technical failure.
GraalVM provides a polyglot execution environment.
That makes it attractive for workflow engines because developers can execute expressions without building a completely separate scripting system.
But there is an enormous difference between:
execute JavaScript
and:
execute JavaScript with access to the host JVM
The first can be a feature.
The second can become a shell.
The vulnerable configuration effectively allowed attacker-controlled script to cross the language boundary and interact with Java host functionality.
Researchers reproduced paths involving Java reflection and Runtime.exec().
The resulting security boundary looked like:
JavaScript
|
| supposed to stop here
X
|
v
Java host classes
|
v
Runtime
|
v
Operating system
Once the script reaches the host JVM, the workflow engine has stopped being a workflow engine from the attacker’s perspective.
It has become a command-execution interface.
Multiple task types are involved
This is not limited to one obscure workflow feature.
The vulnerability description identifies multiple task types that can reach the vulnerable evaluator:
INLINE
LAMBDA
DO_WHILE
SWITCH
That matters for defenders because searching for only one task type can produce false confidence.
An attacker does not necessarily need to use the most obvious execution path.
The important detection question is whether untrusted workflow definitions can reach an unsafe evaluator.
Why an orchestration server is a valuable target
Conductor is not a random standalone application.
It is an orchestration engine.
It coordinates workflows across services and records workflow state and execution history. Orkes describes Conductor as an engine that orchestrates workflows across services and languages, with self-hosted deployments supported alongside managed environments.
That gives a successful attacker a useful position inside an environment.
The compromised server may have:
API credentials
service credentials
database access
internal network access
cloud credentials
workflow definitions
service URLs
application secrets
The exact blast radius depends on deployment architecture.
But the attacker starts from a server that already knows how to talk to other systems.
That is valuable.
The public PoC makes scanning easier
The vulnerability is particularly uncomfortable because exploitation has moved beyond a purely theoretical stage.
There are multiple public repositories containing working proof-of-concept implementations. One reproduction kit explicitly states that it was tested against Conductor 3.23.0 and demonstrates the vulnerable workflow-to-GraalVM-to-command-execution path.
Exploit-DB also lists a Conductor unauthenticated RCE exploit from August 10.
That means defenders should assume that vulnerable Internet-facing installations are discoverable.
You do not need an elite threat actor.
A scanner plus a public PoC is enough to turn a vulnerability into an operational problem.
There are also reports of exploitation attempts against CVE-2026-58138, although the available telemetry does not justify attributing those attempts to a particular actor or claiming broad confirmed exploitation.
The fix is already available
The upstream project fixed the vulnerable behavior in 3.30.2. The relevant patch commits changed the GraalVM execution restrictions.
The important security principle is simple:
Untrusted expression
|
v
GraalVM
|
X host access
X process creation
X arbitrary I/O
X environment access
The newer implementation tightens those permissions instead of treating the evaluator as a fully trusted Java runtime.
If you are running:
3.21.21
3.22.x
...
3.30.0
3.30.1
you should not wait for the next normal maintenance cycle.
Upgrade.
Do not expose Conductor unnecessarily
Patching is mandatory.
Network isolation is still important.
A workflow orchestration API should not be sitting on the public Internet just because the application technically works that way.
A better architecture is:
Internet
|
v
Authenticated application/API
|
v
Internal network
|
v
Conductor
|
+---- internal services
+---- workers
+---- databases
Not:
Internet
|
v
Conductor :8080
If external access is required, put appropriate authentication and network controls in front of it.
But do not treat authentication as a substitute for patching.
Run Conductor as a non-root user
This is another important mitigation.
Even if the application is vulnerable, the operating-system account running the process determines the immediate impact.
Bad:
Conductor
|
v
root
Better:
Conductor
|
v
conductor
|
X
system root
A successful RCE running as an unprivileged service account is still serious.
It can steal credentials, access application data and pivot through the network.
But it is materially better than handing the attacker UID 0 immediately.
Public research has demonstrated command execution as the Conductor process user, with some lab deployments running the service as root.
What defenders should hunt for
The vulnerability gives defenders some useful detection opportunities.
Look at workflow definitions containing suspicious expressions.
Search for references involving:
getClass
forName
Runtime
exec
ProcessBuilder
java.lang.reflect
java.
These are not automatically malicious.
A legitimate workflow could contain some of them.
But in an unexpected workflow submitted by an unknown user, they deserve immediate attention. Researchers specifically identified these patterns while analyzing the vulnerable execution path.
At the host level, watch the Conductor JVM for unexpected child processes:
java
└── sh
└── ...
or:
java
└── bash
On Windows deployments, investigate unexpected:
java.exe
└── cmd.exe
Also monitor unexpected outbound connections from the Conductor host.
A workflow engine suddenly spawning shells and reaching arbitrary Internet destinations is not normal workflow orchestration.
Check workflow history
Because Conductor is a workflow engine, attackers have another place to leave evidence: workflow definitions and execution history.
Review:
new workflows
modified workflows
unexpected workflow owners
unusual task definitions
INLINE expressions
recent execution spikes
unknown workflow names
A malicious workflow may be created only long enough to execute a command and then deleted.
That means historical telemetry is much more useful than looking only at the current workflow catalogue.
If you were vulnerable, investigate before declaring victory
Suppose your server was:
Conductor 3.30.1
+
Internet reachable
+
No authentication
and you upgraded today.
Good.
But the question remains:
Was it already exploited?
Check:
- HTTP access logs;
- workflow registration events;
- workflow execution history;
- authentication records;
- process telemetry;
- outbound connections;
- filesystem modifications;
- environment variables;
- service-account credentials.
Search around the period beginning with public disclosure and especially after public PoCs appeared.
Do not restrict the investigation to the exact CVE string.
Attackers do not have to send:
CVE-2026-58138
in an HTTP request.
They send a workflow.
The broader problem is bigger than Conductor
CVE-2026-58138 is another reminder that scripting engines are dangerous security boundaries.
The pattern keeps repeating:
User input
↓
Template
↓
Interpreter
↓
Runtime
↓
Host access
Every arrow needs a security boundary.
If the interpreter can access:
filesystem
environment
network
Java classes
process creation
native libraries
then it is not a harmless expression evaluator.
It is a programming environment.
And if that environment accepts unauthenticated input, you have effectively built a remote code execution API.
Bugstoday’s take
This vulnerability is nasty because the exploit path does not look like classic RCE at first.
It starts with a workflow.
Then an expression.
Then a script evaluator.
Then GraalVM.
Then the host JVM.
Then the operating system.
Five abstractions later, the attacker has a shell.
That is exactly why sandbox boundaries matter.
CVE-2026-58138 is rated 9.8 under CVSS 3.1, has public exploitation tooling, and affects Conductor versions before 3.30.2.
If you run Conductor:
Upgrade to 3.30.2 or newer. Restrict the API. Run the service without root privileges. Then inspect your workflow history.
A workflow engine should execute workflows.
It should not execute arbitrary commands for anonymous strangers.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- CVE-2026-58138 — CVE / vulnerability record
- Conductor OSS — 3.30.2 release
- Conductor OSS — security patch commit
- GitHub Advisory Database — CVE-2026-58138
- OpenTaint — technical analysis of CVE-2026-58138
- Public reproduction kit
