CRITICAL: Orkes Conductor CVE-2026-58138 Exploited for Pre-Auth RCE

Orkes Conductor was built to run other people's logic. That is not a design flaw, that is the entire product. You hand it a workflow definition, it executes the steps in order, and if a step needs a little glue logic along the way you can drop a JavaScript or Python expression directly into the definition and Conductor will happily evaluate it for you. Enormously convenient for platform teams. Also, as it turns out, enormously convenient for whoever worked out that the workflow API would accept a definition from someone who never bothered to log in.

That is CVE-2026-58138, and attackers have been using it in the wild since at least the middle of the summer. Fortinet blocked somewhere around 7,000 exploitation attempts against customer deployments in a single week earlier this month. If you have Conductor running anywhere that has a route in from the internet, this is a drop everything and patch it now situation, and it has been for a while whether you noticed or not.

What the bug actually is

The vulnerability carries a CVSS v3.1 base score of 9.8 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and a CVSS v4 score of 9.3. Translated out of scoring notation, that reads as network reachable, low complexity, no privileges required, no user interaction needed, and total loss of confidentiality, integrity, and availability. There is no meaningful hurdle between an attacker and code execution. NVD classifies it as CWE-94, code injection, which is the polite taxonomic way of saying the application ran a string somebody else wrote.

Affected builds are Orkes Conductor 3.21.21 up to but not including 3.30.2. The fix landed in 3.30.2, and the upstream conductor-oss project shipped it alongside a pair of commits that tighten the evaluator configuration. The CVE was published on June 30, 2026, with the disclosure coming through VulnCheck. Worth noting that the NVD record currently sits in Deferred status, which means the usual enrichment pipeline has not fully caught up with it. Do not read that as a sign the issue has gone stale, because the attack telemetry says otherwise in fairly loud terms.

The mechanics are straightforward enough to explain over coffee. Conductor evaluates inline expressions using GraalVM, and that evaluator can be built with either a sandbox or effectively no sandbox at all. When it is configured with HostAccess.ALL or allowAllAccess(true), the scripting engine is not fenced off from the host JVM in any useful way. An expression is then free to reach back into Java reflection or simply call out to a subprocess directly. The task types that accept these expressions are INLINE, LAMBDA, DO_WHILE, and SWITCH, and all four are perfectly ordinary things to find in a real workflow, which is exactly what makes this unpleasant. A malicious payload does not look structurally different from legitimate orchestration logic, so eyeballing your definitions is not going to save you.

The part that turns a bad bug into a critical one is the word unauthenticated. The workflow API endpoint accepts and processes an inline workflow definition before the authentication check that you probably assumed was gating it. An attacker needs no stolen token, no valid service account, and no foothold anywhere else in your environment. They need to be able to reach the port. Whatever the Conductor process runs as, that is the privilege level the attacker inherits, and in a depressing number of deployments that process has far more access to the surrounding infrastructure than anyone would sign off on if you made them sit and think about it for five minutes.

What exploitation looks like in the wild

The timeline here has a familiar shape. Previdian recorded three exploitation attempts against its honeypot infrastructure going back to July 24, 2026, originating from French and United States addresses, which is the quiet reconnaissance phase where a handful of people who read CVE feeds carefully start poking at things to see what answers. Empirical Security observed in the wild exploitation as recently as August 21. Then on August 9 a working exploit landed on Exploit-DB as EDB-52633, targeting Conductor v3.23.0, and the economics changed completely. Public proof of concept code takes a vulnerability out of the hands of people who can read a commit diff and hands it to everyone with a scanner and a grudge.

Fortinet's numbers show the result plainly. FortiGuard Labs blocked roughly 7,000 attempts between September 2 and September 9, with 1,290 of those concentrated into a single 24 hour stretch around September 9, a jump of about 132 percent day over day. Source traffic clustered around Germany, Hong Kong, Indonesia, the United Arab Emirates, and India, which tells you less about who is behind it than about where the cheap hosting is this quarter. FortiGuard issued a formal outbreak alert and pushed coverage in IPS signature database 36.267 across FortiGate, FortiADC, FortiNDR, FortiNDR Cloud, FortiProxy, and FortiSASE. If you run Fortinet gear and your signatures are current, you have some protection at the perimeter. That is not remotely the same thing as being patched.

