Attackers Are Abusing the Backup Plugin Behind Your Hosting Control Panel
The software kept for recovery needs its own place in the patch queue. An Acronis backup privilege escalation vulnerability has drawn targeted exploitation, turning a local Linux foothold into a question about the power an attacker can gain through the hosting control panel’s backup integration.
Acronis advisory SEC-10986 identifies CVE-2026-87886 as a high-severity, 7.8 flaw involving insecure file permissions. Its published vector requires low privileges and local access on Linux, without user interaction. This is not an unauthenticated remote takeover of every cPanel or Plesk server.
The vendor reports limited, targeted exploitation against its cPanel & WHM plugin. In a statement to BleepingComputer, Acronis said its assessment rested on one potentially affected customer’s report. The reviewed sources do not identify an actor, a campaign’s scale or specific compromise indicators. Its Plesk update notice separately says it sees no signs of active exploitation.
Check the backup integration’s actual build
| Linux integration | Affected builds | First fixed build |
|---|---|---|
| Acronis Backup plugin for cPanel & WHM | Earlier than 1.9.3.1021 | 1.9.3.1021, described as 1.9.3 HF3 |
| Acronis Backup extension for Plesk | Earlier than 1.8.11.638 | 1.8.11.638, within the 1.8.11 release |
The cPanel/WHM hotfix notice dates to 11 September; the Plesk notice dates to 10 September. Both were updated on 15 September. A fix already being available does not establish that a particular host received it.
CISA’s official KEV feed records the addition on 16 September, a 19 September deadline for covered US federal civilian agencies, and forensic triage requirements. That deadline is not a universal legal obligation. It is an urgency signal; ransomware use is marked unknown, not confirmed.
No verified public proof of concept or separate vendor workaround was established in the reviewed sources. Apply the fixed software. Do not mistake the lack of a public exploit or a named victim for assurance that a vulnerable integration is safe.
A local prerequisite is not a reason to leave the flaw open
For a hosting provider, the right question is which identities and workloads could supply that prerequisite. BlackTree recommends mapping the local access available to accounts, applications and automation on the affected host. Do not assume that an internal service is beyond reach simply because the original intrusion happened through a different component.
The sources do not prove a specific cross-customer escape or that backups were altered. Those outcomes should not be presented as incident facts. However, the separation between ordinary workload access and privileged administration is exactly the boundary that a local escalation review needs to examine.
Close the exposure and keep recovery evidence separate
- Inventory the integration itself. Record each host, plugin or extension build, Linux environment and owner. Include standby, migration and test hosts that retain real credentials or data.
- Verify the installed fix. Use the complete build threshold, not only a product name or short release label. Confirm the running integration after the authorised update.
- Review the access prerequisite. Identify existing local accounts, jobs and application access that could matter. Prioritise hosts with suspicious activity or an unresolved initial intrusion.
- Preserve evidence before destructive work. Involve responders when compromise is suspected. Retain relevant identity, endpoint and connection records outside the potentially affected host.
- Separate patching from investigation. Record the vulnerable period and the evidence reviewed. Installing a fix does not establish what happened before it was installed.
- Validate recovery controls. Check expected backup and restore operation after the change. If evidence suggests compromise, assess the integrity and credentials of recovery systems rather than assuming the software update answers those questions.
These are BlackTree’s enterprise response recommendations, not vendor-published indicators or proof that every affected server needs rebuilding. Escalate unexplained activity to qualified incident responders and the vendor. Credential rotation and recovery scope should follow the evidence and the systems actually exposed.
The urgent decision is to remove the known privilege boundary failure in CVE-2026-87886. The separate decision is how much confidence the organisation has in the host and its recovery arrangements. Neither should be left waiting for a more dramatic incident description.
Sources
- Acronis, advisory SEC-10986, verified through its public original data record. The record gives publication on 15 September 2026 at 15:30 UTC, 17:30 Europe/Madrid, and no separate update timestamp. The public Atom feed uses the same clock.
- CISA, official KEV record, added 16 September 2026, deadline 19 September. No individual entry publication clock is provided.
- BleepingComputer, Acronis exploitation and patch reporting, published 15 September 2026 at 17:37 as displayed. The page does not label the timezone; no separate update clock was verified.
Acronis update records: cPanel & WHM 1.9.3 HF3, published 11 September 2026 at 12:30 UTC, 14:30 Madrid; Plesk 1.8.11, published 10 September at 13:30 UTC, 15:30 Madrid. Both records were updated 15 September at 15:30 UTC, 17:30 Madrid. Exact clocks come from the vendor’s public data, not inferred relative labels.
The focus on backup integrations as part of the security patching process is particularly useful, since recovery software can also introduce privilege risks. The distinction between local access requirements and remote takeover, together with the recommendations to verify exact builds, review access, preserve evidence, and validate backup integrity, provides a practical approach to handling CVE-2026-8788