CVE-2026-58138 is an unauthenticated remote-code-execution vulnerability affecting Conductor versions from 3.21.21 through 3.30.1, and current threat-intelligence reporting says attackers are exploiting it in the wild. The complete fixed release is Conductor 3.30.2. Administrators with a vulnerable deployment that is reachable by untrusted users should treat this as an urgent patch-and-investigate problem, not only a routine software update.
Direct answer: if your Conductor deployment is running 3.21.21 through 3.30.1 and the workflow API is reachable by an attacker, upgrade to 3.30.2 or later, restrict untrusted API access and review the host for suspicious workflow definitions or unexpected process execution. Active exploitation is documented, but exposure alone does not prove that a specific server was compromised.
What changed with CVE-2026-58138?
The vulnerability itself was disclosed earlier, but the information state has materially changed because current Fortinet and independent security-research telemetry now establish exploitation activity. That means administrators should no longer assess CVE-2026-58138 only as a theoretical critical flaw or a normal patch-cycle item.
Fortinet’s September 18 outbreak record marks the vulnerability as exploited and, at the time reviewed, does not list it as part of the CISA Known Exploited Vulnerabilities catalog. Independent research from Empirical Security also reports observing exploitation through its own sensor network. These are separate evidence points from the Conductor fix itself.
Which Conductor versions are affected?
The reviewed vulnerability record identifies Conductor 3.21.21 through 3.30.1 as affected. The complete fixed version is 3.30.2.
This version boundary matters because 3.30.0 and 3.30.1 introduced partial hardening, but the advisory and patch references identify 3.30.2 as the release containing the complete remediation for the affected evaluator paths. Administrators should not treat 3.30.0 or 3.30.1 as equivalent to the final fixed state.
Why can the flaw lead to remote command execution?
The issue is tied to Conductor’s handling of script-based workflow tasks through GraalVM evaluators. In affected builds, attacker-controlled workflow expressions can reach host functionality that should not be available to untrusted scripts.
The vulnerability is classified as unauthenticated because an attacker who can reach the vulnerable workflow API can submit a malicious workflow before authentication in the affected community-server configuration. Successful exploitation can execute operating-system commands with the privileges of the Conductor process.
That does not mean every Conductor installation is equally exposed. Network reachability, deployment architecture, authentication controls placed in front of the API and the exact software version materially change practical exposure.
Does active exploitation mean your Conductor server was compromised?
No. Active exploitation means attackers are using the vulnerability against real systems. It does not prove that every vulnerable or internet-reachable Conductor instance has been successfully compromised.
It also matters whether security products blocked an attempt, whether the vulnerable API was reachable, whether the application was running an affected build and whether the submitted workflow actually executed. TPS therefore treats vulnerable, exposed, targeted and compromised as different states.
What administrators should do now
1. Find Conductor deployments
Inventory production, development, test, cloud and forgotten self-hosted Conductor instances. Do not assume only the primary production cluster matters.
2. Verify the exact version
If the deployment is running 3.21.21 through 3.30.1, treat it as affected. Confirm the running build rather than relying only on an old deployment manifest.
3. Upgrade to 3.30.2 or later
Move affected installations to the complete fixed release or a newer supported release that includes the remediation.
4. Reduce workflow API exposure
Restrict the API to trusted networks and users. Where architecture permits, place strong authentication and access controls in front of the service.
5. Review past activity
For deployments that were vulnerable and reachable, review recently created or modified workflows and investigate suspicious script expressions or unexpected host-process execution.
6. Separate exposure from compromise
Do not declare an incident solely because a host ran a vulnerable version. Use logs, workflow history and host telemetry to determine whether exploitation actually occurred.
What should defenders review after patching?
Patching closes the known vulnerability path, but it cannot prove that an exposed host was never exploited before the update. For previously reachable vulnerable systems, defenders should review workflow definitions and task history for unusual script content, unexpected changes and execution patterns that do not match normal application activity.
Host telemetry is also important. Investigate unexpected child processes launched by the Conductor service, shells or command interpreters started by the application process, unusual outbound connections, unexpected credential access and changes to systems that Conductor workflows can reach.
The evidence reviewed does not provide a complete universal IOC list that can prove or disprove compromise by itself. Normal application behavior also varies by deployment, so incident review should use each organization’s known-good workflow and host baseline.
Is CVE-2026-58138 in CISA’s KEV catalog?
At the September 21 review point, Fortinet’s outbreak record showed CISA KEV: No. VulnCheck separately tracks the vulnerability in its own exploited-vulnerability intelligence, but VulnCheck KEV and the U.S. CISA Known Exploited Vulnerabilities catalog are different lists.
A later CISA KEV addition would be a material lifecycle change and should update this same article rather than create another URL.
What is confirmed and what remains unknown?
Confirmed: CVE-2026-58138 is an unauthenticated RCE affecting the documented Conductor version range; 3.30.2 contains the complete fix; current security-vendor and research telemetry reports exploitation activity.
Not established: how many organizations were successfully compromised, which victims may be affected, whether a single campaign or multiple actors are responsible, whether ransomware or an APT group is using the flaw, and whether every publicly reported exploit attempt resulted in command execution.
Fortinet’s reviewed alert specifically did not attribute exploitation to a ransomware group or APT group. TPS therefore does not assign an attacker identity or campaign motive without stronger evidence.
What happens next?
The most important next signals are any Orkes or Conductor security-advisory revision, a CISA KEV addition, new authoritative indicators of compromise, changes to the fixed-version guidance, or credible reporting that establishes campaign attribution or confirmed victim impact.
For administrators, however, those later developments are not prerequisites for action. A vulnerable and reachable deployment already has enough evidence behind it to justify urgent remediation and a retrospective compromise check.
Verification note
TPS reviewed the CVE/advisory record, Conductor 3.30.2 patch references, Fortinet’s September 18 exploitation alert and current independent security reporting. The vulnerability and fixed-version state are strongly documented; active exploitation is supported by threat-intelligence telemetry rather than a reviewed Orkes exploitation statement.
Limitations
- No reviewed source establishes that every affected Conductor deployment is internet exposed.
- No reviewed source establishes that every exploitation attempt was successful.
- Victim count and victim identities remain unknown.
- Attacker or campaign attribution remains unresolved.
- A complete authoritative IOC set was not available in the evidence reviewed.
- CISA KEV status can change after publication and should be rechecked during maintenance.