The short answer: CVE-2026-87886 is an actively exploited vulnerability affecting the Acronis Backup plugins for cPanel & WHM and Plesk. Check whether the plugin is installed on each server and which version it is running, install the patched version, and separately investigate whether any privilege escalation or backup changes occurred before the update.
What happened on September 16, 2026
On September 16, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-87886 to its Known Exploited Vulnerabilities catalog following evidence of active exploitation. The vulnerability affects Acronis Backup plugins used on Linux servers managed through cPanel & WHM or Plesk.
CISA published the information in its September 16, 2026 alert. According to a BleepingComputer report from September 15, 2026, the vulnerability has a High severity rating and a CVSS score of 7.8. Acronis described the observed attacks as limited and targeted; BleepingComputer added that the vendor based its assessment on a report from one „potentially impacted" customer and had not yet published indicators of compromise. CISA classifies the vulnerability in its catalog as Incorrect Default Permissions.
Publicly available information does not state how many servers were compromised or identify the affected organizations. You therefore cannot estimate the scale of the attacks based on whether you have encountered a publicly documented incident.
Which servers are affected
CVE-2026-87886 does not automatically affect every server running cPanel or Plesk, nor does it affect every Acronis product. What matters is whether the relevant backup plugin is installed on a particular Linux server and which version it is running.
According to the published information, the following versions contain the fix:
| Environment | Vulnerable builds | Version containing the fix |
|---|---|---|
| Acronis Backup plugin for cPanel & WHM | earlier than 1.9.3.1021 | 1.9.3 HF3 |
| Acronis Backup extension for Plesk | earlier than 1.8.11.638 | 1.8.11 |
Check every server individually. The version found on one cPanel server tells you nothing about other nodes or separate Plesk installations.
If the plugin is not installed on a server, the mere presence of cPanel or Plesk does not mean that this particular vulnerability affects it.
Why „the backups are working" is not enough
CVE-2026-87886 allows a local user with limited privileges to elevate their permissions on the server. The cited descriptions do not indicate that the vulnerability alone enables anonymous remote access. An attacker must first gain local access through a less privileged account.
That does not make it a minor issue. Once privileges have been elevated, the entire server may be at risk—not just a single backup job. You must therefore also inspect accounts, SSH keys, sudo rules, system services, and backup configuration.
A successfully completed backup does not prove that:
- the server was not compromised before the update;
- no one changed user accounts or permissions;
- the destination storage and retention rules remained unchanged;
- backup credentials were not exposed;
- the data can actually be restored from the backup.
The update closes the known vulnerability. It does not automatically undo changes made before installation, nor does it prove that the vulnerability was not exploited.
What to do immediately
Treat the response as two separate tasks: installing the fix and investigating a possible compromise. An „updated" result does not mean that the server has been investigated.
1. Find every installation of the plugin
Review all Linux servers running cPanel & WHM or Plesk. Do not limit the check to your primary production server. The plugin may also be running on an older node, a backup server, or a system managed by an external provider.
For each server, record:
- the server name or a unique identifier;
- the administration panel in use;
- whether the Acronis Backup plugin is installed;
- the detected plugin version;
- the date and time of the check;
- the person who verified the status.
2. Capture the state before making changes
Before updating, preserve the information needed to reconstruct a timeline later. At a minimum, this includes the plugin version, available system logs, and a list of administrative accounts.
Do not rely solely on the administration panel display. The result should be a traceable record that can be revisited during a security review.
3. Install the patched version
The patched version listed for cPanel & WHM is 1.9.3 HF3; for Plesk, it is version 1.8.11. After updating, retrieve the version that is actually installed.
A success message from the installation tool is not enough. Verify the component’s status directly on every server you inspect and record the installation time.
4. Preserve available logs
Secure relevant records before log rotation overwrites or removes them. Depending on the distribution and configuration, these may include the systemd journal, /var/log/auth.log, /var/log/secure, administration panel logs, and Acronis plugin logs.
For each source, record:
- the start and end dates covered by the logs;
- whether the server time is synchronized correctly;
- whether there are any gaps in the period;
- whether the logs were stored outside the server being investigated.
A missing log is not evidence of a compromise. However, it also makes it impossible to reliably determine what happened during the uncovered period.
5. Define the investigation period
The security review should cover the period from the last demonstrably secure state until the fix was installed. If you cannot determine when that secure state occurred, document this as a limitation in the final report.
Do not select an arbitrarily short period simply because older records are unavailable. The range of available data and the actual scope of certainty are two different things.
What to inspect after installing the fix
The review must not end with the statement „we found nothing in the logs." It must be clear which sources the administrator checked, what period they covered, and what could not be verified.
In particular, check for:
- newly created, unlocked, or modified local accounts;
- changes to membership in privileged groups;
- modifications to
sudoersand other privilege-escalation rules; - new or modified SSH keys;
- unusual logins and use of privileged commands;
- new cron jobs;
- new or modified systemd services and timers;
- changes to the configuration of cPanel, Plesk, and the Acronis plugin;
- changes to destination storage and retention rules;
- changes to credentials used for backups.
If you find an unexpected administrator account, a new SSH key, or an unknown service, do not consider the incident resolved merely because you removed the item. You need to determine when the change was made, which account was used, and whether the same access was used elsewhere.
If the findings indicate an ongoing attack, follow your established incident response plan. For a practical overview of the first steps, see Ransomware in a business: the first 24 hours.
Verify that the backups are usable
The existence of backup files does not mean that recovery works. Select a specific recovery point and perform a test restore in an isolated environment where production data cannot be overwritten.
The test should document:
- the date and job from which the backup was selected;
- where it was restored;
- whether the data could be opened;
- whether it matches the expected recovery point;
- whether the test used any credentials whose integrity is in doubt.
We provide detailed instructions in Backup recovery testing: how to perform and document it. The aim is not merely to obtain a green job status, but to demonstrate that the data is readable and usable.
What to request from your administrator
Ask your internal administrator or external provider for a specific handover record. It should include:
- a list of all servers reviewed;
- whether the plugin was installed on each server;
- the version before and after the fix;
- the date and time when the fix was installed;
- a list of the logs reviewed and the periods they cover;
- the results of checks covering accounts, permissions, and persistence mechanisms;
- the results of the backup configuration review;
- the results of the test restore;
- any anomalies found and how they will be addressed;
- anything that could not be verified retrospectively.
The statement „no findings" is meaningful only when accompanied by the scope of the review. If the logs cover only the past three days, the conclusion cannot confirm the state of the server before that period.
When to involve IT management
Seek expert assistance immediately if you cannot identify every plugin installation, do not know which build is installed, lack historical logs, or have found unexpected accounts, permissions, or changes to backup jobs.
If you have no one to handle the review, ITHOPE can perform the server update, investigate a possible breach, and test recovery as separately documented tasks. We explain what this type of service should include in What monthly IT management involves.
Require three separate outcomes:
- the vulnerable component was updated and the new version was verified;
- the available evidence was reviewed for a precisely defined period;
- a selected backup passed a genuine recovery test.
Only the combination of these outcomes answers whether the known vulnerability has been fixed, what can be established about the server’s previous state, and whether you can rely on the backup during recovery.
Frequently asked questions
Is every server running cPanel or Plesk vulnerable?
No. The vulnerability affects the relevant Acronis Backup plugin. You must therefore check whether it is installed on each server and verify its specific version.
Which versions contain the fix?
According to BleepingComputer, the fix is included in version 1.9.3 HF3 of the Acronis Backup plugin for cPanel & WHM and version 1.8.11 of the extension for Plesk.
Is installing the update enough?
No. The update fixes the vulnerable component, but it does not prove that the vulnerability was not exploited or the system was not modified before deployment.
Does inclusion in the CISA catalog mean the vulnerability is actually being exploited?
Yes. CISA stated that it added CVE-2026-87886 to the Known Exploited Vulnerabilities catalog based on evidence of active exploitation.
What if logs from before the update are missing?
Record precisely which period is not covered. Without the relevant logs, you cannot reliably confirm that the server was not compromised before the fix. Any further action must take this uncertainty, the importance of the server, and the sensitivity of the backups into account.
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).