Orkes Conductor CVE-2026-58138 Exploited Through Workflow APIs

Attackers are actively targeting Orkes Conductor CVE-2026-58138, a critical pre-authentication remote code execution vulnerability in the workflow orchestration platform.

The flaw affects Conductor versions 3.21.21 through 3.30.1. A remote attacker who can reach the vulnerable workflow API can submit inline workflow definitions containing malicious JavaScript or Python expressions before authentication. Vulnerable GraalVM evaluator configurations can then allow those expressions to execute operating-system commands. Conductor 3.30.2 contains the fix.

Fortinet has reported active exploitation attempts against vulnerable Conductor servers. Its FortiGuard IPS counts represent blocked attack attempts, not confirmed successful compromises.

Orkes Conductor CVE-2026-58138 at a Glance

How Malicious Workflows Escape the GraalVM Scripting Boundary

The distinctive problem in CVE-2026-58138 sits inside Conductor’s workflow expression processing.

CVE-2026-58138 affects Conductor’s GraalVM script evaluators through INLINE, LAMBDA, DO_WHILE, and SWITCH task types. Attacker-controlled JavaScript or Python expressions can lead to arbitrary OS command execution.

In earlier affected releases, vulnerable evaluator configurations included HostAccess.ALL for JavaScript and allowAllAccess(true) for Python, exposing host functionality that malicious expressions could abuse to execute OS commands.

An attacker who can reach an affected Conductor workflow API can submit a crafted workflow containing a malicious expression. The documented vulnerability allows affected evaluators to invoke operating-system commands through Java reflection or direct subprocess calls.

Successful exploitation executes commands with the privileges of the Conductor process. Seqra’s original reproduction against Conductor 3.23.0 confirms command execution through the vulnerable workflow evaluator.

The attack path can be summarized as:

Reachable Conductor API → malicious workflow definition → insufficiently restricted GraalVM evaluation → access to host execution capabilities → OS command execution

What Fortinet Observed in Active CVE-2026-58138 Attacks

The vulnerability moved beyond proof-of-concept testing into observed attack activity.

Fortinet observed exploitation attempts targeting susceptible Conductor servers with crafted workflow definitions containing JavaScript or Python expressions. As of September 9, FortiGuard IPS had blocked 1,290 attempts within 24 hours, which Fortinet described as a 132% increase in daily activity.

Across September 2–9, FortiGuard IPS blocked nearly 7,000 exploitation attempts. Most observed attack activity originated from Germany, Hong Kong, Indonesia, the UAE, and India. However, these source locations do not establish attacker location or attribution.

Additional telemetry supports active exploitation attempts. Previdian reported three honeypot attempts from two IP addresses beginning July 24. Empirical Security also reported recurring exploitation activity, including activity observed on August 21. These honeypot and sensor observations indicate scanning or exploitation attempts against CVE-2026-58138, not confirmed compromises of internal or production networks.

Moreover, the available reporting does not establish a broader post-exploitation campaign involving a named threat actor, malware family, persistence mechanism, credential theft, lateral movement, or data exfiltration. Therefore, those outcomes should not be presented as confirmed consequences of the observed activity.

How to Mitigate CVE-2026-58138

Organizations running affected versions should upgrade to Conductor 3.30.2 or later, which contains the fix for CVE-2026-58138.

Organizations unable to upgrade immediately should restrict untrusted access to affected workflow API endpoints and place exposed Conductor OSS instances behind appropriate authentication and network controls. These measures reduce exposure but do not replace upgrading to a fixed release.

Security teams should also inspect workflow activity for unexpected definitions, suspicious JavaScript or Python expressions, and command execution originating from the Conductor process.

Where Hexnode Fits Around Conductor RCE Response

Remediating Orkes Conductor CVE-2026-58138 starts with updating Conductor itself. Hexnode UEM should not be treated as a substitute for the application or server deployment process used to upgrade the affected Conductor instance.

However, Hexnode can support endpoint security workflows around the incident.

Investigate suspicious endpoint activity with Hexnode XDR

If suspected post-exploitation activity reaches supported Windows or macOS endpoints, Hexnode XDR can help security teams investigate endpoint behavior from its security console.

Hexnode XDR provides threat hunting, endpoint investigation, process metadata and Process Tree analysis, device isolation, process termination, and file quarantine capabilities. These controls can support investigation and containment when suspicious endpoint activity appears after a suspected compromise.

This does not mean Hexnode XDR specifically detects CVE-2026-58138 exploitation. The role is endpoint investigation and response to associated suspicious activity.

Use Hexnode UEM for supported endpoint update workflows

Hexnode UEM provides advanced patch-management workflows for Windows and macOS, while other supported platforms use platform-native update-management mechanisms with platform-specific capabilities.

For Windows and macOS, Hexnode provides OS patch-management workflows and supported application-update workflows, with application patch coverage and requirements varying by platform.

Hexnode also provides custom-script execution for managed Windows, macOS, and Linux endpoints. Administrators can use supported scripting workflows to perform appropriate administrative, operational, and command-based management tasks.

While server application updates should be handled via your Conductor deployment pipeline, Hexnode UEM can assist in executing custom management scripts across supported host endpoints.

Featured resource

Why XDR Is Stronger With UEM

See how combining endpoint management with XDR can connect proactive device hygiene, security context, investigation, and threat response.

Download the whitepaper

What Enterprises Should Do About CVE-2026-58138

Organizations operating Conductor should prioritize several actions:

1. Identify Conductor versions and locate deployments running 3.21.21 through 3.30.1.
2. Upgrade to Conductor 3.30.2 or later using the appropriate application or server deployment workflow.
3. Restrict workflow API exposure to trusted networks and authorized systems.
4. Review workflow definitions for unexpected INLINE, LAMBDA, DO_WHILE, or SWITCH expressions.
5. Investigate unexpected command execution associated with Conductor processes.
6. Review affected systems for post-exploitation evidence rather than assuming that installing the update removes an existing compromise.
7. Use endpoint detection and response controls to investigate suspicious processes or files on supported endpoints where relevant.

CVE-2026-58138 demonstrates the security risk of allowing workflow scripts to reach host functionality. In this case, insufficient GraalVM restrictions allowed attacker-controlled workflow logic to reach host capabilities and execute operating-system commands.

With active exploitation reported, upgrading Conductor and reducing API exposure should take priority. Endpoint investigation can then help determine whether suspicious activity extended beyond the vulnerable orchestration service.