Orkes Conductor CVE-2026-58138: Exploitation Activity Observed Against Unauthenticated Workflow RCE

1. Basic Information

• Original Title: September 2026 CVE of the Month: The 9.8 Nobody Knows They Are Running (CVE-2026-58138)
• Source: Empirical Security
• Publication Date: September 1, 2026
• Updated Date: None
• Severity: Critical
• Basis of Severity: Sending malicious workflow definitions to the Conductor OSS Workflow API, which lacks authentication by default, allows OS commands to execute with the privileges of the Conductor process, which is often root in the default container image. Empirical Security observed exploitation activity in its telemetry, while SecurityWeek reported that Fortinet blocked about 1,300 attempts. Successful code execution in those attempts has not been publicly confirmed.
• Reference: September 2026 CVE of the Month: The 9.8 Nobody Knows They Are Running (CVE-2026-58138)
• Related Source: SecurityWeek Coverage
• Related Entities: CVE-2026-58138, Orkes Conductor, conductor-oss, GraalVM, INLINE, LAMBDA, DO_WHILE, SWITCH

2. Executive Summary

Attackers can register and start workflows containing malicious JavaScript or Python expressions through an unpatched, publicly exposed Conductor Workflow API, enabling OS command execution through GraalVM's HostAccess.ALL.

3. Attack Flow

OS Command Execution via Pre-Authentication API

1. An attacker discovers an externally reachable Conductor Workflow API.
2. The attacker submits a workflow definition containing an INLINE, LAMBDA, DO_WHILE, or SWITCH task with a malicious JavaScript or Python expression.
3. The definition is registered without authentication, and the workflow is started.
4. Java reflection or subprocesses are invoked from the GraalVM context configured with HostAccess.ALL or allowAllAccess(true).
5. OS commands are executed with the privileges of the Conductor process, potentially enabling access to connected systems and sensitive data.

4. Attacker Position and Execution Environment

• An unauthenticated remote attacker with network reachability to the Workflow API.
• Commands are executed within the Conductor host or container under the privileges of the Conductor process, which may be root in default containers.

5. Visibility for Victims and Administrators

• Victims: No user interaction is required, and there may be no visible indicators on the UI.
• Administrators: Unauthorized workflow definitions, INLINE or similar task types containing suspicious expressions, external POST requests to the Workflow API, and unexpected child processes or outbound traffic from Conductor serve as indicators.

6. Conditions for Success and Failure

Conditions for Success

• Using a vulnerable version of Conductor OSS from 3.21.21 up to, but not including, 3.30.2.
• The Workflow API is reachable and not protected by authentication or network controls.

Conditions for Failure

• Updating to version 3.30.2 or later and restricting the Workflow API to internal networks.
• Denying external workflow registration and execution through authentication, authorization, and network controls.

7. Impact upon Success

• Arbitrary OS commands are executed with the privileges of the Conductor process.
• Compromise may spread to data, credentials, microservices, and AI agents connected by the workflow.

8. Observable Logs

• Email: No email vector involvement has been confirmed.
• Proxy / SWG / DNS: Check for external POST requests to the Workflow API and subsequent outbound name resolution and retrieval.
• Endpoint / EDR: Check for child processes such as shells, Python, or curl spawned by the Java or Conductor process.
• Identity / IdP: The attack itself occurs pre-authentication. Verify service credentials utilized after a compromise.
• SaaS / Cloud: Check audit logs for workflow definitions and execution history, secret references, and connected APIs.
• Network: Check for suspicious POST requests to public APIs and unknown destination traffic originating from Conductor.

9. Attack Success Assessment

Confirmed in Public Information

• Attack Attempts Observed (Success Unconfirmed): Empirical Security observed exploitation activity in telemetry on August 21, 2026, and SecurityWeek reported that Fortinet blocked about 1,300 attempts between September 8 and 9. Successful code execution for individual attempts has not been confirmed.

Internal Assessment Criteria

• Confirm Initial Execution: Correlate malicious workflow initiation with Conductor child processes or command output.
• Confirm Subsequent Compromise: Corroborate secret access, connection modifications, C2 activity, and additional payloads with secondary evidence.

10. Investigation Playbook

• Trigger: Start with unpatched, publicly exposed Conductor instances, unknown INLINE expressions, and suspicious Workflow API POST requests.
• Initial Verification: Check version, exposure scope, authentication configuration, definition creator, and execution timestamp.
• Endpoint: Preserve Java process trees, containers, file modifications, and shell history.
• Authentication and Cloud: Enumerate secrets and service accounts accessible to Conductor and revoke them as needed.
• Subsequent Activity: Track audit logs and data access for destinations connected by the workflow.
• Containment: Block APIs, update to version 3.30.2 or later, isolate compromised instances, and rotate credentials.
• Classification: Distinguish between scanning, definition registration, execution initiation, OS command execution, and destination compromise.

11. Defense and Detection Ideas

