CVSS 7.8. Attack vector local, privileges required low, user interaction none. On most estates that combination buys a vulnerability a slot in next month's maintenance window. CVE-2026-87886 got a different schedule: Acronis published the advisory on September 15, and CISA added it to the Known Exploited Vulnerabilities catalog the next day with a remediation date of September 19.
The product is why. The bug sits in the Acronis Backup plugin for cPanel & WHM, and a cPanel server's entire business is handing out local accounts with low privileges. The exploit's entry condition ships with the service. Every hosting account on the box already satisfies it, and so does anyone who gets a single PHP file written into any one of those accounts.
What Acronis actually fixed
Advisory SEC-10986 describes the defect in one line: local privilege escalation due to insecure file permissions. The class is CWE-276, incorrect default permissions, and the vector is CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Two builds carry the fix:
- Acronis Backup plugin for cPanel & WHM (Linux) - affected before build
1.9.3.1021, fixed in 1.9.3 HF3. - Acronis Backup extension for Plesk (Linux) - affected before build
1.8.11.638, fixed in that build.
Acronis states that exploitation has been detected in the wild in limited, targeted attacks against cPanel & WHM deployments. The Plesk extension takes the same fix and carries no reported exploitation. The vendor has not named the file, the directory, or the permission bits, and no public proof of concept exists. CWE-276 still tells you the shape of it: an object that the root-privileged half of the plugin reads, writes, or executes was left reachable by an unprivileged local user. Whoever controls that object gets to decide what root does next.
CISA's September 19 date binds federal civilian agencies under BOD 26-04. For everyone else it carries no legal weight, and it is still the most useful number in the advisory. It is CISA's public estimate of how long this stays a limited, targeted problem.
Who this is for, and who can stop reading
If your Linux servers are boxes you build yourself with no hosting control panel in front of them, this one is not yours. The Acronis Cyber Protect agent you may run on workstations and file servers is a different product line under a different advisory. Close the tab.
Three groups should keep going, and they have different jobs.
Hosting providers and resellers running cPanel & WHM with the Acronis plugin installed are the direct targets. You have the package, you have the untrusted local users, and exploitation is already happening. Patch tonight.
Managed service providers who park client WordPress, Magento, or WooCommerce sites on a shared cPanel box are in the same position, with one addition: your exposure is the sum of every client's plugin hygiene, not your own. You do not control stage one of this chain. You do control stage two.
Small businesses who rent space rather than run the server are the third group, and the honest verdict is that you cannot patch this. What you can do takes one email, and I have put the wording in the closing section. Your host either applied 1.9.3 HF3 this week or they did not, and you are entitled to know which.
How a local bug stops being local
A local privilege escalation is only as serious as the ease of getting local. On a shared web server that step is a commodity, and this month supplied a fresh example of exactly the right shape.
On September 16, coverage from The Hacker News and BleepingComputer described active exploitation of CVE-2026-27540 in the WooCommerce Wholesale Lead Capture plugin. It is an unauthenticated arbitrary file upload through the wwlc_file_upload_handler AJAX action, rated 9.8, affecting versions up to and including 2.0.3.1 and fixed in 2.0.3.2. Wordfence reports blocking more than 100,000 exploitation attempts. The payload observed in the wild is a PHP file named shell.php that reports host details and offers a browser form for writing more files.
Read the two advisories together and the chain writes itself. The WooCommerce bug gives an attacker code execution as the hosting account's Unix user: unprivileged, local, no interaction. That is the exact entry condition CVE-2026-87886 requires. Stage one costs an unauthenticated HTTP request against a plugin with 6,000 installations. Stage two costs a local exploit against a package the host installed on purpose. The result is root on a machine that also holds every other tenant.
This is the second tenant-isolation break on cPanel in a week. LiteSpeed shipped Web Server Enterprise 6.3.7 on September 11, and cPanel's advisory three days later said the flaw could bypass the controls that keep hosting accounts apart, CageFS included. No CVE has been assigned and no exploitation has been reported. We wrote about the same failure mode in LiteSpeed cPanel CVE-2026-48172. The pattern deserves a name in your threat model: the control panel's add-on layer runs as root, updates on its own schedule, and rarely appears in anybody's asset inventory.
Find out which build you are running
The cPanel plugin installs as an RPM, so the version check is short. Run it on every server, not the one you remember installing it on.
# --- cPanel & WHM hosts ---
# Fixed build is 1.9.3.1021 (shipped as 1.9.3 HF3). Anything lower is affected.
rpm -q --queryformat '%{NAME} %{VERSION}-%{RELEASE}\n' acronis-backup-cpanel 2>/dev/null \
|| echo "plugin package not installed on $(hostname)"
# Patch, then confirm the build actually moved:
yum clean metadata && yum update -y acronis-backup-cpanel
rpm -q --queryformat '%{VERSION}-%{RELEASE}\n' acronis-backup-cpanel
# --- Plesk hosts ---
# Fixed build is 1.8.11.638. No exploitation reported here, patch on the
# normal cycle rather than tonight.
plesk bin extension --list | grep -i acronis
# --- Fleet sweep from a management host ---
# Replace the host list with your inventory source.
while read -r h; do
printf '%s ' "$h"
ssh -o BatchMode=yes -o ConnectTimeout=5 "root@$h" \
"rpm -q --queryformat '%{VERSION}-%{RELEASE}' acronis-backup-cpanel 2>/dev/null || echo absent"
echo
done < hosts.txtTwo results are worth pausing on. A host that reports absent may still have the plugin installed outside the package manager, because Acronis also ships a shell installer. A host that reports a build number lower than 1.9.3.1021 after a successful yum update is pointed at a stale mirror, and the patch has not landed no matter what the ticket says.
Root on that box reaches the backups
Most privilege-escalation write-ups stop at the word root. Here the identity of the compromised software changes what root is worth.
The Acronis plugin exists to hold backup configuration and credentials for every account on the server and to talk to the storage those archives live in. An attacker who escalates through it arrives with control of the machine and a working, authorised path to the recovery copies of every tenant on it. That inverts the usual assumption behind a restore. The intruder held working credentials to the same archive set you would restore from.
Three consequences follow, and they change the order of your response:
- Restore does not clear the incident. If the web shell that got them local was captured in a backup taken after stage one, restoring reinstalls it. Check the timeline of your archive set against the earliest evidence of compromise before you restore anything.
- Backup credentials are now in scope for rotation. Storage keys, cloud destination tokens, and any retention-policy account the plugin authenticates with were readable by root on a host you must assume was root-owned by someone else.
- Immutability is the control that survives this. Object-lock or write-once retention on the destination is the one setting that keeps an archive trustworthy when the host that writes to it is compromised. If your backup destination lets the writing host delete or rewrite history, it inherits the compromise.
What to pull out of the logs first
There are no published indicators for CVE-2026-87886, so hunt the chain rather than the exploit. The stage-one half is well documented and leaves ordinary web-server evidence.
# 1. The documented stage-one entry point, in the account access logs.
grep -rhE 'admin-ajax\.php.*wwlc_file_upload_handler' \
/home/*/logs/*.log /var/log/apache2/domlogs/* 2>/dev/null \
| awk '{print $1}' | sort | uniq -c | sort -rn | head -20
# 2. PHP written into upload directories, which should hold media only.
find /home/*/public_html/wp-content/uploads -name '*.php' \
-newermt '2026-06-01' -printf '%TY-%Tm-%Td %u %p\n' 2>/dev/null
# 3. Files under the plugin that a non-root user can write. This is the
# CWE-276 class itself, and it is worth auditing after the update too.
find /usr/local/cpanel/base/3rdparty/acronis /opt/acronis \
\( -perm -o+w -o -perm -g+w \) -not -type l -printf '%M %u:%g %p\n' 2>/dev/null
# 4. setuid and setgid binaries anywhere an account can reach them.
find /home /tmp /var/tmp -xdev -perm /6000 -type f -printf '%M %u %p\n' 2>/dev/null
# 5. Accounts that gained a shell or a key since the advisory date.
awk -F: '$3 >= 1000 && $7 !~ /nologin|false/ {print $1, $3, $7}' /etc/passwd
find /root /home -name authorized_keys -newermt '2026-09-10' -printf '%TY-%Tm-%Td %p\n' 2>/dev/nullQuery one is the highest-yield line in the set, because it tells you whether the account was reachable at all. A hit there with a 200 response, followed by a new PHP file in query two, is a confirmed stage one and means you treat the whole server as suspect rather than the single account. Queries three and four are the local half. Neither proves exploitation of this CVE, and both surface the conditions that make the class work.
One caution about the second query. On a busy reseller box, legitimate plugins do write PHP into wp-content, though almost never into uploads. Read the file before you delete it, and keep a copy. That file is often the only surviving record of how they arrived.
Prove the archive survived the intrusion
Patching the plugin is an hour of work and it is the easy half. The half that decides how the next month goes is whether the backups on that server still mean anything, and there is exactly one way to find out. Pick an account, restore it to a scratch host that touches nothing in production, and read what comes back: the file listing, the database, the plugin versions, the presence or absence of a shell.php you did not put there. A restore you have performed this week is worth more than a monitoring dashboard that has been green for a year.
If you rent space rather than run the server, send your host one message today and keep the reply. Ask three things: whether the Acronis Backup plugin is installed on the server your sites sit on, whether it is on build 1.9.3.1021 or later, and whether your backup destination has object-lock or equivalent write-once retention enabled. A host that answers all three in a sentence is doing the work. A host that answers none of them has told you something useful too.
We help small teams test the restore path before an incident forces the question, and we read the answers your hosting provider gives you. If the exercise above is on a list nobody has time for this week, that is the conversation to have.
Need an incident response plan before the next attack?
We help organizations build and test incident response playbooks, including the restore exercise that proves a backup set survived the intrusion. Book a session with our team.