Acronis Backup cPanel Plugin Flaw (CVE-2026-87886) Is Being Exploited

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Infrastructure security for US and EU enterprise teams

The short answer

What Acronis disclosed

The Acronis Backup plugin for cPanel & WHM and the matching extension for Plesk bolt a hosting control panel onto Acronis backup infrastructure. They let administrators back up and restore websites, databases, mailboxes, and whole servers directly from the panel — which means the plugin runs with broad access to the files and processes on the box. Software that privileged is a high-value target: a weakness in it does not stay contained to one account.

In September 2026, Acronis disclosed CVE-2026-87886, a local privilege-escalation vulnerability rooted in insecure default file permissions (CWE-276). Because certain files or directories the plugin installs are writable or executable by accounts that should not have that access, an authenticated attacker who already holds a low-privileged position on the Linux server can leverage them to raise privileges — up to root — without any interaction from a legitimate user. The flaw carries a CVSS score of 7.8, and Acronis describes the exploitation as low-complexity.

Crucially, Acronis said exploitation has been detected in the wild in limited, targeted attacks against the cPanel & WHM plugin; it has not observed the Plesk extension being exploited, though that extension is also affected and should be patched. Shortly after disclosure, CISA added CVE-2026-87886 to its Known Exploited Vulnerabilities catalog on September 16, 2026, with a September 19 remediation deadline for U.S. federal civilian agencies — the same treatment given the day’s far-flashier maximum-severity bugs, because in-the-wild use, not raw score, is what earns a KEV listing. The remediation is straightforward: update the plugin to the fixed build. The same edge-hardening discipline we apply across a cloud and DevOps platform — least privilege, tight file permissions, and a fast patch pipeline — is exactly what this flaw exists in the absence of.

Why a “local” bug is a big deal

It is tempting to file a local, authenticated, CVSS 7.8 issue below the pre-authentication 10.0 headliners — and that instinct is exactly how these flaws get exploited. Real intrusions are chains, not single steps. Attackers land a low-privileged foothold cheaply: a vulnerable web application, a leaked SSH key, a web shell dropped through a compromised CMS, or simply one tenant account on a shared box. On its own, that foothold is limited. A privilege-escalation bug is the second half of the chain — the step that converts “I can run code as a restricted user” into “I own the machine.”

On a multi-tenant hosting server that blast radius is enormous. Root does not just mean one site; it means every website, database, and mailbox on the host, plus the backup control plane itself. That last point is what makes a backup-adjacent escalation especially dangerous: an attacker who reaches the layer that manages backups can read, exfiltrate, or destroy them, quietly stripping away the recovery path an organization is counting on if ransomware follows. The tool bought to guarantee recoverability becomes the pivot that undermines it.

There is no clever configuration that fixes insecure file permissions in third-party code — the corrected permissions ship in the patched build, which is why updating the plugin is the whole remediation. That reframes the real risk as patch velocity for the software you did not write: control-panel plugins, backup agents, and management add-ons drift out of your update cadence precisely because they feel like infrastructure rather than application code, and that gap is where an exploited-in-the-wild escalation waits.

What it means for US & EU software teams

The first lesson is that your hosting stack’s privileged add-ons are part of your attack surface. Teams inventory and patch the frameworks in their own repos, then treat the control panel and its plugins as a black box that “just runs.” But backup agents and panel extensions hold some of the most powerful access on the server, and a permissions flaw in one of them is a direct route to root. Everything you do to harden application code — least privilege, minimal file access, prompt updates — has to extend to the third-party software that sits beneath it.

The second lesson is about defense in depth so one foothold is not fatal. This escalation only pays off after an attacker already has a low-privileged position, so every control that makes that first foothold harder or louder — isolating tenants, constraining what a web process can execute, monitoring for unexpected privilege changes, and keeping the backup plane on separate credentials and networks — directly limits the damage. Assume initial footholds will happen; design so that reaching root still takes more than one unpatched plugin.

Third, this is a compliance and recovery-assurance event, not just an ops ticket. A root compromise of a server that hosts customer sites and mailboxes lands squarely within GDPR, NIS2, and DORA expectations in the EU, and HIPAA and SOC 2 obligations for US teams in health and finance — and because the backup layer is in scope, it also touches your ability to demonstrate that recovery is intact. Being able to show which hosts ran the affected plugin, when you patched, and that your backups were verified and access-controlled is the record auditors and regulators will ask for first.

What to do now

1. Inventory affected hosts. Find every Linux server running cPanel & WHM or Plesk with the Acronis Backup plugin or extension installed — including staging, legacy, and reseller boxes that fall outside the main asset list.
2. Update the plugin immediately. Install build 1.9.3.1021 (1.9.3 HF3) for cPanel & WHM or 1.8.11.638 (1.8.11) for Plesk, or later. There is no permissions workaround, so treat this as an emergency change. Patch Plesk too, even though only cPanel/WHM exploitation has been observed.
3. Hunt for escalation. Review server, sudo, and plugin logs for unexpected privilege changes, new root-owned files or cron jobs, and activity from low-privileged accounts that suddenly acted as root. A root-level intruder may also have tampered with those logs, so corroborate across sources.
4. Verify your backups. Confirm that backups are present, restorable, and stored with credentials and network access separate from the hosts they protect — the point of an attack on the backup layer is to strip your recovery option before the next stage.
5. Contain, rotate, then test. If a host was reachable and unpatched, treat it as potentially compromised: rotate credentials, keys, and secrets it held, and add hosting control panels and their plugins to the scope of your next penetration test so privileged infrastructure stops being a blind spot.

Frequently asked questions

Sources

Help Net Security — Acronis backup plugin flaw exploited in targeted attacks (CVE-2026-87886)
Security Affairs — CISA Adds Acronis Backup, Cisco ISE, and Google Pixel Flaws to KEV Catalog
CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog