Attackers Are Breaking Into Orkes Conductor Servers Through a Critical Pre-Login Flaw

Key points

• Fortinet's FortiGuard team says it is seeing live attack attempts against Orkes Conductor servers vulnerable to CVE-2026-58138, a critical flaw published on 30 June 2026.
• The bug carries a CVSS v4 score of 9.3 and lets an attacker run operating system commands without logging in first.
• A working proof-of-concept exploit targeting Conductor version 3.23.0 is public, and further exploit code has been posted to Exploit-DB.
• Orkes fixed the flaw in Conductor 3.30.2; every release from 3.21.21 up to that version is affected.
• The weakness sits in the platform's GraalVM script evaluators when configured with unrestricted host access.

Attackers have started hunting the public internet for exposed Orkes Conductor servers, according to a FortiGuard outbreak alert issued this week. Orkes Conductor is a workflow orchestration platform: software companies use to string together automated business tasks across their internal systems. It's the kind of infrastructure that sits quietly in the middle of everything, which is precisely why a foothold there matters.

The flaw, tracked as CVE-2026-58138, needs no password. An attacker who can reach the workflow API over the network can submit a malicious workflow definition and have the server run commands on their behalf.

What does the vulnerability actually do?

It lets an unauthenticated attacker execute operating system commands on the Conductor server with the privileges of the Conductor process. The technical cause, per the NVD record, is that Conductor's GraalVM script evaluators can be set up with HostAccess.ALL or allowAllAccess(true). Those settings remove the sandbox that would normally stop a script from touching the underlying machine.

With the sandbox gone, an attacker can send JavaScript or Python expressions inside INLINE, LAMBDA or SWITCH task types, then use Java reflection or direct subprocess calls to run arbitrary commands. The server was designed to run little scripts as part of a workflow. On vulnerable installations, those scripts can reach out and take over the whole machine.

Which versions are affected?

Orkes Conductor 3.21.21 up to, but not including, 3.30.2. The fix is in 3.30.2 or later.

How serious is the exploitation?

FortiGuard describes the activity as active attack attempts against vulnerable deployments, not confirmed breaches. What raises the temperature is the exploit code. A working proof-of-concept aimed at Conductor v3.23.0 is circulating, and additional material has been published through Exploit-DB, a well-known public database of exploit scripts. Once a reliable exploit lands on Exploit-DB, opportunistic scanning tends to follow within days.

We've reported on this pattern before. The Langflow campaign we covered on 1 September showed how quickly internet-exposed AI infrastructure gets probed once working exploit code is out: over 360 attacks hit tracking sensors in the UK in a single day.

My read: this is a textbook pre-auth remote code execution flaw in a niche but privileged piece of enterprise plumbing. Conductor sits in the middle of automated pipelines, so compromise there means a foothold on everything those pipelines touch. Patch windows measured in weeks aren't appropriate here.

What should teams running Conductor do now?

Upgrade to Orkes Conductor 3.30.2 or later, and treat any internet-exposed instance running an earlier version as potentially already probed. Fortinet's advisory points operators to the fixed release as the primary remediation.

Where an immediate upgrade isn't possible, restrict network access to the workflow API so it's unreachable from the public internet, and review GraalVM evaluator configuration to remove HostAccess.ALL and allowAllAccess(true) settings. Log review should focus on unexpected workflow definitions submitted to the API, particularly ones containing inline JavaScript or Python.