Acronis Backup CVE-2026-87886: Your Backups Still Hold the Credentials You Rotated

Rotating a credential changes the future. It does nothing to the copy sitting in last quarter's backup. CISA added CVE-2026-87886 to its Known Exploited Vulnerabilities catalog on September 16, after exploitation of a file-permission flaw in the Acronis Backup plugin for cPanel & WHM. The federal remediation deadline is September 19.

On its own this is a local privilege-escalation bug with a moderate score, the kind that usually gets patched quietly. It is worth more attention than that, for two reasons: the software sits on shared hosting infrastructure where one tenant reaching root affects everyone else on the box, and the data it guards is the most complete copy of your secrets that exists anywhere.

What is confirmed

CISA's KEV entry names it an “Acronis Backup Incorrect Default Permissions Vulnerability” and states that the Acronis Backup plugin for cPanel & WHM and the extension for Plesk “contains an incorrect default permissions vulnerability that could allow for privilege escalation.” It was added September 16, 2026 with a due date of September 19, 2026.

Reporting puts the flaw at CVSS 7.8 and classifies it as CWE-276, incorrect default permissions, arising from insecure file permissions in the Linux backup components. An attacker needs local access and low privileges; no user interaction is required. Exploitation has been observed in limited, targeted attacks against cPanel & WHM deployments. Acronis tracks the issue as advisory SEC-10986.

Reporting cites fixed releases of 1.9.3 HF3 for the cPanel & WHM plugin and 1.8.11 for the Plesk extension. Confirm the exact build against the Acronis advisory for your product before you sign off the change—published build strings for this one vary slightly between write-ups.

What remains unknown

“Limited, targeted attacks” is the vendor's characterisation, and no public source establishes how many hosts were affected, who conducted the attacks, or what was taken. There is no indication this is being used at scale. Local access is a real prerequisite, so this is a second-stage vulnerability: it matters most to whoever already has a foothold, which on shared hosting can be an ordinary customer account.

Why a backup bug is a secrets bug

The privilege escalation is the vulnerability. The consequence is access to backup data, system files and, on a multi-tenant host, other customers' environments on the same infrastructure. What sits in those backups is the part that outlasts the patch:

Configuration files with live credentials—database passwords, API keys, mail and payment-provider secrets in application config.
Database dumps containing password hashes, session tokens, and personal data whose disclosure obligations do not care that it came from a backup.
Private keys and certificates captured as ordinary files.
Archived mail, which is where credentials people were told not to email end up anyway.

And here is the property that makes this class of exposure different from a live compromise: backups are immune to your rotation schedule. You replace a database password in March; the January backup still has the old one. If nobody actually invalidated the old credential—and often nobody does, because rotation in practice means “start using the new one”—then a two-year-old archive is a working key.

What to do

Patch the plugin or extension on every host, and verify the installed build afterwards. On shared hosting you may be the tenant rather than the operator; ask your provider for the version they are running and the date they applied it.
Check who can read backup files. This bug is about permissions, so the review that matters is the same one regardless of vendor: which local accounts can read backup archives, their temporary working files, and the restore staging directories.
Invalidate, do not just replace. When you rotate a credential, explicitly revoke the previous value at the system that honours it. Rotation without revocation leaves every historical backup holding a live secret.
Encrypt backups with a key that is not in the backup. Backup-at-rest encryption only helps if the key lives somewhere the same compromise cannot reach—not in the config file that gets backed up alongside it.
Shorten retention deliberately. Every additional month of retained backups is another month of revoked-but-maybe-not credentials. Keep what you need for recovery and compliance; the rest is stored risk.
Reduce what lands in a backup in the first place. Secrets pulled at runtime from a secrets manager or issued as short-lived tokens are not in the archive at all. That is the only fix that makes the next backup incident smaller instead of equal.

If you share infrastructure

The multi-tenant angle deserves a separate note. On a cPanel or Plesk host your security boundary includes every other account on the machine, and you generally cannot see who they are or how carefully they operate. Assume a neighbour can become a local attacker, and hold your provider to a patch commitment with dates rather than assurances. If your workload genuinely cannot tolerate that shared-kernel boundary, the answer is isolation, not a better backup plugin.

Where Secretus fits—and where it does not

Secretus can reduce plaintext exposure when an authorized person must hand over a small, temporary value—a replacement database password, a restored service credential—during a rotation, through a channel that does not keep a copy the way mailboxes and tickets do. Team Split can require several holders to reconstruct a high-value text secret such as a backup-encryption recovery code.

It is not backup software, not a secrets manager, and not a place to store keys or archives. It will not tell you what your backups contain, and it cannot revoke a credential that an old archive still holds—only the system that honours that credential can do that. Patch the plugin, then go and find out what your backups are still keeping alive.