Local privilege escalation due to insecure Unix socket permissions

CVE-2026-28727 is a local privilege escalation in Acronis macOS products caused by overly permissive Unix socket permissions. The affected ranges called out by Acronis/NVD are Acronis Cyber Protect 17 (macOS) before build 41186, Acronis Cyber Protect Cloud Agent (macOS) before build 41124, and later-added Acronis True Image (macOS) before build 42902. In plain English: a low-privileged local user can talk to a privileged Acronis service over a socket that should have been locked down more tightly.

The vendor's 7.8/HIGH is technically fair in CVSS terms because successful exploitation can hand over root-equivalent impact on the box. Operationally, though, this is less urgent than the label implies: it requires existing local code execution plus a logged-in low-priv account, only affects macOS endpoints with specific Acronis builds, and the blast radius is one host at a time. With no KEV listing, no public exploitation evidence, and very low EPSS, this lands better as MEDIUM for enterprise patch scheduling.

Why this verdict

• Start from 7.8/HIGH, then subtract for attacker position: AV:L/PR:L means the attacker already has local execution and a user context. That is post-initial-access, not an entry-point bug.
• Subtract for reachable population: only macOS endpoints with specific Acronis products and vulnerable builds are in scope. That is a much smaller exposed set than a cross-platform or remotely reachable service flaw.
• Subtract for blast radius: exploitation yields privilege on one host, not unauthenticated domain-wide or internet-scale compromise. Even if impact on that host is severe, the chain does not naturally fan out.
• Keep it above LOW because the exploit path is simple once local: low complexity, no user interaction, and high CIA impact on the endpoint make this a meaningful post-exploitation amplifier.
• No external amplifier: no KEV, no public exploitation evidence, and extremely low EPSS mean there is no threat-intel reason to preserve the vendor HIGH.

Why not higher?

To justify HIGH here, you would want an amplifier like active exploitation, broad product prevalence, or a path from unauthenticated remote access to impact. None of those are present in the reviewed sources. This is a local macOS privesc requiring an existing foothold, which is exactly the kind of compounding friction that should drag the score down.

Why not lower?

This is still a real privilege escalation, not a cosmetic misconfiguration. Once an attacker has a user-level foothold, the path to root appears straightforward and can defeat the boundary between ordinary user compromise and full host compromise. On shared Macs, developer endpoints, or already-compromised hosts, that matters enough to stay above LOW.

1. Audit Acronis installs on macOS — Identify Macs running the affected products and build numbers, then prioritize the subset exposed to higher local-user risk such as shared workstations, lab Macs, and developer endpoints. For a MEDIUM verdict there is no mitigation SLA, so use this as scoping work before normal-cycle remediation.
2. Reduce local user exposure — Limit interactive logons to managed corporate users, remove stale local accounts, and avoid shared non-admin accounts on vulnerable Macs. This directly attacks the main prerequisite: a low-privileged local user context.
3. Watch Acronis parent-child behavior — Deploy or tune EDR analytics for unusual privileged process launches, file writes to protected locations, and permission changes originating from Acronis processes. Because the Unix socket interaction itself may be quiet, catching the post-escalation behavior is the practical control.
4. Harden socket/file permissions where validated — If your packaging and vendor support model allow it, validate ownership and mode bits on Acronis-created sockets and containing directories, and restore restrictive permissions through managed configuration. Treat this as a temporary guardrail, not a substitute for upgrading.
5. Segment admin rights on Macs — Use least privilege, admin elevation workflows, and strong monitoring around local privilege grants. This does not stop the vulnerable socket itself, but it reduces attacker payoff and improves detection around attempted privilege transitions.

Run this on the target macOS host from Terminal or through your RMM/MDM shell. Example: bash acronis_cve_2026_28727_check.sh; no root is required for standard app-bundle checks, though elevated rights may help if your Acronis install paths are unusually locked down.

#!/bin/bash
# CVE-2026-28727 verification for macOS Acronis products
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

found_any=0
unknown_any=0
vuln_any=0

# Compare two integer build numbers: returns 0 if $1 < $2
lt_build() {
  local a="$1" b="$2"
  [[ "$a" =~ ^[0-9]+$ ]] || return 1
  [[ "$b" =~ ^[0-9]+$ ]] || return 1
  (( a < b ))
}

# Read CFBundleVersion from an app bundle
get_bundle_build() {
  local app="$1"
  local plist="$app/Contents/Info.plist"
  local v=""

  if [[ -f "$plist" ]]; then
    v=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' "$plist" 2>/dev/null || true)
    if [[ -z "$v" ]]; then
      v=$(defaults read "$app/Contents/Info" CFBundleVersion 2>/dev/null || true)
    fi
  fi
  echo "$v"
}

check_product() {
  local label="$1"
  local pattern="$2"
  local fixed_build="$3"
  local paths=()
  local build=""
  local matched=0

  while IFS= read -r p; do
    paths+=("$p")
  done < <(find /Applications "$HOME/Applications" /Library/Application\ Support -maxdepth 4 \( -iname "$pattern" -o -iname "$pattern.app" \) 2>/dev/null | sort -u)

  for app in "${paths[@]}"; do
    matched=1
    found_any=1
    build=$(get_bundle_build "$app")

    if [[ -z "$build" ]]; then
      echo "UNKNOWN: $label found at $app but build could not be read"
      unknown_any=1
      continue
    fi

    if lt_build "$build" "$fixed_build"; then
      echo "VULNERABLE: $label at $app build $build < fixed build $fixed_build"
      vuln_any=1
    else
      echo "PATCHED: $label at $app build $build >= fixed build $fixed_build"
    fi
  done

  return 0
}

# Product checks based on vendor/NVD affected ranges
check_product "Acronis Cyber Protect 17 (macOS)" "*Cyber Protect*" "41186"
check_product "Acronis Cyber Protect Cloud Agent (macOS)" "*Cloud Agent*" "41124"
check_product "Acronis True Image (macOS)" "*True Image*" "42902"

if (( found_any == 0 )); then
  echo "UNKNOWN: No matching Acronis macOS product paths found"
  exit 2
fi

if (( vuln_any == 1 )); then
  echo "VULNERABLE"
  exit 1
fi

if (( unknown_any == 1 )); then
  echo "UNKNOWN"
  exit 2
fi

echo "PATCHED"
exit 0

Sources

1. NVD CVE-2026-28727
2. Acronis advisory SEC-9408
3. Acronis True Image build 42902 update page
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS
6. CVE.org record
7. SentinelOne vulnerability database entry
8. Vulners record