A Single Unauthenticated POST Gets Root on Orkes Conductor. Fortinet Blocked 7,000 Attempts Trying It Last Week.
CVE-2026-58138 lets anyone reach Conductor's open workflow API and hand it a script that escapes its own sandbox. The fix shipped quietly in June — exploitation is still accelerating three months later.
Conductor is an open-source workflow engine — originally built at Netflix, now maintained by Orkes — that companies use to orchestrate microservices, and increasingly, AI agents. Its workflow API lets a caller define a job as a sequence of typed tasks: call this service, wait for that condition, branch on this result. Four of those task types can also run a short JavaScript or Python expression inline. That feature is the entire vulnerability. Conductor evaluates that script in an unsandboxed GraalVM context, and until version 3.30.2, nothing stood between the script and the operating system underneath it — not a permission check, not a login prompt, nothing.
How one POST becomes root
Orkes Conductor's open-source server ships with no authentication enabled by default — the workflow API is simply open to whoever can reach it. That alone would be a problem. Combined with the second flaw, it's a one-shot exploit: an attacker registers a malicious workflow definition containing an INLINE, LAMBDA, DO_WHILE, or SWITCH task, submits it as an unauthenticated POST, and starts it. Any one of those four task types will evaluate attacker-supplied JavaScript or Python — and Conductor built that evaluator on a GraalVM context configured with HostAccess.ALL (Java) or allowAllAccess(true) (Python), GraalVM's most permissive settings. From inside the script, an attacker can reach java.lang.Runtime through reflection and call Runtime.exec() or ProcessBuilder directly.
The fix shipped three weeks before the bug had a name
From silent patch to outbreak alert
- Conductor 3.30.2 releasedThe changelog described it only as restricting GraalVM JavaScript further — no security label, no CVE attached.
- CVE-2026-58138 publishedCVSS 9.8, four weeks after the fix that resolved it had already shipped.
- First honeypot probesPrevidian recorded three exploitation attempts from two IPs, in France and the U.S.
- Public exploit publishedExploit-DB entry EDB-52633 made a working exploit against Conductor 3.23.0 available to anyone.
- Broader in-the-wild exploitation confirmedEmpirical Security detected active exploitation attempts in its own telemetry.
- Fortinet logs the spikeRoughly 1,290 blocked attempts in a single 24-hour window — a 132% day-over-day increase.
- Fortinet outbreak alertNearly 7,000 blocked attempts recorded across September 2–9; attack traffic concentrated from Germany, Hong Kong, Indonesia, the UAE and India.
Patching to 3.30.2 isn't optional — and 3.30.0/3.30.1 don't count
| Version range | Status |
|---|---|
| 3.21.21 – 3.29.x | Vulnerable — original flaw, unrestricted GraalVM host access |
| 3.30.0 – 3.30.1 | Still vulnerable — patch attempt used only a partial blocklist |
| 3.30.2 and later | Fixed — Runtime, ProcessBuilder, Process, System and reflection primitives blocked; host class loading, native access, and file/environment access disabled inside the script context |
That middle row matters: teams that upgraded to 3.30.0 or 3.30.1 believing they'd addressed a GraalVM hardening item are still exposed. The complete fix — a real sandbox rather than a blocklist — only landed in 3.30.2.
This isn't just a microservices bug anymore
Conductor's own GitHub description no longer says "microservices orchestrator" — it describes an "event driven agentic workflow engine" for both applications and AI agents, and Orkes markets purpose-built features on top of it (Agentspan for durable agent runtimes, an MCP Gateway for exposing internal APIs as agent tools, prompt-to-workflow generation). The same INLINE/LAMBDA task types that make Conductor flexible for chaining LLM calls and tool invocations are exactly the ones this vulnerability abuses. An organization standing up an agentic pipeline on Conductor today is adopting the same unauthenticated-by-default posture that let this bug become exploitable in the first place.
What to do about it
- Upgrade to Conductor 3.30.2 or later — confirm the actual version, since 3.30.0/3.30.1 do not fix this.
- Enable authentication on the OSS server explicitly; it is disabled by default.
- Restrict network access to the workflow API to trusted internal callers only — do not expose it to the internet.
- If INLINE, LAMBDA, DO_WHILE or SWITCH tasks aren't in use, disable those task types at the server configuration level.
- Review logs on any internet-reachable instance still on a pre-3.30.2 build for suspicious workflow registrations or unexpected process execution.
CVSS/EPSS data as of 2026-09-22live record →