Orkes Conductor’s unauthenticated RCE is now exploited in the wild, three months after disclosure
On September 19, 2026, Fortinet confirmed active exploitation of CVE-2026-58138, an unauthenticated remote code execution flaw in Orkes Conductor that was published to the NVD on June 30. Upgrade to 3.30.2 and treat any exposed instance as compromised.
September 19, 2026. Fortinet confirms that CVE-2026-58138 is being actively exploited in the wild. June 30, 2026. The flaw had already been published to the NVD — nearly three months earlier. September 9, 2026. The vendor blocked 1,290 attempts in 24 hours. Why it matters: this is an unauthenticated remote code execution flaw, rated CVSS 9.8, inside a workflow orchestration engine — the class of tool that holds the keys to your automations, your integrations, and often your infrastructure.
The flaw: an unsandboxed GraalVM evaluator
Orkes Conductor is the commercial distribution of the orchestration engine inherited from Netflix Conductor. Its job is to run workflows — graphs of tasks that chain API calls, scripts, and decisions together. That very ability to execute code is where the problem lives.
CVE-2026-58138 affects versions 3.21.21 up to, but not including, 3.30.2. The NVD description is unambiguous: a remote attacker can submit inline workflow definitions carrying malicious JavaScript or Python expressions to the workflow API, before any authentication. Those expressions are evaluated by GraalVM evaluators configured without restrictions — HostAccess.ALL or allowAllAccess(true) — through four task types: INLINE, LAMBDA, DO_WHILE, and SWITCH.
The technical consequence is stark. Because the evaluator is not sandboxed, the attacker escapes the intended scripting environment and invokes arbitrary system commands, either through Java reflection or direct subprocess calls. All of it runs with the privileges of the Conductor process — often a service account holding broad rights over the very systems it orchestrates.
The score reflects that severity. The vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H describes the flaw an attacker dreams of: network reachable, low complexity, no privileges, no user interaction, and high impact on confidentiality, integrity, and availability. CWE-94 (code injection) confirms the nature of the bug. EPSS puts it at a 9.26% probability of exploitation, in the 95th percentile — the statistical reflection of a flaw already being targeted.
The technical detail that makes the flaw exploitable comes down to the configuration of GraalVM, the polyglot runtime that evaluates the JavaScript and Python expressions. Two settings open the door. HostAccess.ALL lets the script reach any class and method of the host Java virtual machine; allowAllAccess(true) disables host-access restrictions. With both in place, a single reflective call to java.lang.Runtime.getRuntime().exec(…) turns a workflow expression into a system command. The 3.30.2 fix therefore adds no extra firewall: it restores a safe configuration that should have been the default.
The exploitation: a spike, then a routine
The gap between disclosure (June 30) and mass exploitation (September) is no accident. Fortinet published an outbreak alert this week detailing what it is seeing. On September 9, 2026, it blocked 1,290 attempts in 24 hours, a 132% jump in daily activity. Between September 2 and 9, nearly 7,000 attempts were neutralized.
The origin data points to a distributed campaign: most attempts came from Germany, Hong Kong, Indonesia, the United Arab Emirates, and India. Telemetry from Previdian reports three attempts against its honeypots since July 24, 2026, from two unique IP addresses in France and the United States. Empirical Security says it detected in-the-wild exploitation as recently as August 21, 2026.
In other words, this is not a mere proof of concept. It is an opportunistic campaign scanning exposed Conductor instances and trying to inject booby-trapped workflow definitions, betting that some instance still runs a vulnerable version. The lag between disclosure and exploitation is the time it took attackers to write, test, and industrialize the exploit — while teams still had not patched.
Why workflow engines are a target
The significance of CVE-2026-58138 goes beyond the Orkes case. Orchestration engines occupy a special position inside a company: they hold credentials, API tokens, cloud keys, and execution rights over the systems they automate. Compromise the engine and you often inherit everything it is allowed to do — without having to attack each target one by one.
It is the same logic that makes CI/CD platforms, secrets managers, and configuration management tools such attractive targets. They are choke points: once inside, an attacker gains a legitimate relay to the rest of the estate. The Orkes flaw is all the more severe because it requires no authentication — no credential theft, no phishing, just an exposed API and a forged request.
The subtext is a recurring configuration mistake. The GraalVM sandbox exists, but it must be enabled and hardened. By default, or for convenience, deployments leave HostAccess.ALL open, which amounts to handing a shell to anyone who can reach the endpoint. The 3.30.2 fix does not merely patch a hole: it restores a separation that the default configuration should have guaranteed.
Three months of lag, two lessons
The gap between June 30 — disclosure — and September 19 — the exploitation alert — deserves scrutiny for what it says about patch management. CVE-2026-58138 was no secret: it sat in the NVD with a critical score, a trivial vector, and a CWE-94. A Conductor instance exposed in September should have been patched nearly three months earlier.
The first lesson is that visibility is not enough. A published flaw is only fixed if someone connects it to a real inventory of affected instances. Orchestration engines, often deployed outside the perimeter the security team monitors, slip past conventional infrastructure scanners. The second lesson is that attackers read the NVD as attentively as defenders do: the curve Fortinet describes — a 132% daily spike in September — is the fingerprint of an industrialised, distributed exploit ready to fire the moment a vulnerable instance appears.
What to do: patch, then investigate
The first action is mechanical: upgrade to Conductor 3.30.2 or later. That is the only version that fixes the flaw. Any deployment exposing the workflow API to the internet on an older version should be treated as potentially compromised — not merely vulnerable.
Detecting past exploitation is trickier, because the attack blends into legitimate workflow traffic. The signals to look for are unusual workflow submissions, the appearance of unexpected INLINE or LAMBDA task types, and any unexplained command execution from the Conductor process account:
# Find recent inline/lambda task submissions in Conductor logs
grep -iE 'INLINE|LAMBDA|DO_WHILE|SWITCH' /var/log/conductor/*.log | tail -50
# Cross-reference with processes spawned by the Conductor service account
ps -eo user,pid,cmd | grep -i conductorIf an immediate upgrade is impossible, Fortinet recommends restricting external access to the workflow API endpoints, placing instances behind network access controls, and monitoring for suspicious submissions. Those measures reduce the risk without eliminating it: the patch remains the only real boundary.
Verdict
CVE-2026-58138 is proof that the gap between an NVD publication and active exploitation is now measured in weeks, not years. If you run Orkes Conductor, upgrade to 3.30.2 immediately and assume any exposed instance has been visited — audit your workflows and service accounts before resuming normal operations. If your orchestration engine is not Conductor, apply the same lesson to your own tool: an unsandboxed script evaluator behind an exposed API is a shell waiting to happen, whatever the product.