• Single Event: Detect definitions in INLINE or similar fields containing Java reflection, Runtime, ProcessBuilder, or subprocess calls.
• Time-Series Correlation: Correlate unauthenticated API POST requests, workflow initiation, Java child processes, and outbound network traffic.
• Hunting: Inventory all Conductor OSS versions, exposure scopes, root execution status, and unknown workflows.
• Log Gaps: Identifying the definition creator is difficult without API gateways or audit logs.
• Prioritized Mitigations: Prioritize updates, making instances private, implementing authentication and authorization, avoiding root execution, and minimizing secrets.

12. Facts, Inference, and Hypothesis

Facts

• CVE-2026-58138 affects Conductor versions 3.21.21 through 3.30.1 (>= 3.21.21 and < 3.30.2) and has a CVSS v3.1 base score of 9.8.
• The issue stems from broad host access within the GraalVM context used for evaluating user expressions.
• Empirical Security observed active exploitation in the wild, and SecurityWeek reported approximately 1,300 blocked attempts by Fortinet.

Inference

• The more service credentials Conductor holds, the wider the potential for lateral movement from host RCE; therefore, privilege reduction is required alongside patching.

Hypothesis

No additional hypotheses. Unverified items are documented in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application (Confidence: high): Exploits public Workflow APIs.
• T1059 Command and Scripting Interpreter (Confidence: high): Executes OS commands from JavaScript or Python expressions.

14. Unknowns and Additional Investigation

• The number of successfully exploited environments, executed commands, and threat actors involved.
• The number of unique attack sources and targets among the approximately 1,300 attempts blocked by Fortinet.
• The specific impact scope on Orkes Cloud editions and various derivative distributions.

15. Impact on SOCs and Organizations

Because Conductor is rarely recognized as a standard asset, yet holds high privileges at the center of microservices and AI agents, organizations must discover instances including SBOMs, containers, and developer self-managed environments while simultaneously reviewing exposure scope and secret privileges.

16. Summary by Role

• SOC: Correlate Workflow APIs, definition contents, Java child processes, and destination audit logs.
• Administrators: Update to version 3.30.2 or later, make APIs private and authenticated, and operate with non-root privileges and least privilege.
• Users: No general user action required. Developers should avoid executing suspicious workflows.

Comments

[Sammi De Blas]

The 'what actually ran vs what was submitted' framing is the right one, and the diff between those two sets is itself a finding class: submitted-but-no-spawn is a failed or blocked attempt (still an attack indicator), and spawn-without-submission means either record destruction or an out-of-band trigger.

The wrinkle is where the join key lives. Workflow definitions and execution records are exactly the records an unauthenticated attacker can delete - they had write access to the API, which is the same gap that makes this 'nobody knows they're running it.' A join keyed on workflow ID or name will read clean if the attacker did their homework: definition deleted after execution, and both sides of your join agree there was nothing.

So I'd design the join to not need the middle layer. The durable pair is the HTTP access log entries to the Workflow API (server-side, an unauthenticated caller can't reach them) and the child process spawn events from the Conductor PID (OS-side). Timestamp-correlate those two: a spawn from the Conductor PID with no surviving workflow definition behind it is an orphan spawn - deletion or never recorded - and an API POST with no spawn inside the window is the failed-attempt side. Both survive definition deletion; only log tampering kills them, which is a different (and louder) finding.

[Anoymask]

Thanks, Sammi. You’re right that workflow definitions and execution records can be deleted via the API. Looking beyond those records and using telemetry that is harder for an attacker to alter or remove makes a lot of sense.

Your suggestion to correlate HTTP access logs with OS-level telemetry for processes spawned by Conductor is definitely worth exploring, especially when workflow records are missing. I appreciate you sharing this insight!

[Sammi De Blas]

One trick that worked for us: hash the workflow definition at submission time and store that hash in the process audit record, so a deleted definition still leaves a verifiable fingerprint of what was supposed to run.

[Anoymask]

That's a great approach. Preserving the workflow-definition hash in an independent audit record would provide a useful reference even if the original definition is deleted.

Thanks for sharing this practical insight and for the thoughtful discussion!

[Sammi De Blas]

Apologies for the slow reply. Keeping the definition hash outside the workflow store matters, since the attacker can delete the definition itself. An independent record is what proves what ran versus what was submitted.

[Sammi De Blas]

The 'nobody knows they are running it' angle is what makes this one interesting from a detection standpoint: an unauthenticated Workflow API with GraalVM HostAccess.ALL means the exposure is not the application, it is the default deployment. In my environment I would treat externally reachable conductor-oss as a P1 finding - check asset inventory and cloud DNS for exposed workflow APIs first, then look for workflow definitions registered immediately before process-spawn events from the Conductor PID. That parent-child relationship is the signal that survives even when the payload changes.

[Anoymask]

The inventory gap worries me here too. We need to know where Conductor is running and whether its Workflow API is reachable from outside.

I’d also check the workflow execution records alongside those child-process events. That should help show what actually ran, not just what was submitted to the API, even when the payload changes.

[Sammi De Blas]

The hash only counts as evidence if the audit store is separate from the runner that can delete it.