Exposed Orkes Conductor APIs Turn Workflow Scripts Into Root-Level Attack Paths

Orkes Conductor deployments are being targeted through a critical code-injection flaw that lets unauthenticated attackers execute operating-system commands by submitting malicious workflow definitions.

Tracked as CVE-2026-58138, the vulnerability affects Conductor 3.21.21 and subsequent releases before 3.30.2. Version 3.30.2 contains the fix. Internet-facing installations using the default open-source configuration face the greatest risk because the workflow API may be accessible without authentication.

This is no longer a theoretical weakness. Empirical Security detected exploitation on August 21, while Fortinet blocked roughly 1,300 attempts between September 8 and September 9 and issued an outbreak alert covering continued activity.

Affected Conductor releases and deployment conditions

Orkes Conductor is an open-source framework for coordinating microservices, application workflows, and AI agents. The vulnerable component processes JavaScript and Python expressions embedded in workflow definitions.

The affected version range is:

• Affected: Conductor 3.21.21 through all releases before 3.30.2
• Fixed: Conductor 3.30.2
• Weakness: CWE-94, Improper Control of Generation of Code
• Attack type: Unauthenticated remote code execution
• Privileges required: None
• User interaction: None described
• Attack surface: The Conductor workflow API

The default open-source server configuration reportedly does not enforce authentication on the relevant API. An attacker who can reach that interface may consequently submit a hostile workflow without first obtaining credentials.

SecurityWeek reported that the flaw was patched in June. Proof-of-concept exploit code appeared in early August, followed shortly by real-world attacks. The precise number of compromised organizations and the geographical distribution of the activity are not known.

No threat actor has been identified.

GraalVM host access breaks the script sandbox

Conductor supports script-bearing tasks that evaluate inline JavaScript or Python. The vulnerable releases create GraalVM evaluators using highly permissive settings, including:

• HostAccess.ALL
• allowAllAccess(true)

Those options allow evaluated expressions to interact broadly with the Java host environment. Instead of remaining confined to a limited scripting context, attacker-controlled code can reach Java functionality, use reflection, or start subprocesses.

The technical descriptions identify four exploitable Conductor task types:

• INLINE
• LAMBDA
• DO_WHILE
• SWITCH

An attack begins with a request to the exposed workflow API. The attacker supplies a workflow definition containing a malicious expression in one of these task types, then causes the workflow to execute. GraalVM evaluates the expression with unrestricted host access, allowing it to invoke operating-system commands through the Java runtime.

Under the vulnerable default configuration, this process can require only one unauthenticated API request. There is no reported need for social engineering, an existing account, or interaction from an administrator.

The resulting commands inherit the permissions of the Conductor process. That detail materially changes the potential damage: Conductor services frequently run as root, according to the available reporting. In those environments, exploitation can move directly from application-level code injection to full control of the underlying host.

Exploitation accelerated after public proof-of-concept code

Evidence of active attacks emerged soon after exploit instructions became publicly available. Empirical Security observed exploitation on August 21. Fortinet later recorded approximately 1,300 blocked attempts during the two-day period from September 8 to September 9.

Fortinet’s subsequent outbreak alert indicates that scanning and exploitation did not end with that burst of traffic. The available information does not disclose the payloads delivered in every attempt, the infrastructure used by attackers, or whether the activity represents one operation or several unrelated campaigns.

CVE-2026-58138 carries a CVSS v3.1 score of 9.8, Critical, with the vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

That assessment reflects network accessibility, low attack complexity, no authentication requirement, no user interaction, and high potential impact across confidentiality, integrity, and availability.

A CNA-provided CVSS v4.0 assessment from VulnCheck rates it 9.3, Critical, using:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

The NVD record displays VulnCheck’s v4.0 assessment but has not supplied its own CVSS v4.0 score. NVD published the record on June 30, 2026, last modified it on July 14, 2026, and marks it “Not Scheduled” for additional enrichment.

As of September 18, 2026, the available NVD information does not show CVE-2026-58138 in CISA’s Known Exploited Vulnerabilities catalog. No CISA remediation deadline is therefore available. The absence of a listed KEV deadline does not change the direct evidence that attackers are already exploiting the flaw.

A successful request can expose hosts and connected services

The immediate result of exploitation is arbitrary command execution under the Conductor service account. If that account is privileged, an attacker could take complete control of the server.

Potentially exposed assets include application credentials, environment variables, workflow data, API secrets, and configuration files stored on the host. Attackers may also alter or delete workflows, install persistence, make unauthorized outbound connections, or modify application files.

The risk can extend beyond the Conductor server. Because the platform coordinates microservices and other workflows, a compromised instance may hold credentials or network access to downstream systems. Deployments that orchestrate AI agents could similarly expose agent workflows, associated secrets, or connected services.

Not every exploitation attempt necessarily results in full infrastructure compromise. Effective impact depends on operating-system permissions, network segmentation, available secrets, and the access Conductor has to other services. Instances running as root with broad internal connectivity represent the most severe case.

No campaign-specific indicators, malicious IP addresses, file hashes, or command strings have been disclosed. Defenders must therefore rely on behavioral evidence and workflow auditing rather than a fixed indicator list.

Upgrade first, then investigate previous exposure

Administrators should upgrade to Conductor 3.30.2 or later. Restricting network access can reduce exposure, but it does not remove the vulnerable evaluation behavior from older versions.

Conductor should not be directly accessible from the public internet unless there is a documented operational requirement. Organizations should place the service behind a firewall or controlled gateway and enforce authentication and authorization for workflow-management functions.

Security teams should inspect newly created or modified workflows for unexpected JavaScript or Python, with particular attention to INLINE, LAMBDA, DO_WHILE, and SWITCH tasks. Script content that reaches Java classes, uses reflection, or attempts to create subprocesses deserves immediate investigation.

Host-level monitoring should look for:

• Shells or command interpreters launched by the Conductor or Java process
• Unexpected Java child processes
• Unusual subprocess creation from workflow execution
• Unauthorized changes to workflows or application files
• New persistence mechanisms or scheduled tasks
• Credential and environment-variable access
• Unexplained outbound network connections
• Activity performed through the Conductor service account

Any affected instance that was reachable from an untrusted network should be treated as potentially compromised, even after upgrading. The update blocks the known vulnerability but cannot remove persistence or reverse commands already executed.

Responders should preserve relevant API, workflow, application, process, authentication, and network logs before rebuilding or cleaning systems. They should also rotate secrets available to the Conductor process and review downstream services for unauthorized access.

No separate vendor workaround has been disclosed. For exposed installations, upgrading and conducting a retrospective compromise assessment are the primary defensive actions.