This is a loose service hatch inside the machine, not an unlocked front gate
CVE-2026-28721 is a Windows-only local privilege escalation in Acronis Cyber Protect 17 before build 41186. The flaw is described as improper soft link handling: a low-privileged local user can abuse symbolic-link or junction behavior so a privileged Acronis operation touches the wrong file or path, potentially turning a normal user foothold into SYSTEM-level control on the host.
The vendor's HIGH 7.3 score is technically defensible in a lab because successful exploitation can end in full host compromise. In real enterprise operations, though, the biggest fact is the one CVSS compresses away: the attacker already needs local access, low privileges, and some triggering/user interaction on a machine that both runs Acronis and is still on a pre-41186 build. That makes this a post-compromise escalator, not an initial-access bug, so the practical urgency drops into MEDIUM.
4 steps from start to impact.
Land low-priv code execution on a protected Windows host
- Windows host has Acronis Cyber Protect 17 installed
- Version is before build 41186
- Attacker already has local execution or a user session
- EDR, AppLocker, WDAC, attack-surface reduction, and macro controls should block many initial footholds before this CVE matters
- Many Acronis deployments sit on servers with tighter local access than general user workstations
Find a privileged file operation to bend
mklink, NTFS junctions, or direct Win32 calls like CreateSymbolicLinkW.- Acronis service performs privileged filesystem work
- Attacker can place or point a link in a writable location relevant to that workflow
- Link creation can be constrained by permissions and platform settings
- The attacker still needs the exact Acronis path/operation pattern that follows the attacker-controlled reference
Trigger the vulnerable workflow
- Relevant Acronis action is executed
- Attacker-controlled link is in place before the privileged operation runs
- User interaction or workflow timing lowers reliability
- Single-purpose servers may not hit the vulnerable code path often
Escalate to SYSTEM on that host
- The vulnerable file operation reaches a security-sensitive target
- The target choice produces code execution or privileged tampering
- Exploit value is host-local; it does not inherently spread laterally or cross tenants
- The attacker still needs follow-on tradecraft for credential theft, persistence, or lateral movement
The supporting signals.
| In-the-wild status | No evidence of active exploitation was found in the reviewed primary sources, and CISA KEV does not list CVE-2026-28721. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit reference appears in the NVD, CVE, or vendor advisory references reviewed. That does not make the bug harmless; it just removes one urgency amplifier. |
| EPSS | User-supplied EPSS = 0.00007. That is an extremely low predicted exploitation probability, consistent with a niche, post-compromise local bug; percentile was not independently verified from FIRST data in this review. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector readout | AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H means local-only, needs existing low privileges, and needs user/workflow interaction. That is classic downward pressure versus a remotely reachable flaw. |
| Affected range | Acronis Cyber Protect 17 (Windows) before build 41186. |
| Fixed version | Vendor fix is build 41186 or later for Acronis Cyber Protect 17 on Windows. |
| Exposure reality | This is not meaningfully internet-queryable in Shodan/Censys terms because the vulnerable condition is a local Windows endpoint/server install state, not an exposed network listener. Reachable population is therefore bounded by hosts where an attacker already has execution. |
| Disclosure timing | User-supplied disclosure date is 2026-03-06; the NVD page shows the CVE was received by the CNA on 2026-03-05 and published by NVD around that same period. |
| Researcher / reporting | The reviewed public references attribute the CVE to Acronis International GmbH as CNA. No independent researcher credit was visible in the sources reviewed. |
noisgate verdict.
The decisive factor is attacker position: this bug only matters after an adversary already has local access on a vulnerable Windows host. That sharply narrows the exposed population and makes the CVE a post-compromise privilege escalator, not a broad enterprise entry point.
Why this verdict
- Local-only requirement cuts the score hard:
AV:Lmeans the attacker is already on the endpoint or server. For a 10,000-host fleet, that is not a front-door risk; it is a follow-on privilege bump after another control has already failed. - Low privileges still imply prior compromise:
PR:Lis not 'easy'; it means malware, a stolen user session, or an internal user already exists. That prerequisite compounds the downward adjustment from the vendor's 7.3 baseline. - User/workflow interaction lowers reach and reliability:
UI:Rsuggests the exploit is not pure fire-and-forget. The attacker likely needs a user action, operator workflow, or timing against a specific privileged Acronis operation, which trims mass-exploitation potential. - Windows-only and version-bounded: only Acronis Cyber Protect 17 on Windows before build 41186 is affected. That is a much narrower fleet slice than a cross-platform or remotely exposed agent flaw.
- No exploitation evidence amplifier: no KEV listing, no public PoC in reviewed primary references, and a very low user-supplied EPSS all argue against treating this as a hot operational threat.
- Not lower because SYSTEM still matters: once an attacker has local execution on a machine running a backup/security agent, turning that into SYSTEM can defeat host controls, steal secrets, and enable strong persistence. On shared admin servers, that can still be materially bad.
Why not higher?
A higher rating would require at least one strong amplifier that is missing here: unauthenticated remote reachability, broad internet exposure, active exploitation, or trivial weaponization. Instead, every major prerequisite stacks in the opposite direction: local access, existing privileges, vulnerable Windows build, and workflow interaction.
Why not lower?
This is still a real privilege-escalation path on a product that commonly runs with elevated rights and touches sensitive files. If an attacker already has a foothold, converting that foothold into SYSTEM is operationally meaningful and can be the difference between a contained user compromise and a full-host compromise.
What to do — in priority order.
- Restrict interactive access — Reduce the number of users who can log on locally or via RDP to Acronis-managed Windows servers and consoles. Because this verdict is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window while prioritizing shared admin systems and high-value backup infrastructure for tighter access control immediately.
- Watch for reparse-point abuse — Add or tune EDR/Sysmon coverage for suspicious creation of symbolic links, junctions, and abnormal writes by low-privilege users followed by Acronis service activity. There is no mitigation SLA for MEDIUM, so use this as hardening and detection coverage while you patch within the 365-day remediation window.
- Apply application control on admin-heavy hosts — Use WDAC, AppLocker, or equivalent to limit untrusted binaries and scripts on backup servers, management servers, and jump boxes where Acronis is installed. This is the control most likely to kill the prerequisite low-priv execution stage before the CVE ever becomes relevant; for MEDIUM, move it through normal hardening if not already present and remediate the vulnerable builds within 365 days.
- Prioritize multi-user and admin-path systems — If you cannot patch every Acronis Windows deployment at once, start with shared servers, management nodes, terminal servers, and endpoints used by IT admins. Those systems offer the best payoff for a local SYSTEM escalation and should be first in your normal MEDIUM remediation window.
- Perimeter firewalls or WAFs do not help; this is not a remotely reachable network bug.
- Internet exposure scanning will miss the practical risk because the vulnerable condition is an installed local agent build, not an externally fingerprintable service.
- MFA does not neutralize the vulnerability itself; it only helps reduce some paths to the prerequisite user foothold.
Crowdsourced verification payload.
Run this on the target Windows host or through your endpoint management tool as a standard inventory script. Invoke it with powershell -ExecutionPolicy Bypass -File .\check-acronis-cve-2026-28721.ps1; local admin helps for complete registry/file visibility, but normal user rights often work. The script reports VULNERABLE, PATCHED, or UNKNOWN and uses exit codes 1, 0, and 2 respectively.
# check-acronis-cve-2026-28721.ps1
# Purpose: Detect whether Acronis Cyber Protect 17 on Windows is below fixed build 41186
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
$fixedBuild = 41186
function Get-AcronisInstallInfo {
$roots = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
$results = @()
foreach ($root in $roots) {
$items = Get-ItemProperty $root | Where-Object {
$_.DisplayName -match 'Acronis Cyber Protect 17' -or $_.DisplayName -match '^Acronis Cyber Protect$'
}
foreach ($i in $items) {
$results += [PSCustomObject]@{
DisplayName = $i.DisplayName
DisplayVersion = $i.DisplayVersion
InstallLocation = $i.InstallLocation
Publisher = $i.Publisher
}
}
}
return $results
}
function Get-BuildFromText([string]$text) {
if ([string]::IsNullOrWhiteSpace($text)) { return $null }
# Try dotted versions first, e.g. 17.0.41186 or 17.0.41186.0
if ($text -match '(\d+)\.(\d+)\.(\d+)(?:\.(\d+))?') {
return [int]$Matches[3]
}
# Fallback: last 4-6 digit number in the string
$nums = [regex]::Matches($text, '(\d{4,6})') | ForEach-Object { $_.Value }
if ($nums.Count -gt 0) {
return [int]$nums[$nums.Count - 1]
}
return $null
}
$installs = Get-AcronisInstallInfo
if (-not $installs -or $installs.Count -eq 0) {
Write-Output 'UNKNOWN: Acronis Cyber Protect 17 installation not found in uninstall registry.'
exit 2
}
$best = $null
foreach ($app in $installs) {
$build = Get-BuildFromText $app.DisplayVersion
# If registry version is unclear, try a likely executable path under InstallLocation
if (-not $build -and $app.InstallLocation) {
$candidates = @(
(Join-Path $app.InstallLocation 'Agent\acronis_agent.exe'),
(Join-Path $app.InstallLocation 'CyberProtectionService.exe'),
(Join-Path $app.InstallLocation 'AcronisAgent.exe')
)
foreach ($c in $candidates) {
if (Test-Path $c) {
$fv = (Get-Item $c).VersionInfo.FileVersion
$build = Get-BuildFromText $fv
if ($build) { break }
}
}
}
$record = [PSCustomObject]@{
DisplayName = $app.DisplayName
DisplayVersion = $app.DisplayVersion
InstallLocation = $app.InstallLocation
Build = $build
}
if (-not $best) { $best = $record }
elseif ($record.Build -and (-not $best.Build -or $record.Build -gt $best.Build)) { $best = $record }
}
if (-not $best.Build) {
Write-Output ('UNKNOWN: Found Acronis install but could not determine build. Name="{0}" Version="{1}" Path="{2}"' -f $best.DisplayName, $best.DisplayVersion, $best.InstallLocation)
exit 2
}
if ($best.Build -lt $fixedBuild) {
Write-Output ('VULNERABLE: {0} Version="{1}" Build={2} is below fixed build {3}.' -f $best.DisplayName, $best.DisplayVersion, $best.Build, $fixedBuild)
exit 1
}
else {
Write-Output ('PATCHED: {0} Version="{1}" Build={2} is at or above fixed build {3}.' -f $best.DisplayName, $best.DisplayVersion, $best.Build, $fixedBuild)
exit 0
}
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.