A critical, unauthenticated remote-code-execution flaw in Orkes Conductor — the open-source workflow orchestration engine used to sequence microservice calls, ETL jobs, and background pipelines — was quietly fixed in June 2026, formally assigned CVE-2026-58138 on June 30, and is now, as of early-to-mid September 2026, seeing a sharp rise in real-world exploitation attempts. The bug lets an attacker with no credentials send a single crafted HTTP request to a Conductor server's workflow API and get arbitrary OS command execution as the Conductor process — which, in OpenTaint's testing of the official container image, runs as root. Fortinet reported blocking roughly 7,000 exploitation attempts against this flaw between September 2 and 9, including 1,290 in a single 24-hour period (a 132% day-over-day increase). Honeypot operator Previdian logged a handful of attempts going back to July 24, and Empirical Security's telemetry recorded in-the-wild exploitation on August 21.
What the bug actually is
Conductor lets a client submit a complete workflow definition and start it in the same API call. Some task types in that definition — INLINE, LAMBDA, DO_WHILE, and SWITCH — can embed a JavaScript or Python expression that Conductor evaluates as part of running the workflow. According to a technical writeup from the vulnerability research group OpenTaint, those expressions were evaluated inside a GraalVM context configured with HostAccess.ALL (or the equivalent allowAllAccess(true)), which gives the script full access to the host JVM rather than sandboxing it. A script submitted through the workflow API — which is unauthenticated by default in a stock Conductor deployment — can therefore use Java reflection to reach Runtime.exec() or equivalent and run arbitrary shell commands on the server.
This isn't a first-time mistake in this codebase. Conductor had already fixed a related inline-script RCE once before, tracked as CVE-2025-26074, which involved the older Nashorn JavaScript engine. When the project migrated its scripting backend from Nashorn to GraalVM, the sandboxing wasn't carried over, and the same class of trust-boundary failure reopened on the new engine.
Why it's spreading now, months after the fix
The timeline is the part worth paying attention to. Orkes shipped the fix in Conductor 3.30.2 on June 3, 2026 — but according to Empirical Security's research, the release notes described it only as restricting GraalVM JavaScript further, with no security label and no CVE attached, so the fix looked like a routine bug patch rather than a "stop what you're doing and upgrade" advisory. (Empirical also notes that the 3.30.0 and 3.30.1 releases contained only partial fixes, so pinning to "3.30.x" isn't sufficient — the safe floor is 3.30.2.) The CVE itself wasn't published until June 30, nearly a month later. A public proof-of-concept went out in early August. Previdian's honeypots had already seen three attempts from July 24 onward, Empirical identified in-the-wild attacks on August 21, and by early September Fortinet was seeing attempts sourced mainly from Germany, Hong Kong, Indonesia, the UAE, and India.
Compounding the slow-burn disclosure, Empirical Security says there is no credentialed Tenable or Qualys plugin for this CVE as of publication, meaning a clean authenticated vulnerability scan tells you nothing about whether you're exposed. Conductor also rarely shows up cleanly in asset inventories under its own name — it's frequently bundled inside a larger platform or internal tooling layer, so security teams doing a routine "are we running X" grep across their CMDB can miss it entirely. That combination — a silent patch, a scanner blind spot, and an easily-missed dependency name — is why exploitation is still accelerating three months after a fix existed.
Scale and who's affected
This is not a niche tool. Conductor was originally built at Netflix and open-sourced before being commercially maintained by Orkes; it's used as a durable workflow/orchestration layer comparable to Temporal or Camunda, frequently sitting behind internal admin consoles, data pipelines, or CI/CD automation rather than being exposed as a customer-facing product. That's part of what makes a pre-auth RCE in it dangerous: instances are often reachable from internal networks or, in worse cases, directly from the internet with no additional authentication layer in front of them, because teams assumed the internal network boundary was protection enough.
SecurityWeek reported on September 18 that Fortinet had issued an outbreak alert for ongoing exploitation. It isn't an isolated case: on September 12, CISA added five actively exploited flaws in JFrog Artifactory, ConnectWise ScreenConnect, and MikroTik RouterOS to its Known Exploited Vulnerabilities catalog — several of them reachable without authentication — a reminder that September 2026 saw multiple infrastructure and DevOps tools get weaponized in quick succession, not just this one.
What this changes
If your organization runs Orkes Conductor or conductor-oss anywhere — including as an embedded dependency inside another internal tool — the concrete actions are:
1. Check your version now. Versions from 3.21.21 up to (but not including) 3.30.2 are affected; 3.30.0 and 3.30.1 are only partially fixed. Confirm the actual running version, not just what's pinned in a manifest that may be stale.
2. Don't rely on your vulnerability scanner to tell you. Per Empirical Security, there was no credentialed plugin for this CVE at publication time. Absence of a finding is not absence of exposure — check manually.
3. Put authentication in front of the workflow API regardless of patch status. Conductor's workflow-submission endpoint being unauthenticated by default is the underlying design issue; a reverse proxy requiring auth is a reasonable compensating control if you can't patch immediately, and is worth keeping even after patching, since it removes an entire class of future "unauthenticated API" bugs.
4. Re-audit any place you evaluate user-controlled scripts inside a JVM sandbox. The recurrence of this bug class across two different script engines (Nashorn, then GraalJS/GraalPy) in the same product is a useful case study: migrating a scripting backend without re-verifying the sandbox configuration is a repeatable failure mode, not a one-off mistake, and it's worth checking for the same pattern in any internal tooling that embeds GraalVM, V8, or similar embedded interpreters.
If you don't run Conductor, the narrower lesson still applies: a patch without a security advisory label is easy to deprioritize, and "we run a scanner" is not the same claim as "we know our exposure." Both gaps are process problems, not tooling problems, and they're cheap to close before the next silently-labeled fix.
Wise Hustlers builds and hardens backend infrastructure, including workflow and orchestration layers, as part of our engineering work — see our cybersecurity services if that's something you need help auditing.
Sources
- Critical Pre-Auth RCE in Orkes Conductor Workflow Platform Exploited in the Wild — The Hacker News
- September 2026 CVE of the Month: The 9.8 Nobody Knows They Are Running (CVE-2026-58138) — Empirical Security
- From Workflow Definition to Shell: Finding CVE-2026-58138 in Conductor — OpenTaint
- Critical Orkes Conductor Vulnerability Exploited in Attacks — SecurityWeek
- CVE-2026-58138 — Vulnerability Details, OpenCVE
- CVE-2026-58138: Orkes Conductor RCE Actively Exploited — SOCRadar
- CISA Adds 5 Actively Exploited Artifactory, ScreenConnect, and RouterOS Flaws to KEV — The Hacker News