72 Hours to Root: Acronis CVE-2026-87886 and the Shared Hosting Box Nobody Watches

CISA put CVE-2026-87886 on the Known Exploited Vulnerabilities catalog on 16 September 2026 and set the federal remediation deadline for 19 September. Three days. That is today, and if you run web hosting infrastructure the deadline applies to you in spirit even if BOD 26-04 does not apply to you in law.

The bug itself reads like a footnote. Acronis describes it as a local privilege escalation caused by insecure file permissions in the Acronis Backup plugin for cPanel and WHM on Linux, CVSS 7.8, CWE-276 in CISA's phrasing. Builds before 1.9.3.1021 are affected, with 1.9.3 HF3 carrying the fix. The Plesk extension is listed as affected below build 1.8.11.638. The line from Acronis advisory SEC-10986 that earned it a KEV slot is this one: "Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments."

No public exploit. No named actor. No details on what the intruders did after they got root. A Hacker News request for comment got an Acronis spokesperson saying they had nothing to add. So what we have is a shape, not a story, and the shape is the interesting part.

"Local" and "authenticated" mean something different on a hosting box

Every CVSS rating that starts with local access and low privileges gets triaged down somewhere in the queue. That reflex is built on an assumption from the corporate estate: to be a local user on a server, you had to become an employee, or phish one, or land a beachhead first. Local access is expensive, so a local bug is cheap to defer.

Shared hosting breaks that assumption completely. On a cPanel box, a local low-privilege account is the product. You buy one with a credit card. There might be three hundred of them on the same kernel, each one a separate business, each one with a control panel password that somebody's marketing intern reuses on four other sites. The distance between "unauthenticated internet attacker" and "authenticated local user with low privileges" is the price of a hosting plan, or a single entry in a stealer log.

That is why the exploitation reports say "limited, targeted." Targeted does not mean hard. It means somebody already had a foothold and knew which box they wanted root on.

The precondition is the cheapest thing in the attack

Here is the part that gets skipped in most writeups of a privesc bug. The exploit is step two. Step one is a credential, and credentials are the most oversupplied commodity in the criminal economy right now.

Flashpoint's 2026 Global Threat Intelligence Report midyear edition, covering January through June 2026, counted 1.7 billion credentials harvested by infostealer malware across 7.4 million infected hosts in six months, with Vidar, StealC and Lumma as the top three families. SpyCloud's 2026 Identity Exposure Report puts 2025 at 13.2 million infostealer infections yielding 642.4 million credentials and 8.6 billion session cookies. Whatever methodology you prefer, the conclusion is the same: nobody has to phish a hosting customer to get their cPanel password. They filter a log dump by URL.

That last detail matters more than the raw totals. Stealer logs are structured around the exact URL where each credential was typed, which makes :2083 and /whm trivially greppable. A buyer on Russian Market can select by domain or by software. The hosting provider never sees a failed login, never sees a brute force, never sees anything except a customer logging into their own account from a slightly unusual IP, which customers do constantly. I wrote about the industrialised version of this in the Zerofot campaign that automated credential harvesting end to end, and the pipeline has only gotten tighter since.

So the honest reading of CVE-2026-87886 is not "low severity, requires local access." It is "the second half of a two-step chain whose first half costs about four dollars."

Multi-tenancy turns a 7.8 into a 9-point-something

The other thing CVSS cannot express is blast radius across tenants. Root on a laptop is root on a laptop. Root on a cPanel server is:

• Every other customer's document root, including their wp-config.php and its database credentials
• Every .my.cnf and .env file under /home/*
• Every SSH private key and authorized_keys file on the box
• The backup agent's own configuration, which by design holds credentials for wherever the backups go, typically object storage in somebody's cloud account
• The ability to modify the login page every one of those customers types their password into

Estimates of internet-exposed cPanel put the number somewhere between 1.5 million instances by Rapid7's Shodan count and over 2 million by Eye Security's. Backup plugins are not installed on all of them, but they are disproportionately installed on the ones run by hosting companies and MSPs, which is to say the ones with the highest customer-per-server ratio.

We covered the same structural problem from a different direction when one N-central RMM server exposed every downstream MSP customer. Backup and management tooling sits at the exact point in an architecture where one compromise fans out. That is not a coincidence, it is what those tools are for.

And the April cPanel authentication bypass, CVE-2026-41940, already showed how this population behaves under fire: KnownHost traced exploitation back to 23 February 2026, more than two months before disclosure. Our teardown of that zero-to-hero-days window holds up depressingly well as a template for what is probably happening with this one.

Why your detection stack is not going to catch this

I have spent enough time in detection engineering to be blunt about the coverage here. Shared hosting servers are among the least instrumented production systems in existence, and the reasons are structural rather than lazy:

No EDR agent. Hosting margins do not support per-server EDR licensing across a fleet of thousands, and the agents that do get installed are often excluded from /home to avoid melting the CPU on a box running three hundred PHP sites.

Root is normal. The backup plugin legitimately runs as root. It reads every customer's files as root. It writes archives as root. An attacker who escalates through it inherits an activity profile that is indistinguishable from the tool doing its job, because it is the tool doing its job.

The interesting reads look like backups. File access across every tenant home directory is the single most normal event on this server. Any rule that alerts on it alerts continuously.

Nobody owns the logs. The hosting provider watches uptime and abuse complaints. The tenant watches their own site. Neither party is running a SIEM correlation on kernel-level activity, and a privesc that happens inside a plugin's own process leaves very little for either one to correlate.

Put those together and you get the profile that made this a KEV entry in the first place: quiet, targeted, no public exploit, no forensic detail released. CISA's own BOD 26-04 language asks agencies to check whether threat actors compromised the system before the patch was applied, which is an admission that patch status and compromise status are different questions.

The patch closes the hole. It does not un-steal anything.

This is the part I want hosting operators to sit with. The permissions fix in 1.9.3.1021 changes what an attacker can do tomorrow. It does nothing about the database credentials, object storage keys and SSH material that a successful escalation already copied out. Credentials survive patching. We made this argument at length about the Artifactory tokens that outlived their own patch, and the logic transfers cleanly: the vulnerability had a lifetime, the secrets it exposed have a different and much longer one.

If you patch and stop there, the actual outcome of your incident response is that you have secured the door on a house where the keys are already copied.

Rotation is the real work, and on a multi-tenant box it is genuinely unpleasant: you are asking hundreds of customers to change credentials they did not know you could read. Do it anyway for anything you control directly, starting with the backup target's storage keys, then your own WHM and root SSH material, then any shared service account the plugin touched.

What deception is actually good for here

I am not going to pretend a honeytoken would have blocked this exploit. It would not have. Deception does not stop privilege escalation, and anybody selling it that way is selling the wrong thing.

What it does is solve the specific detection failure described above, which is that on this class of server every legitimate signal is noise. A decoy inverts that. Plant a wp-config.php in a document root that serves no live site, with database credentials that map to a mine rather than a database. Drop a .my.cnf in a home directory that has no customer. Put an object storage key in a backup configuration file that the real backup job never reads.

Now think about who touches those files. The backup agent will, during a scheduled run, which is a known and filterable pattern. Nothing else will, because nothing else has a reason to know they exist. There is no legitimate process on that machine that enumerates tenant home directories looking for credential files outside a backup window. So when one of those planted credentials gets used, you do not get a probability score. You get a fact: something authenticated with a secret that exists nowhere except as bait. That is what the zero false positive claim actually rests on, and it is the only property that makes this deployable on a box where conventional alerting has already been tuned into silence.

The same structure covers the exfiltration path. A decoy cloud key in the backup config gets used from an IP that is not your backup infrastructure, and you have both the compromise and the attacker's egress point in one event. MineField's decoy services extend the idea to the network layer on these hosts, where a fake internal MySQL or SSH listener catches the lateral sweep that follows escalation.

The uncomfortable honest note: deception on shared hosting requires you to think about which tenant directory you are planting in, because a decoy sitting inside a paying customer's document root is a decoy that customer's own developers can trip. Use empty or reserved accounts. Use the provider-controlled paths. This is a five minute design decision that people skip and then blame the tooling for.

If you run one of these servers, today

Install 1.9.3 HF3 (build 1.9.3.1021) or later for cPanel and WHM, and build 1.8.11.638 or later for Plesk. That is the non-negotiable part and the KEV deadline is now.

Then assume the window was open. Pull backup plugin logs for the period before the patch and look for runs that do not match your schedule. Check for accounts created in WHM outside your provisioning workflow, since persistence that survives a patch is the whole point of getting root. Rotate the backup storage credentials regardless of what you find, because their exposure cost nothing to an attacker and their rotation costs you an afternoon. And treat any tenant account that shows a successful login from a new ASN in the last sixty days as a candidate foothold rather than a customer who went on holiday.

The thing to take away from CVE-2026-87886 is not that Acronis shipped a bad file mode. Everybody ships a bad file mode eventually. It is that the severity math we use assumes authenticated local access is a meaningful barrier, and on multi-tenant infrastructure fed by a credential market that moves 1.7 billion logins in six months, it is not a barrier at all. It is a purchase. If you want to find out whether someone has already made that purchase on your fleet, book a walkthrough of how Mine2 deploys decoy credentials across hosting infrastructure and see what your quietest servers have been doing.