Orkes Conductor's "Discovery Gap" Left a Critical RCE Unpatched for Months

On August 21, 2026, Empirical Security detected the first in-the-wild attacks against Orkes Conductor, an open-source workflow engine with over 32,000 GitHub stars and more than 3,000 enterprise customers. The surprise: the patch, version 3.30.2, had been available since June 3. No advisory, no CVE reference, no security label in the release notes. The result was a nearly three-month exposure window where the fix technically existed but operationally did not.

How the Attack Works: From Workflow Registration to Execution

The attack unfolds in two unauthenticated POST requests. The first targets /api/metadata/workflow to register a workflow containing a malicious INLINE task. The second calls /api/workflow/<name> to execute it. The vulnerability lies in how Conductor handles embedded scripts.

According to Empirical Security, as quoted by SecurityWeek, "An INLINE task (and LAMBDA, DO_WHILE, and SWITCH tasks) evaluates a user-supplied JavaScript or Python expression, and Conductor builds that evaluator on a GraalVM context configured with HostAccess.ALL." This configuration disables the GraalVM sandbox and allows guest code to access any Java class on the classpath via reflection, including java.lang.Runtime. From there, OS command execution is direct.

The Conductor process, in the default container image, often runs with root privileges. This escalates the impact from remote code execution to full host compromise. The combination of absent authentication by default and unsandboxed script evaluators makes exploitation fully automatable and scalable.

The Timeline of Silence: Patch Without Advisory, Exploitation Without Warning

The chronology reveals a recurring pattern in infrastructure software. On June 3, 2026, the development team released version 3.30.2 with a change described in the release notes as "restricting GraalVM JavaScript further." No mention of security, no CVE referenced. On June 30, CVE-2026-58138 was formally published. In early August, proof-of-concept code went public. Only then did the vulnerability become "discoverable" for most organizations.

Empirical Security framed the problem clearly: "patching only helps the instances you can find." The lack of a structured advisory prevented vulnerability management programs from flagging the update as a priority. No scanner plugin — neither Tenable nor Qualys, according to the same source — flagged the vulnerable version in time. The workflow engine, by nature load-bearing but not security-critical in enterprise inventories, vanished from the perimeter of attention.

"No login stands in the way, because the open-source server enforces no authentication by default and leaves its workflow API open. A single unauthenticated POST registers a workflow with a hostile INLINE task and starts it" — Empirical Security

From Fortinet Data to Campaign Confirmation

Network telemetry turned hypothesis into evidence. Fortinet documented approximately 1,300 exploitation attempts concentrated between September 8 and 9, 2026, followed by an outbreak alert in the current week. Empirical Security researchers had already observed attacks from August 21, a week ahead of the peak detected by firewalls.

The data converges on a single conclusion: attackers did not exploit the vulnerability when it became patchable, but when it became publicizable. The PoC acted as a discovery trigger, not the CVE. This delay between technical availability and operational awareness is what Empirical Security defines as "the discovery gap in practice": a phenomenon where instrumental visibility fails on components that fall outside traditional security radars.

Immediate Actions

• Identify all Conductor instances across the infrastructure, including containerized deployments and uncataloged development environments, focusing on versions between 3.21.21 and 3.30.1
• Prioritize updating to version 3.30.2, the only release with a complete fix: the previous 3.30.0 and 3.30.1 only partially limit the attack surface with incomplete blocklists
• Enable authentication on the workflow API where absent, given that the open-source server does not enforce it by default and the workflow registration endpoint remains exposed
• Monitor logs for POST requests to /api/metadata/workflow followed by executions of workflows with INLINE, LAMBDA, DO_WHILE, or SWITCH task types from unauthorized sources

Why CVE-2026-58138 Is a Systemic Signal

Orkes Conductor is not a niche product. It is used by LinkedIn, Twilio, and Quest Diagnostics, among the more than 3,000 enterprises cited by the vendor. Its invisibility in the security perimeter does not stem from limited adoption, but from miscategorization: a workflow engine is infrastructure, not an application, and as such tends to escape traditional patch management cycles.

The lesson of CVE-2026-58138 extends beyond a single product. When a corrective patch is released without an advisory, the defensive community's intelligence system breaks. Scanners do not detect, asset management does not update, SOCs do not correlate. Exploitation becomes almost inevitable not for lack of technical defenses, but for lack of human alert. In this specific case, the fix existed. Only the knowledge of its existence was missing.

Sources

• https://www.securityweek.com/critical-orkes-conductor-vulnerability-exploited-in-attacks/
• https://www.sherlockforensics.com/blog/2026-06-30-cve-2026-58138.html
• https://exploit-intel.com/vuln/CVE-2026-58138
• https://www.thehackerwire.com/vulnerability/CVE-2026-58138/
• https://cyberstrike.io/cve/CVE-2026-58138/
• https://nvd.nist.gov/vuln/detail/cve-2026-58138
• https://www.cve.org/CVERecord?id=CVE-2025-26074
• https://research.empiricalsecurity.com/research/september-2026-cve-of-the-month
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Information verified against cited sources and current as of publication.

Sources