One more detail is worth sitting with for a moment. CISA's SSVC assessment for this CVE marks automatable as yes and technical impact as total. Automatable means the reconnaissance, weaponization, delivery, and exploitation steps can all be scripted end to end with no human in the loop. That is the profile of a bug that ends up baked into a mass scanning botnet rather than saved for a targeted campaign, and mass scanning does not care whether you are a Fortune 500 or a forty person shop with one overworked platform engineer.

Who is actually exposed

Conductor started life at Netflix before moving out to the conductor-oss project and the commercial Orkes offering, and it has spread well beyond its original niche since then. It shows up orchestrating microservices, running data pipelines, coordinating payment and provisioning flows, and lately doing a great deal of work behind AI agent pipelines where somebody needed a durable way to chain a dozen model calls and tool invocations together without writing their own state machine. That last category is growing fast and tends to get built by teams optimizing for velocity rather than for a hardened deployment topology, which is not a criticism so much as an observation about deadlines.

Most Conductor installs are meant to be internal. That assumption is baked into a lot of these deployments, and it is precisely the assumption that the unsandboxed evaluator configuration quietly depends on to be safe. The problem is that meant to be internal and actually unreachable are two very different states, and the gap between them is where incidents live. A misconfigured ingress rule, a cloud load balancer somebody stood up for a demo and never tore down, a Kubernetes service typed as LoadBalancer when it should have been ClusterIP, a VPN split tunnel that routes more than anyone intended, any one of these turns an internal service into an internet facing one without a single ticket being filed about it. Ask your development teams whether they run Conductor and you may well get a blank look. Scan your own address ranges for it and you may get a very different answer.

What to do right now

Upgrade to Conductor 3.30.2 or later. That is the actual fix, and everything else here is a stopgap dressed up as a plan. If you are running anything in the 3.21.21 through 3.30.1 band you are in scope, and given that weaponized exploit code has been public since early August, any exposed instance should be treated as potentially already touched rather than merely at risk.

If you genuinely cannot patch this week, go look at how your evaluators are configured. Any Conductor deployment building its GraalVM context with HostAccess.ALL or allowAllAccess(true) is handing scripts the keys to the host, and pulling that back to a restricted host access policy removes the escape route even where the authentication bypass itself remains reachable. While you are in there, get the workflow API endpoint behind network controls that actually enforce something. Put it on an internal segment, front it with an authenticating reverse proxy, and drop inbound traffic from anywhere that has no business submitting workflows in the first place. Fortinet customers should confirm that IPS signature database 36.267 or later is deployed and set to block rather than sitting in monitor mode, a distinction that has ruined more than one incident review.

For detection, the highest value signal by a wide margin is process lineage. Your Conductor JVM has no legitimate reason to spawn sh, bash, curl, wget, or a Python interpreter as a child process, so an EDR rule watching child process creation under that JVM will catch successful exploitation with very few false positives and almost no tuning. Back that up by logging workflow definition submissions and alerting when inline task types arrive from source addresses outside your expected set, and by watching for unexpected outbound connections from the Conductor host, since the first thing most of these payloads do is reach out to pull down a second stage. If you find evidence of execution, treat it as a full host compromise and go looking hard at credentials, service tokens, and cloud instance metadata access from that box rather than just killing a process and calling it handled.

The MSP angle

This is a clean upsell for external attack surface discovery, because the honest answer to whether a client runs Conductor is usually that nobody at the leadership level knows, and a scan that surfaces unknown internet facing developer infrastructure sells itself far better than any deck about the concept ever will. Pair the remediation work with a managed detection offering built around the process lineage rules above, because the same EDR logic that catches this one catches every other server side code execution bug queued up behind it, and that is a recurring revenue conversation rather than a one time patching engagement.