A Control-M/Server communication command does not sufficiently filter or sanitize user-supplied input

Control-M/Server is BMC's enterprise workload-automation brain — the scheduler that dispatches batch jobs, file transfers, ETL pipelines, and database maintenance to Control-M/Agent processes running across thousands of managed hosts. A communication command in the server-side listener fails to sanitize attacker-supplied input, letting an unauthenticated network attacker inject unauthorized commands that execute in the context of the Control-M/Server process itself. Per BMC, affected builds are 9.0.20.x through 9.0.21.200 inclusive, plus older unsupported branches; the fix is expected in the next 9.0.21 rollup.

Vendor severity of CRITICAL / 9.0 is fair — arguably conservative. CVSS AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H captures the ingredients, but the AC:H (some race/config precondition) is the only thing that shaved this off a 9.8. Reality is that Control-M/Server is the *definition* of a high-value-role component: successful RCE on the server yields arbitrary command execution on every agent-managed host it schedules against, plus the service accounts, DB creds, and file-transfer material stored on the scheduler. This is a fleet-pivot bug, not a single-host bug.

Why this verdict

• Role multiplier (decisive): Control-M/Server occupies the fleet-orchestration high-value role by *definition* — ~100% of installs sit in this role. RCE on the scheduler yields command execution on every agent host it manages, plus the credential/vault material used to run jobs. This is the same class of blast radius as compromising a Jenkins controller, an SCCM primary, or a Rundeck server. That alone floors the verdict at CRITICAL.
• Unauthenticated, network-reachable, no user interaction: AV:N/PR:N/UI:N. Any attacker with L3 reachability to the CTM listener can attempt exploitation.
• Friction adjustment (does NOT break the floor): The scheduler is internal-only in ~99% of deployments, so the attacker must already have a foothold on the corporate network — this narrows attacker population but does not reduce blast radius. Per the noisgate role-multiplier rule this can pull the verdict ABOVE the floor but not BELOW it; here it holds at CRITICAL rather than pushing beyond.
• AC:H precondition: Non-trivial timing/state requirement will slow public PoC development by 2-6 weeks. This trims the score from 9.8 → 9.2 but does not change the bucket.
• No KEV / no PoC yet: Justifies not weighting this as an active-exploitation emergency, but for a scheduler that owns the batch plane of a Fortune-500, the pre-PoC window IS the patch window.

Why not higher?

No public PoC, no active exploitation, and AC:H reflects a real precondition attackers must satisfy. The listener is not internet-exposed in any meaningful population, so the immediate 'ransomware group scanning tomorrow' scenario doesn't fit — that's what separates a 9.2 from a 9.8 emergency like a public-facing edge-appliance RCE.

Why not lower?

Downgrading past CRITICAL would require evidence that Control-M/Server is NOT a fleet-orchestration component — it is, by design. Every credible deployment ends the chain at fleet command execution and credential loot. 'Requires internal access' is not sufficient friction to break the floor for a scheduler; the role multiplier rule explicitly overrides friction-only downgrades here.

1. ACL the CTM listener to known agent hosts only — On the Control-M/Server host, restrict inbound 7005/tcp (and any configured server ports) to the known agent CIDR list via host firewall (Windows Firewall inbound rules, nftables/iptables on Linux) plus upstream VLAN ACLs. Deploy within 3 days per the noisgate CRITICAL mitigation SLA. This blocks the pre-auth reachability step for any attacker who isn't already on an agent-registered host.
2. Deploy vendor hotfix / rollup 9.0.21.201 — Apply BMC's fix build across every Control-M/Server node — active-active pairs, DR replicas, and staging must all be patched together to prevent asymmetric exposure. Target completion within 90 days per the noisgate CRITICAL remediation SLA; realistically most shops can do this inside 2 weeks given Control-M's patch tooling.
3. Rotate Control-M service-account and vaulted-job credentials — Assume any credential referenced by a job definition or stored in the Control-M vault is compromised until proven otherwise. Rotate DB, SFTP, cloud-API, and mainframe credentials referenced from job plans; force re-enrollment of agent trust if you have any indication the scheduler was reachable from an untrusted segment.
4. Turn on job-plan change auditing and alert on out-of-window creation — Enable Control-M audit logging, forward to SIEM, and alarm on job definitions created or modified outside your change window or by accounts other than approved schedulers. This is the primary detection for step 4 (weaponized job push) if steps 1-3 succeed anyway.
5. Segregate the scheduler host from user-desktop VLANs — If Control-M/Server currently sits in a general-server VLAN reachable from the desktop plane, move it into an isolated batch-management VLAN with jump-host-only admin access. This raises the cost of the 'insider or malware-on-workstation' reachability path.

