Critical Orkes Conductor Vulnerability Exploited in Attacks

1. Executive summary

CVE-2026-58138 is an unauthenticated remote code execution vulnerability in Orkes Conductor, an open source framework used to orchestrate microservices, workflows and AI agents. The flaw sits in how Conductor evaluates user-supplied JavaScript or Python expressions in INLINE, LAMBDA, DO_WHILE and SWITCH tasks, and a single unauthenticated POST to the workflow API registers and starts a hostile workflow whose code executes OS commands as the Conductor process, which often runs as root. Verified reference data rates it CVSS 9.3 CRITICAL, CWE-94 (code injection), EPSS 9%, and it is not in CISA KEV. Note a discrepancy: the source article quotes CVSS 9.8; the verified NVD value of 9.3 is authoritative here. Exploitation is confirmed in the wild: Empirical Security identified attacks on 21 August 2026 and Fortinet blocked roughly 1,300 attempts between 8 and 9 September, following PoC publication in early August. Financial services clients running exposed or internally reachable Conductor deployments face unauthenticated root-level code execution on workflow infrastructure that frequently holds service credentials and integration secrets.

2. Regulatory framing

No NIS2 or UK NIS article is engaged by a fact distinctive to this item. Exploitation of a third-party product alone does not trigger NIS2 Art. 21(2)(d) supply chain measures or UK NIS duties beyond what any patching event requires.

3. Technical analysis & attack chain

Confirmed attack chain, reconstructed from the Empirical Security findings reported by SecurityWeek:

1. The attacker reaches a Conductor deployment whose workflow API is network-accessible. The open source server enforces no authentication by default and leaves the workflow API open.
2. A single unauthenticated POST registers a workflow containing a hostile INLINE task and starts it.
3. The INLINE task (or a LAMBDA, DO_WHILE or SWITCH task) evaluates the attacker-supplied JavaScript or Python expression.
4. Conductor builds the evaluator on a GraalVM context configured with HostAccess.ALL, which disables the sandbox.
5. The attacker-supplied code reflects into the Java runtime and executes OS commands as the Conductor process, which often runs with root privileges.

The vulnerability mechanism is the combination of two failures: the GraalVM HostAccess.ALL configuration removes the isolation that should contain evaluated expressions, and the default unauthenticated workflow API removes the barrier to submitting one. Either failure alone would be a hardening gap; together they give an unauthenticated remote attacker command execution at the privilege of the Conductor process. Because the payload is arbitrary JavaScript or Python evaluated in a GraalVM context, the attacker is not limited to a fixed payload format; any expression that can reach the Java runtime and invoke system commands works.

CVE-2026-58138 was patched in June 2026 in Orkes Conductor 3.30.2. PoC code was published in early August and exploitation began shortly after. Empirical Security identified in-the-wild attacks on 21 August 2026. Fortinet blocked roughly 1,300 exploitation attempts between 8 and 9 September 2026 and released an outbreak alert on the ongoing exploitation this week.

Two caveats on sourcing. First, the technical mechanism and the attack timeline rest on a single vendor, Empirical Security, relayed through one SecurityWeek article; the Fortinet attempt count is a second source but covers only the 8 to 9 September window. Treat the mechanism description as accurate but single-sourced; verify against your own telemetry before enforcing on it. Second, no attribution to any named actor is present in the source material, and no MITRE ATT&CK profile applies; attribution is unconfirmed and we make no claim about who is exploiting this. No post-exploitation detail, payload names, C2 infrastructure or victim sectors are given in the sources, so none is asserted here.

4. Mitigation & containment

P1, within 24 hours:

• Inventory for Orkes Conductor deployments, including instances embedded in internal developer platforms or AI agent infrastructure, and record their versions. Anything below 3.30.2 is vulnerable.
• Check whether Conductor workflow API endpoints are reachable from the internet or from broad internal networks. Block external access at the firewall and ensure Conductor services are not directly exposed to the internet. If an instance cannot be patched immediately, isolate it to a management network reachable only by authorised workflow submitters.
• For instances that were exposed and unpatched during the exploitation window (early August 2026 onward), review for signs of intrusion: unexpected workflow definitions, workflow submissions from unrecognised sources, and command execution originating from the Conductor process.

P2, within 72 hours:

• Update to Orkes Conductor 3.30.2 or later, the version that patched CVE-2026-58138.
• Where Conductor must remain network-reachable, put authentication in front of the workflow API; the open source server does not enforce it by default, so this requires an explicit control such as an API gateway or reverse proxy with enforced authn.
• Restrict the privilege of the Conductor process. The source states it often runs with root privileges; run it as a dedicated unprivileged service account instead, so that successful code injection does not yield host-level compromise.

P3, within 7 days:

• Monitor Conductor instances for suspicious workflow submissions and unauthorised command execution, per the vendor guidance, and alert on workflow registrations from sources outside the expected submitter set.
• Add hostile workflow submission to the resilience testing programme, consistent with DORA Art. 24, covering both the unauthenticated access path and the expression evaluation path.
• Review any third-party or managed service arrangements that deploy Conductor on your behalf and confirm their patch state, since the deployment may sit outside your direct asset inventory.

5. Indicators of compromise

No indicators of compromise available in the source material.

The sources describe observable behaviours but no atomic indicators. Behavioural indicators:

6. Detection

Insufficient indicators to author detection rules.

The sources give no file hashes, payload strings, command-line flags, mutexes, file paths or registry keys belonging to attacker artefacts. The behaviours in §5 are the usable detection material: alert on unauthenticated POSTs to the workflow API that register workflows, and on Conductor process child processes that indicate OS command execution. We will author rules if Empirical Security or Fortinet publish technical indicators.

CVE assessment

1 referenced CVE — 1 critical (CVSS ≥ 9.0)

7. Sources

• SecurityWeek, "Critical Orkes Conductor Vulnerability Exploited in Attacks", https://www.securityweek.com/critical-orkes-conductor-vulnerability-exploited-in-attacks/, 2026-09-18
• Empirical Security, technical findings on CVE-2026-58138, as reported in the SecurityWeek article above (single source for the vulnerability mechanism and attack timeline)
• Fortinet, outbreak alert on CVE-2026-58138 exploitation, as reported in the SecurityWeek article above (source for the ~1,300 blocked attempts between 8 and 9 September 2026)

8. Adverse Trace position

We assess this as a critical-severity exposure for any client running Orkes Conductor below 3.30.2, with verified CVSS 9.3, EPSS 9% and confirmed in-the-wild exploitation since 21 August 2026; it is not in CISA KEV, which we expect to change if exploitation volume grows. The severity is driven less by the CVSS number than by the deployment pattern: unauthenticated API plus root-privileged process plus sandbox-disabled expression evaluation gives an internet-facing attacker a one-request path to host compromise, and the same pattern is common in workflow and AI agent orchestration tooling beyond Conductor. The mechanism and timeline are single-sourced to Empirical Security and we flag that accordingly; the exploitation itself is corroborated by Fortinet's telemetry. We will monitor for CISA KEV listing, published IOCs from Empirical Security or Fortinet, and any attribution reporting, and we will update this advisory if indicators emerge that allow detection rule authoring.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.