Acronis Backup CVE-2026-87886: Insecure Permissions on cPanel/Plesk Plugins Exploited for Root, Now in CISA KEV

Introduction

CISA added CVE-2026-87886 to the Known Exploited Vulnerabilities catalog on September 16 alongside the Cisco ISE CVSS 10.0, with a federal due date of September 19. The bug is a local privilege escalation in Acronis Backup's Linux hosting integrations: the plugin for cPanel & WHM and the extension for Plesk install files with incorrect default permissions. A low-privileged local user can tamper with files the backup service trusts and execute code as root. Acronis (advisory SEC-10986) says it has seen exploitation in limited, targeted attacks against the cPanel plugin. Shared hosting is the obvious blast radius — one customer shell on a box that also runs the backup plugin.

What Happened

Acronis rates the issue CVSS 3.0 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): local, low complexity, low privileges, no user interaction, full impact on the host. That is not a remote unauth RCE. It is the exact pattern that matters on multi-tenant hosting: the backup agent has to read every customer's home directory, so it runs hot, and a world-writable or group-writable control file becomes a root oracle for anyone who already has a shell.

Affected products and fixed builds from Acronis:

  • Acronis Backup plugin for cPanel & WHM (Linux) — versions 1.9 before build 1.9.3.1021 (1.9.3 HF3)
  • Acronis Backup extension for Plesk (Linux) — versions 1.8 before build 1.8.11.638 (1.8.11)

Acronis's own wording: exploitation detected in the wild in limited, targeted attacks against the cPanel & WHM plugin deployments. CISA's KEV addition does not require the CVE to be mass-wormable; it requires evidence it was used. For hosting providers still cleaning up from this year's cPanel auth-bypass wave (CVE-2026-41940 and the Sorry ransomware fallout), a local LPE in the backup plugin is how a single remaining webshell becomes host-wide persistence.

Why It Matters

Backup software on a shared host is structurally over-privileged. It must read /home, databases, and mail spools. If a tenant or a leftover webshell can rewrite a script or config that the backup service executes as root, every other tenant's data is in play — and so is the backup catalog itself, which is the one copy you were going to restore from after ransomware.

Pair that with this site's earlier cPanel coverage: mass scanning, WHM auth bypass, Sorry encryptors. An LPE in the backup plugin is the privilege step that turns "I have a customer account" into "I own the hypervisor-adjacent host." CISA putting a three-day clock on it is the signal for MSPs and hosts to treat the Acronis add-on like production software, not a panel checkbox.

Who Is Affected

  • Linux cPanel/WHM servers with Acronis Backup plugin 1.9.x before build 1.9.3.1021
  • Linux Plesk servers with Acronis Backup extension 1.8.x before build 1.8.11.638
  • Shared-hosting and MSP estates where untrusted tenants have SSH, cron, or a webshell
  • Indirectly, every customer whose backups and home directories live on those boxes

How to Protect Yourself

1. Inventory the exact plugin build, not just "Acronis is installed."

# cPanel / RPM-style installs
rpm -qa | grep -i acronis
find /usr/local/cpanel /opt /usr/libexec -iname '*acronis*' 2>/dev/null | head

# Plesk
plesk bin extension --list | grep -i acronis
rpm -qa | grep -i acronis

Confirm the build string: cPanel plugin must be 1.9.3.1021 or later; Plesk extension 1.8.11.638 or later. Update through the vendor's documented channel for that panel (Acronis 1.9.3 HF3 / 1.8.11), then re-check the running package.

2. After upgrading, audit ownership and mode on Acronis plugin paths. The CVE is incorrect default permissions. Look for files the backup service executes or reads that are writable by users other than root / the Acronis service account:

# tighten the hunt to Acronis install prefixes you found above
find /usr/lib/Acronis /opt/acronis /usr/local/cpanel/3rdparty/acronis \
  -type f \( -perm -0002 -o -perm -0020 \) -ls 2>/dev/null

find /usr/lib/Acronis /opt/acronis -type d \( -perm -0002 -o -perm -0020 \) -ls 2>/dev/null

World-writable binaries, cron snippets, or config next to a backup daemon are the finding. Compare against package RPM metadata (rpm -V <package>) so you can tell vendor defaults from attacker changes.

3. Hunt as if a local account already tried the LPE, especially on cPanel hosts with a messy 2026:

# unexpected roots, new sudoers, new cron as root
awk -F: '($3==0){print}' /etc/passwd
grep -R . /etc/sudoers /etc/sudoers.d 2>/dev/null
find /etc/cron* /var/spool/cron -type f -mtime -60 -ls

# leftover webshells in tenant homes — same hunt as the CVE-2026-41940 playbook
find /home -type f \( -name '*.php' -o -name '*.phtml' \) -mtime -90 \
  -exec grep -lE 'eval\s*\(|base64_decode|passthru' {} + 2>/dev/null | head

If you find a writable Acronis helper that a tenant could have replaced, treat the host as compromised: rotate panel root, Acronis console credentials, backup-encryption keys, and tenant database passwords that the plugin could read.

4. Reduce local attack surface on multi-tenant boxes. Do not give hosting customers a login shell unless they need one. Jail SSH. Keep the backup plugin updated on the same cadence as cPanel/upcp. Backup daemons should not be reachable from tenant cron.

Source