Run this on each Windows Control-M/Server host as a local administrator (Linux operators can adapt using ctm_menu + rpm -q/dpkg -l). Example invocation from an elevated PowerShell prompt: .\Check-CVE-2026-10539.ps1 -CtmHome 'C:\ProgramData\BMC Software\Control-M Server'. Reports VULNERABLE, PATCHED, or UNKNOWN.

#requires -Version 5.1
<#
  Check-CVE-2026-10539.ps1
  Detects Control-M/Server builds in the vulnerable range 9.0.20.x .. 9.0.21.200.
  Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
#>
param(
    [string]$CtmHome = $env:CONTROLM_SERVER_HOME
)

function Get-CtmServerVersion {
    param([string]$Home)
    # 1) Preferred: ctm_menu / ctmgetcm output
    $ctmgetcm = Join-Path $Home 'exe\ctmgetcm.exe'
    if (Test-Path $ctmgetcm) {
        try {
            $out = & $ctmgetcm '-version' 2>$null
            if ($out -match '(\d+\.\d+\.\d+\.\d+)') { return $Matches[1] }
        } catch {}
    }
    # 2) Fallback: file version on the main server binary
    $bin = Join-Path $Home 'exe\ctmsys.exe'
    if (Test-Path $bin) {
        return (Get-Item $bin).VersionInfo.FileVersion
    }
    # 3) Registry fallback
    $reg = 'HKLM:\SOFTWARE\BMC Software\Control-M/Server'
    if (Test-Path $reg) {
        $v = (Get-ItemProperty $reg -ErrorAction SilentlyContinue).Version
        if ($v) { return $v }
    }
    return $null
}

function Compare-Version {
    param([string]$V)
    # Vulnerable: 9.0.20.0 <= V <= 9.0.21.200
    $parts = $V.Split('.') | ForEach-Object { [int]$_ }
    if ($parts.Count -lt 4) { return 'UNKNOWN' }
    $vObj  = [Version]::new($parts[0],$parts[1],$parts[2],$parts[3])
    $low   = [Version]'9.0.20.0'
    $high  = [Version]'9.0.21.200'
    $fixed = [Version]'9.0.21.201'
    if ($vObj -ge $fixed) { return 'PATCHED' }
    if ($vObj -ge $low -and $vObj -le $high) { return 'VULNERABLE' }
    if ($vObj -lt $low) { return 'VULNERABLE'  } # unsupported older branches per BMC advisory
    return 'UNKNOWN'
}

if (-not $CtmHome -or -not (Test-Path $CtmHome)) {
    Write-Output 'UNKNOWN: Control-M/Server home not found. Pass -CtmHome explicitly.'
    exit 2
}

$ver = Get-CtmServerVersion -Home $CtmHome
if (-not $ver) {
    Write-Output 'UNKNOWN: could not determine Control-M/Server version.'
    exit 2
}

$state = Compare-Version -V $ver
Write-Output ("{0}: Control-M/Server version {1}" -f $state, $ver)
switch ($state) {
    'PATCHED'    { exit 0 }
    'VULNERABLE' { exit 1 }
    default      { exit 2 }
}

Sources

1. BMC Control-M security announcements (docs.bmc.com)
2. BMC Community – Control-M CVE guidance
3. CVE Details – BMC Control-M vulnerability history
4. CWE-305: Authentication Bypass by Primary Weakness
5. CISA KEV Catalog
6. FIRST EPSS scoring
7. NVD CVE search
8. OpenCVE – BMC vendor page