- The Mess: Acronis patched CVE-2026-87886, a Linux local privilege-escalation flaw in its backup integrations for cPanel & WHM and Plesk. Acronis says exploitation has already been detected in limited, targeted attacks against cPanel deployments.
- The Damage: A low-privileged attacker who already has local access can abuse the vulnerable component to elevate privileges on a hosting server.
- The Fix: Patch the Acronis plugin immediately, then investigate suspicious local accounts and privilege changes on exposed Linux hosts.
This is not a harmless backup-plugin bug
CVE-2026-87886 is a local privilege-escalation vulnerability caused by insecure file permissions inside Acronis backup software.
That distinction matters.
This is not an unauthenticated Internet-facing RCE where an attacker can simply scan port 443 and take over every vulnerable server. The attacker needs an existing foothold on the Linux system.
But hosting environments routinely create exactly that kind of foothold.
A compromised WordPress site, stolen hosting credentials, vulnerable web application, malicious tenant or previously compromised account can provide an attacker with limited access. CVE-2026-87886 can then become the second step: turning limited access into something substantially more powerful.
Acronis rates the vulnerability CVSS 7.8.
The company has also confirmed something more important than the score:
the vulnerability is being exploited in the wild.
Acronis says exploitation has been observed in limited, targeted attacks against its Backup plugin for cPanel & WHM deployments. There is currently no indication from the vendor that the same exploitation has been observed against the Plesk extension.
The affected components
The vulnerable software sits directly inside common hosting-management environments.
Affected versions include:
- Acronis Backup plugin for cPanel & WHM: builds earlier than 1.9.3.1021
- Acronis Backup extension for Plesk: builds earlier than 1.8.11.638
Acronis released:
- cPanel & WHM: version 1.9.3 HF3
- Plesk: version 1.8.11
Administrators should move beyond the vulnerable builds rather than attempting to compensate with filesystem permission changes of their own. The backup integration is part of a larger software stack, and manual modifications can break future updates or leave the underlying issue unresolved.
Why hosting servers are an attractive target
Acronis backup software is not sitting on an isolated workstation.
It can be deployed in environments where a single Linux server hosts:
- websites,
- databases,
- email,
- customer accounts,
- control-panel services,
- backups,
- administrative tooling.
That creates an ugly privilege boundary.
An attacker does not necessarily need to start with root.
If they compromise a low-privileged account first, a local privilege-escalation vulnerability can turn that foothold into a much more serious server compromise.
And once an attacker reaches sufficiently high privileges, the backup layer itself becomes particularly interesting.
Backups contain copies of the things administrators are trying to protect: databases, configuration files, credentials, mailboxes and application data.
The vulnerability therefore sits in an unusually valuable part of the infrastructure.
The exploitation is real — but the details are still thin
There is an important limitation here.
Acronis has confirmed exploitation, but it has not publicly disclosed detailed technical information about the attacks.
The company has also not published specific indicators of compromise.
According to reporting around the advisory, Acronis based its exploitation assessment on a report involving a potentially affected customer. The vendor has not disclosed when the attacks occurred or what attackers achieved after privilege escalation.
That means defenders should not invent an attack chain that has not been documented.
What we know is enough:
- A vulnerable local privilege-escalation condition exists.
- Acronis shipped fixes.
- Exploitation has been detected in the wild.
- The observed exploitation targets cPanel & WHM deployments.
- Public technical details and IoCs remain limited.
For defenders, that last point is annoying.
It also means absence of published IoCs is not evidence that a server is clean.
Shared hosting makes the boundary more interesting
The risk profile becomes particularly uncomfortable on multi-tenant hosting infrastructure.
A server may contain dozens or hundreds of accounts. Each account represents another possible entry point.
If one web application gets compromised, the attacker may initially be trapped inside a restricted account.
That is exactly the kind of situation where local privilege escalation becomes valuable.
The attacker does not have to break directly through the control panel.
They can potentially work sideways:
web compromise → low-privileged Linux access → privilege escalation → server-level access
CVE-2026-87886 belongs in the middle of that chain.
That does not mean every compromised WordPress account automatically becomes root. The vulnerability still depends on the vulnerable Acronis component and the attacker’s ability to reach the relevant local execution conditions.
But it changes the economics of an existing compromise.
A small foothold can become a server problem.
What administrators should do now
1. Check the installed Acronis version
Do not assume that because backups are working, the installation is safe.
Check the installed cPanel/WHM or Plesk Acronis integration against the fixed versions.
For cPanel & WHM, move to 1.9.3 HF3 or later.
For Plesk, move to 1.8.11 or later.
2. Treat cPanel exploitation as the primary concern
Acronis specifically reported exploitation against the cPanel & WHM plugin.
That should put vulnerable cPanel installations at the top of the patch queue.
Plesk systems are affected by the vulnerability, but Acronis has not reported the same active exploitation there according to the current advisory information.
3. Look for signs of privilege escalation
If a vulnerable system was exposed before patching, inspect:
- unexpected privileged users,
- new SSH keys,
- modifications to
/etc/passwdand/etc/shadow, - unexpected sudo configuration,
- recently modified system binaries,
- suspicious cron jobs,
- systemd services created outside normal deployment processes,
- unexpected processes running as root,
- unusual outbound connections,
- recently modified Acronis files.
Do not limit the investigation to the Acronis process itself.
A privilege-escalation exploit is useful precisely because the attacker may move somewhere else after gaining higher privileges.
4. Do not rely on the absence of IoCs
Acronis has not published specific indicators of compromise for this campaign.
That means defenders cannot simply grep for a known hash and declare victory.
If the server had a vulnerable version installed while an attacker had local access, investigate the system’s authentication and privilege history.
5. Patch first, investigate in parallel
On a production hosting server, waiting for a perfect forensic picture before applying the vendor fix is a bad operational trade.
Update the vulnerable component.
Then investigate.
If there are signs of compromise, treat the incident separately and consider whether credentials, SSH keys, API tokens and other secrets stored on the host need to be rotated.
The uncomfortable part
The most interesting detail is not the CVSS score.
It is the combination of local privilege escalation + hosting infrastructure + confirmed exploitation.
A local vulnerability can look less frightening than a pre-authentication RCE on paper.
On a shared Linux server, that distinction can become much less comforting.
Attackers often do not need one vulnerability that does everything.
They need a chain.
A vulnerable web application provides access.
A stolen credential provides access.
A malicious account provides access.
Then a local privilege-escalation bug removes the next security boundary.
CVE-2026-87886 fits that model perfectly.
Bugstoday’s take
Acronis did the important part: it shipped fixes after identifying exploitation.
The problem is that backup software lives in the part of the infrastructure administrators tend to trust the most.
That trust is exactly why privilege boundaries around backup agents, control panels and hosting plugins deserve aggressive monitoring.
If you run cPanel & WHM with an affected Acronis plugin, patch it now.
Then check what happened on the server before the patch arrived.
Because once an attacker gets root, the backup system stops being just a security control.
It becomes another very interesting place to look.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- Acronis security advisory SEC-10986 / CVE-2026-87886
- Acronis Backup documentation and release information
- CVE Program — CVE-2026-87886
