Attackers are hammering unpatched Orkes Conductor servers
Fortinet says it blocked nearly 7,000 attempts to exploit CVE-2026-58138, an unauthenticated remote code execution flaw in Orkes Conductor that was fixed at the end of June.
Attackers are hammering unpatched Orkes Conductor servers through a remote code execution flaw that needs no login at all, and the volume is climbing fast. Fortinet says it blocked 1,290 exploitation attempts in a single 24-hour window as of 9 September, a 132% jump on the daily average it had been recording.
The flaw is CVE-2026-58138, rated 9.8 on the CVSS 3.1 scale and 9.3 under CVSS 4.0. According to the National Vulnerability Database, Conductor versions from 3.21.21 up to but not including 3.30.2 will process inline workflow definitions before authentication, and those definitions can carry JavaScript or Python expressions.
Why a workflow engine is a way in
The problem sits in the GraalVM evaluators that Conductor uses to run those expressions. Where an operator has configured them with unrestricted host access – HostAccess.ALL, or allowAllAccess(true) – an attacker can step outside the scripting sandbox entirely. The NVD entry names INLINE, LAMBDA, DO_WHILE and SWITCH task types as the routes, and notes that commands can be issued through Java reflection or a direct subprocess call. Whatever runs, runs with the privileges of the Conductor process itself.
Because the crafted request arrives before authentication, there is no credential to steal and no session to hijack. The workflow API endpoint is simply reachable, and an inline definition is all it takes to start issuing operating system commands.
What Fortinet saw
Fortinet's outbreak alert says attackers are submitting crafted workflow definitions to the Conductor workflow API. The company blocked nearly 7,000 attempts between 2 and 9 September, with most of the traffic originating in Germany, Hong Kong, Indonesia, the United Arab Emirates and India.
Others are seeing it too, if less of it. Previdian's telemetry logged three exploitation attempts against its honeypots from two IP addresses – one in France, one in the United States – since 24 July, and Empirical Security says it detected in-the-wild exploitation as recently as 21 August. That spread of dates matters. This is not one campaign that ran for a week; it is opportunistic scanning that keeps finding the same unpatched service.
What to do about it
The repair is a version bump to Conductor 3.30.2 or later, and both the fix and the release notes are public in the open-source Conductor repository referenced by the NVD entry. Where patching has to wait, the sensible defaults are the obvious ones: stop exposing the workflow API directly to the open internet, tighten what the expression evaluators are permitted to touch, and look for POST requests carrying inline task definitions from addresses that have no business talking to the platform.
Conductor is the kind of middleware that quietly holds the keys to everything around it. It calls internal APIs, kicks off batch jobs and increasingly runs AI pipelines, which is why an authentication-free code execution bug in an orchestration platform is worth more to an attacker than the headline severity score alone suggests.
Our opinion
A 9.8 flaw with a public fix is not, on its own, much of a story – and Orkes will not lose many customers over this, because the patch has been sitting there since the end of June. What is worth saying out loud is what the gap between fix and fire says about how workflow engines get treated in practice. Conductor lives in the plumbing, nobody's on-call rota has a line item called “workflow platform”, and yet it is the one component trusted to call every other one. A flaw that lets a stranger run commands as the orchestration process, with no password required, is not a nice-to-have on a sprint board. Anyone still running 3.21.x through 3.30.1 should be treating this weekend as the deadline, not the next maintenance window.