OS Command Injection Remote Code Execution Vulnerability in API in Progress ADC Products

The user-provided record for CVE-2026-8037 does not line up with primary-source advisories. The official match is CVE-2026-3517, published on 2026-04-20, covering an OS command injection flaw in the Progress ADC API where an authenticated user with Geo Administration permissions can inject commands through the addcountry path on LoadMaster. Officially affected ranges are LoadMaster 7.1.32.0 before 7.2.63.0 in the CNA record, with NVD-enriched fixed branches showing LoadMaster GA < 7.2.63.1 and LoadMaster LTSF < 7.2.54.17; ECS Connection Manager, Object Scale Connection Manager, and MOVEit WAF are also affected in their respective pre-7.2.63.1 ranges.

Reality is much less dramatic than the user-supplied CRITICAL 9.6 / PR:N framing. Primary sources describe this as authenticated, high-privilege, admin-plane abuse, and Progress documents that the REST API is disabled by default. That combination turns this from 'internet-scale initial access' into 'post-compromise or admin-credential abuse on a management surface', which is why this gets downgraded hard despite the eventual RCE impact.

Why this verdict

• Start from the official baseline, not the social-media one: the primary-source match is vendor/NVD HIGH 8.4/7.2, not the user-supplied CRITICAL 9.6 PR:N.
• PR:H is real downward pressure: exploitation requires a valid authenticated account with Geo Administration permissions, which implies the attacker is already past initial access or abusing privileged credentials/API keys.
• Admin-plane reachability is another hard gate: this is not the normal application data plane; it targets the management surface of an ADC appliance.
• API disabled by default matters: Progress explicitly says the REST API is disabled by default, so a meaningful slice of deployments never expose the vulnerable path at all.
• No KEV / no confirmed exploitation: absent active exploitation evidence, there is no reason to keep an authenticated management-plane bug in the top bucket solely because the post-exploitation impact is high.

Why not higher?

If this were unauthenticated, broadly internet-reachable, or confirmed under active exploitation, it would jump buckets fast because command execution on an ADC is strategically ugly. But the real chain requires adjacent/internal access, an enabled management/API surface, and a privileged authenticated role, which compounds downward friction at every step.

Why not lower?

Once those prerequisites are met, the impact is still arbitrary command execution on a central application delivery appliance. That is too much blast radius per successful compromise to dismiss as LOW, especially in environments where ADCs terminate TLS, hold certificates, and sit on privileged network paths.

1. Restrict management-plane reachability — Move Admin WUI/API access onto a dedicated management interface or tightly limited management network, and remove any unnecessary internet or broad internal exposure. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is worth doing now because it collapses step 1 of the attack chain.
2. Disable the REST API if unused — Progress states the API is disabled by default; keep it that way unless you have an explicit automation dependency. For this MEDIUM case there is no mitigation SLA — go straight to the 365-day remediation window, but eliminating the vulnerable surface is cleaner than hoping role controls hold forever.
3. Tighten privileged roles and rotate API keys — Review who actually has Geo Administration or equivalent high-impact rights, remove stale access, and rotate API keys tied to admin automation. There is no mitigation SLA — go straight to the 365-day remediation window, but reducing credential sprawl directly attacks the most important prerequisite in this exploit chain.
4. Alert on admin/API activity — Log and monitor admin logins, API calls, config changes, and unusual management-plane source IPs. There is no mitigation SLA — go straight to the 365-day remediation window, yet visibility is still the best way to catch the preconditions this bug depends on.

Run this on the Progress appliance itself over SSH or console as an admin-capable shell user. Invoke it with bash check_cve_2026_3517.sh; no internet access is needed, but you may need elevated rights to read version files and appliance metadata. This script is geared to LoadMaster builds and returns VULNERABLE, PATCHED, or UNKNOWN based on detected LMOS version.

#!/usr/bin/env bash
# check_cve_2026_3517.sh
# Purpose: Best-effort local version check for the Progress LoadMaster fix for CVE-2026-3517.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

ver=""
source_hint=""

trim() {
  echo "$1" | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'
}

extract_ver() {
  echo "$1" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' | head -n1
}

# Try common files first
for f in \
  /etc/version \
  /etc/loadmaster-version \
  /etc/loadmaster_version \
  /etc/loadmaster-release \
  /etc/lmos-release \
  /etc/issue
 do
  if [ -r "$f" ]; then
    cand=$(extract_ver "$(cat "$f" 2>/dev/null)")
    if [ -n "$cand" ]; then
      ver="$cand"
      source_hint="$f"
      break
    fi
  fi
done

# Try likely commands if file-based lookup failed
if [ -z "$ver" ]; then
  for cmd in \
    "bal version" \
    "bal -v" \
    "lmversion" \
    "lmver" \
    "hostnamectl"; do
    cand=$(sh -c "$cmd" 2>/dev/null | head -n 20)
    cand_ver=$(extract_ver "$cand")
    if [ -n "$cand_ver" ]; then
      ver="$cand_ver"
      source_hint="$cmd"
      break
    fi
  done
fi

if [ -z "$ver" ]; then
  echo "UNKNOWN - could not determine LMOS version from common files or commands"
  exit 2
fi

# Version compare helpers using sort -V
ver_lt() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

ver_ge() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

# Branch logic for LoadMaster based on Progress/NVD fixed builds:
#   GA fixed in 7.2.63.1
#   LTSF fixed in 7.2.54.17
# NVD also shows older GA ranges vulnerable below 7.2.63.1.

case "$ver" in
  7.2.54.*)
    if ver_ge "$ver" "7.2.54.17"; then
      echo "PATCHED - detected LoadMaster LTSF $ver from $source_hint"
      exit 0
    else
      echo "VULNERABLE - detected LoadMaster LTSF $ver from $source_hint (fixed in 7.2.54.17+)"
      exit 1
    fi
    ;;
  7.2.63.*)
    if ver_ge "$ver" "7.2.63.1"; then
      echo "PATCHED - detected LoadMaster GA $ver from $source_hint"
      exit 0
    else
      echo "VULNERABLE - detected LoadMaster GA $ver from $source_hint (fixed in 7.2.63.1+)"
      exit 1
    fi
    ;;
  7.2.*|7.1.*)
    if ver_lt "$ver" "7.2.63.1"; then
      echo "VULNERABLE - detected pre-fix LoadMaster-family version $ver from $source_hint"
      exit 1
    else
      echo "PATCHED - detected LoadMaster-family version $ver from $source_hint"
      exit 0
    fi
    ;;
  *)
    echo "UNKNOWN - detected version $ver from $source_hint, but branch is not recognized as a supported LoadMaster fix branch"
    exit 2
    ;;
esac

Sources

1. NVD CVE-2026-3517
2. CVE Record CVE-2026-3517
3. Progress LoadMaster 7.2.63.1 Security Updates
4. Progress RESTful API Interface
5. Progress LoadMaster APIv2 Documentation
6. Progress Administrator Access
7. Progress Release History
8. CISA KEV Catalog
9. ZDI-26-319