A critical vulnerability in Orkes Conductor is being actively exploited by attackers, potentially allowing them to execute arbitrary commands on vulnerable systems without authentication.
Tracked as CVE-2026-58138 and rated 9.8 on the CVSS scale, the flaw affects Conductor, an open-source enterprise framework used to orchestrate microservices, workflows and AI agents. The vulnerability can be exploited through inline workflow definitions submitted to the platform’s workflow API.
The security issue stems from the way Conductor executes scripts within workflows.
Attackers can insert malicious JavaScript or Python expressions into workflow definitions and use them to execute arbitrary system commands.
According to Empirical Security, INLINE tasks, along with LAMBDA, DO_WHILE and SWITCH tasks, can evaluate user-controlled JavaScript or Python expressions. Conductor creates the evaluator using a GraalVM context configured with HostAccess.ALL, effectively removing the intended sandbox protections.
The attacker-controlled code can then reach the underlying Java runtime and execute operating system commands with the privileges of the Conductor process.
In many deployments, that process runs with root privileges, potentially giving attackers extensive control over the affected system.
Authentication does not prevent exploitation by default because the open-source Conductor server does not enforce authentication and leaves its workflow API accessible. An attacker can reportedly send a single unauthenticated POST request to register a malicious workflow containing an INLINE task and trigger its execution.
Orkes patched CVE-2026-58138 in June with Conductor version 3.30.2.
However, attackers began targeting the vulnerability after proof-of-concept exploit code was publicly released in early August.
Empirical Security identified exploitation attempts in the wild on August 21. Fortinet subsequently blocked approximately 1,300 exploitation attempts between September 8 and September 9 and has issued an outbreak alert warning about continued exploitation.
Organizations running Conductor should upgrade to version 3.30.2 or later and limit external access to the platform’s workflow API endpoints.
Security teams should also place Conductor deployments behind firewalls and ensure vulnerable services are not directly exposed to the public internet.
Administrators should monitor Conductor instances for suspicious workflow submissions and unexpected command execution. Systems that previously ran vulnerable versions should also be reviewed for signs of unauthorized access or compromise.
Read the original article: