Workflow orchestration platforms are attractive targets because they sit close to business logic, integrations, credentials, queues, APIs, and automation paths. When one of those platforms exposes a remote code execution path, the issue is not just application security. It becomes a control-plane risk.

FortiGuard Labs is warning that attackers are actively targeting Orkes Conductor deployments vulnerable to CVE-2026-58138, a critical unauthenticated remote code execution vulnerability tied to GraalVM script evaluators. The flaw affects Orkes Conductor versions before 3.30.2. The Hacker News also reported active exploitation activity and pointed defenders to the same remediation path.

The short version: a vulnerable Conductor server can accept malicious workflow definitions containing JavaScript or Python expressions through workflow API paths before authentication. If the evaluator is configured with unrestricted host access, the attacker can escape the intended scripting environment and execute operating system commands with the privileges of the Conductor process.

What was reported

FortiGuard described active attack attempts against exposed Orkes Conductor servers. Its reporting said FortiGuard IPS blocked 1,290 attempts in a 24-hour period, a 132 percent increase in daily activity, and 6,696 attempts over seven days. Observed activity was highest from Germany, Hong Kong, Indonesia, the United Arab Emirates, and India.

Public exploit material is also available, including exploit code targeting Conductor v3.23.0. That matters because defenders should expect broader opportunistic scanning once a remotely exploitable unauthenticated flaw has both public technical detail and working exploit examples.

The fixed version is Conductor 3.30.2 or later. The release notes include additional restriction work around GraalJS, which aligns with the reported evaluator abuse path.

Why this matters

Conductor-style workflow systems are often wired into sensitive internal processes. They may trigger jobs, move data, call internal APIs, interact with cloud services, or carry service credentials. If an attacker can run commands from the workflow engine, the blast radius can extend well beyond the application itself.

For SMBs and government contractors, this is the kind of exposure that can hide in engineering or operations environments. A workflow server might be stood up for automation, integration testing, customer operations, AI pipeline orchestration, data processing, or DevOps glue work. If it is Internet-accessible or reachable from a broad internal network, it can become a pivot point.

The government-contractor angle is straightforward: automation platforms often touch proposal systems, ticketing systems, cloud workloads, security tooling, and customer-support workflows. Even when the platform does not directly store regulated data, it may have access paths into systems that do.

Defensive priorities

  • Patch first. Identify Orkes Conductor and Conductor OSS deployments and upgrade affected systems to 3.30.2 or later.
  • Remove Internet exposure. Do not expose workflow API endpoints directly to the public Internet. Place them behind VPN, private connectivity, identity-aware access, or other access controls.
  • Segment the workflow tier. Treat workflow engines like automation control planes. Limit where they can connect, which services they can call, and which credentials they can access.
  • Review authentication and API gateway rules. Confirm that workflow creation, execution, and evaluator-related endpoints require authentication and authorization before processing user-controlled content.
  • Hunt for suspicious workflow submissions. Look for unusual inline workflow definitions, unexpected JavaScript or Python expressions, command-execution patterns, outbound callbacks, and workflows created by unknown users or unauthenticated paths.
  • Monitor the Conductor process. Alert on shell spawning, unexpected child processes, scripting runtime abuse, filesystem staging, and outbound network connections from the Conductor service account.
  • Rotate exposed secrets. If exploitation is suspected, assume service credentials reachable from the Conductor host or process may be compromised.
  • Reduce evaluator privilege. Where scripting is required, avoid unrestricted host access and remove dangerous execution capabilities that are not explicitly needed.

Fast check for leadership

If your team uses Orkes Conductor, Netflix Conductor-derived tooling, or any workflow automation engine with scriptable tasks, ask three questions today:

  • Is the workflow API reachable from the Internet or from broad internal networks?
  • Can workflow definitions execute scripts or expressions that interact with the host?
  • What credentials, internal services, and data paths can the workflow process reach?

Those answers define the real risk. A patched vulnerability is important, but the long-term control is making sure automation platforms are not placed in flat networks with privileged credentials and broad outbound reach.

Bulwark Black assessment

CVE-2026-58138 is a useful reminder that automation engines are not ordinary web apps. They are designed to execute work. That makes evaluator bugs, unsafe scripting features, and unauthenticated workflow submission paths especially dangerous.

The durable fix is not only version management. Workflow systems should be treated like privileged infrastructure: private by default, segmented, monitored, least-privileged, and surrounded by strong identity controls. If a workflow platform can start jobs across your environment, then compromising it can look a lot like compromising an operator.

Source: The Hacker News — Critical Pre-Auth RCE in Orkes Conductor Workflow Platform Exploited in the Wild

Primary reference: FortiGuard Labs threat signal — Orkes Conductor evaluator remote code execution

Additional reference: FortiGuard Labs outbreak alert and Conductor 3.30.2 release notes