Default credentials set for local privileged user in Virtual Appliance

CVE-2026-28713 is a default-credentials flaw affecting the VMware virtual appliance form factors of Acronis Cyber Protect Cloud Agent before build 36943 and Acronis Cyber Protect 17 before build 41186. In plain English: the appliance includes a local privileged account with vendor-set credentials, so anyone who can reach the relevant management/login surface and knows the credential pair can authenticate as a powerful local user.

The vendor's HIGH 7.1 score overstates enterprise urgency a bit. The impact is absolutely real because backup infrastructure is sensitive and privileged, but the exploit chain has meaningful friction: this is a VMware appliance deployment only, typically parked on an internal management network, and I found no KEV entry, no public exploitation evidence, and no public PoC in primary sources. That makes this a solid MEDIUM for most fleets, not because default credentials are harmless, but because the exposed population and attacker reach are much narrower than a generic internet-facing auth bypass.

Why this verdict

• Start from 7.1 HIGH: default credentials on a privileged backup appliance can absolutely lead to sensitive data access and operational sabotage.
• Downward pressure — VMware appliance only: this is not every Acronis endpoint or every agent; it is the virtual-appliance deployment path, which narrows affected population materially.
• Downward pressure — likely internal management plane: Acronis docs show setup via vSphere console and vCenter/ESXi connectivity, which usually means segmented admin networks rather than broad internet exposure.
• Downward pressure — attacker reach is the real gate: the exploit is easy *after* access to the appliance interface, but getting to that interface is the hard part in well-run environments.
• Downward pressure — no exploitation signal: no KEV listing, no public PoC found, and a very low EPSS all argue against emergency-tier prioritization.
• Upward pressure — backup infrastructure matters: if exploited, this can touch recovery operations, stored trust, and potentially the virtualization control plane, so this is not backlog fluff.

Why not higher?

This is not a mass-exploitable edge bug with broad anonymous reach. The chain depends on a narrower product slice, a management-plane path, and the default credentials still being present, which compounds friction. Absent active exploitation or wide internet exposure, CRITICAL/HIGH would over-prioritize it against more reachable flaws.

Why not lower?

A privileged default account on backup infrastructure is never a paperwork-only issue. If an attacker does reach the appliance, impact can include backup tampering, credential abuse, and follow-on movement into VMware-adjacent systems. That risk keeps it above LOW.

1. Inventory every Acronis VMware appliance — Find all Acronis Cyber Protect 17 and Cloud Agent for VMware virtual appliances in vCenter, CMDB, and backup administration records. Because this is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window unless you discover external exposure or suspicious logins.
2. Restrict management-plane reachability — Limit appliance access to backup admins and jump hosts only, using ACLs, firewall rules, and management VLAN segmentation. This directly attacks the biggest real-world friction point in the exploit chain; for a MEDIUM finding, deploy during normal network-hardening work if not already in place.
3. Rotate or disable local privileged defaults — If the appliance permits credential rotation or account disablement, remove any vendor-known local credentials immediately after validation. This is the most direct compensating control when patching will wait for the normal ≤365-day remediation window.
4. Review appliance trust scope — Check what vCenter/ESXi accounts, storage paths, and backup repositories the appliance can touch. Reducing those permissions limits blast radius even if the default account is abused.
5. Monitor for appliance-sourced admin activity — Alert on unusual logins from the appliance to vCenter/ESXi, backup repository changes, backup deletion attempts, and sudden policy edits. This does not prevent initial authentication, but it raises the chance of catching follow-on abuse.

Run this on the target Acronis VMware appliance or on a cloned shell session to it. Invoke it as sudo bash check_cve_2026_28713.sh cp17 or sudo bash check_cve_2026_28713.sh cloud-agent; it needs local shell access and enough privileges to inspect package metadata and Acronis install paths.

#!/usr/bin/env bash
# check_cve_2026_28713.sh
# Purpose: Best-effort local check for CVE-2026-28713 on Acronis VMware appliances.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN, 3 USAGE

set -u

PRODUCT="${1:-}"
if [[ -z "$PRODUCT" ]]; then
  echo "Usage: $0 <cp17|cloud-agent>"
  exit 3
fi

case "$PRODUCT" in
  cp17) THRESHOLD=41186 ;;
  cloud-agent) THRESHOLD=36943 ;;
  *) echo "Usage: $0 <cp17|cloud-agent>"; exit 3 ;;
esac

extract_build() {
  local out build

  # 1) Try package managers
  if command -v rpm >/dev/null 2>&1; then
    out=$(rpm -qa 2>/dev/null | grep -Ei 'acronis|backup|cyberprotect|cyber-protect' || true)
    build=$(echo "$out" | grep -Eo '[0-9]{5}' | sort -nr | head -n1 || true)
    if [[ -n "$build" ]]; then echo "$build"; return 0; fi
  fi

  if command -v dpkg-query >/dev/null 2>&1; then
    out=$(dpkg-query -W 2>/dev/null | grep -Ei 'acronis|backup|cyberprotect|cyber-protect' || true)
    build=$(echo "$out" | grep -Eo '[0-9]{5}' | sort -nr | head -n1 || true)
    if [[ -n "$build" ]]; then echo "$build"; return 0; fi
  fi

  # 2) Try Acronis command-line utility if present
  for cmd in \
    /usr/lib/Acronis/CommandLineTool/acrocmd \
    /usr/sbin/acrocmd \
    /usr/bin/acrocmd
  do
    if [[ -x "$cmd" ]]; then
      out=$($cmd --version 2>/dev/null || true)
      build=$(echo "$out" | grep -Eo '[0-9]{5}' | sort -nr | head -n1 || true)
      if [[ -n "$build" ]]; then echo "$build"; return 0; fi
    fi
  done

  # 3) Search common install paths for a 5-digit build marker
  out=$(find /opt/acronis /usr/lib/Acronis /etc 2>/dev/null \( -type f -o -type l \) | head -n 5000 | xargs -r strings 2>/dev/null | grep -Ei 'Acronis|Cyber Protect|build' || true)
  build=$(echo "$out" | grep -Eo '[0-9]{5}' | sort -nr | head -n1 || true)
  if [[ -n "$build" ]]; then echo "$build"; return 0; fi

  return 1
}

BUILD=$(extract_build || true)

if [[ -z "$BUILD" ]]; then
  echo "UNKNOWN - could not determine installed Acronis build locally; verify in Cyber Protect console Details view or package inventory"
  exit 2
fi

if [[ "$BUILD" =~ ^[0-9]+$ ]]; then
  if (( BUILD < THRESHOLD )); then
    echo "VULNERABLE - detected build $BUILD, threshold for $PRODUCT is $THRESHOLD"
    exit 1
  else
    echo "PATCHED - detected build $BUILD, threshold for $PRODUCT is $THRESHOLD"
    exit 0
  fi
fi

echo "UNKNOWN - extracted non-numeric build value: $BUILD"
exit 2

Sources

1. Acronis advisory SEC-4168
2. NVD entry for CVE-2026-28713
3. Acronis docs: Configuring Agent for VMware (Virtual Appliance)
4. Acronis docs: Updating virtual appliances
5. Acronis docs: Updating protection agents manually
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS data and statistics
8. Tenable CVE page with EPSS snapshot