Acronis Backup plugin for cPanel exploited in the wild; Plesk and DirectAdmin builds also fixed

Acronis has warned that a high-severity flaw in the backup plugin it ships for cPanel-based hosting servers has been used in attacks, which have been characterised as targeted [2]. The issue is tracked as CVE-2026-87886 and carries a CVSS score of 7.8 [2].

CISA added the CVE to the Known Exploited Vulnerabilities catalogue on 16 September 2026, with a remediation deadline of 19 September 2026 [1]. That is a three-day window, which is unusually tight and worth reading as a signal about how CISA views the exposure of the affected systems. The catalogue entry records known ransomware use as unknown [1].

The underlying weakness is incorrect default permissions leading to local privilege escalation [1][2]. In plain terms: files installed or written by the backup plugin are readable or writable by accounts that should not have that access, and an attacker who already has a foothold on the host can use that to move to a higher privilege level.

Who is affected

Per the vulnerability record, the affected products and fixed builds are:

• Acronis Backup plugin for cPanel & WHM (Linux), before build 1.9.3.1021
• Acronis Backup extension for Plesk (Linux), before build 1.8.11.638
• Acronis Backup plugin for DirectAdmin (Linux), before build 1.2.3.238

The scope of exploitation and the scope of the vulnerability are not the same thing in the sources we have. In-the-wild attacks are reported only against the cPanel and WHM plugin [2]. The CISA KEV entry describes the flaw as affecting the cPanel & WHM plugin and the Plesk extension [1]. The DirectAdmin build appears in the CVE record’s affected-product list only. If you run DirectAdmin or Plesk, treat them as in scope and patch them — the conservative reading is the safe one here.

The practical population at risk is shared and managed hosting: servers running a control panel where many low-privilege accounts coexist on one operating system instance. That is exactly the environment in which a local privilege escalation is most valuable to an attacker, because low-privilege access is cheap to obtain. A single compromised hosting account, a vulnerable customer web application, or a stolen panel credential can be enough of a starting point.

How it works, as far as the sources go

The CVSS vector recorded for the CVE is CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Read literally, that means: local access required, low attack complexity, some privileges already needed, no user interaction, and high impact to confidentiality, integrity and availability.

So this is not a remote entry point. It is a second-stage flaw — the step that takes a contained account compromise to a higher privilege level on the same host. The sources do not state which privilege level an attacker reaches, so treat the impact ratings in the vector as the ceiling you can actually cite. On a backup product, the relevant worry is that elevated access on that host could reach backup data and stored credentials, though no source confirms that outcome in the observed attacks.

The available sources do not describe the exploitation chain in technical detail, do not name the actors involved, and do not say when exploitation began or how many servers were affected [1][2]. No indicators of compromise have been published in the sources we have. We are not going to speculate about the mechanism beyond what the permissions description and the CVSS vector support.

What to do

• Patch now, ahead of the 19 September KEV deadline [1]. Upgrade to at least build 1.9.3.1021 (cPanel & WHM), 1.8.11.638 (Plesk) or 1.2.3.238 (DirectAdmin). Federal civilian agencies are bound by the KEV due date; everyone else should treat a three-day deadline on an actively exploited flaw as the same instruction.
• Inventory before you assume. Control panel extensions are often installed once and forgotten. Check every hosting node, including staging, legacy and customer-managed boxes, not just the fleet your configuration management knows about.
• If you cannot patch, follow CISA’s stated alternative: apply vendor mitigations, follow BOD 26-04 guidance for cloud services, or discontinue use of the product [1].
• Assume a foothold may already exist. This is a privilege escalation bug in an actively exploited state, so the interesting question is what came before it. Review panel and SSH authentication logs, web application logs for the accounts on each host, and any newly created or modified system accounts.
• Audit file permissions after upgrading. Verify that the plugin’s directories and any files it wrote are no longer group- or world-accessible. A patched installer does not always repair permissions set by the vulnerable version; confirm rather than assume.
• Review exposure of the backups themselves. Elevated access on a backup agent host can put backup content and stored credentials in reach. Rotate any credentials the plugin holds and check backup repositories for unexpected reads, deletions or new destinations.
• Watch for a follow-up advisory. With no published indicators of compromise, detection is currently limited to behavioural review. If Acronis or CISA publishes IoCs, rerun your hunt against them.