Acronis Backup: "requires local access" — and that access is what you sell your customers

A CVSS of 7.8 tagged "local" is, in most teams, the CVE that gets parked. It is not a ten, it does not come in over the internet, you have to be inside already. That reasoning holds on a server with a single administrator. On a hosting server, being inside is what you sell your customers.

On Tuesday 15 September at 15:30 UTC, Acronis published advisory SEC-10986. The next day CISA added the same CVE to its known exploited vulnerabilities catalog and gave it a deadline: 19 September. Three days. The short version of the advisory fits on one line: "Local privilege escalation due to insecure file permissions".

One sentence and two build numbers

Acronis's full advisory is shorter than this paragraph. It says the flaw affects the Acronis Backup plugin for cPanel & WHM on Linux, fixed in build 1.9.3.1021, and the extension for Plesk, fixed in 1.8.11.638. It assigns CVSS 7.8 — high severity — with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, classifies it as CWE-276 (incorrect default permissions) and adds one sentence: "Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments".

And that is it. In the advisory record, the references and credits fields come back empty. No file path, no specific permission, no indicator of compromise, no date from which exploitation is known. When The Hacker News asked, an Acronis spokesperson said they had no additional information to share. The release notes are clear enough in tone: "This update contains fixes for 1 high-severity security vulnerability and should be installed immediately by all users". One thing the advisory does pin down: the observed exploitation is against cPanel & WHM deployments. Plesk has a patch, but no reported attacks.

Reading the vector slowly

The two metrics that decide this CVE's priority in any spreadsheet are AV:L (the attacker has to be on the machine) and PR:L (an unprivileged account is enough). The rest of the vector is the bad part: no user interaction, and confidentiality, integrity and availability fully compromised. Translated: total impact on the vulnerable component. And since that component is installed as root, the practical translation is that whoever holds any account on that server ends up owning the server.

Now remember where this plugin lives. It lives on hosting panels. And on a cPanel server, every account you create is a system user. cPanel's documentation does not put it in those words, but it does say what matters: on account creation "the system creates new account UIDs and GIDs with a number between 1000 and 60000", with a unique username of sixteen characters or fewer. A UID and a GID of your own are, in practice, a line in /etc/passwd with its home directory.

With that on the table, "local access with low privileges" stops being a barrier and becomes an inventory. Every customer you sell hosting to has it. Every developer you gave SSH to so they could push a shop has it. And so does, without paying a cent, anyone who manages to run PHP on the out-of-date WordPress of any of those customers, because under cPanel's usual setup — per-user PHP-FPM or suPHP — that PHP runs as that account's own user. The step that normally costs weeks of work — going from code on someone else's website to the whole machine — is handed over by a file permission.

Why that process and not another

There is a reason a permissions flaw hurts more in a backup agent than in almost any other software. The installation procedure in the plugin's manual — May 2026 revision — opens like this: "Log in to the cPanel server as a system administrator or root user". And to manually create the features that decide what each account sees, it says it again: "Log on to the host as a root user". The backup agent can read everything by definition; that is what you install it for.

The table of contents of that same manual works as an inventory of what is within reach of that process. Downloading and recovering domains. Files. Database dumps. Mailboxes. Mail filters. Forwarders. And a chapter titled "Exporting the entire account". On a single hosting machine, that is the data, the mail and the databases of every business you host.

The manual itself adds the sentence that closes the argument, and it is worth reading in full: "Only the server administrator has permission to manage backups on the web hosting server. Resellers and end users can only access and restore their data if the self-service recovery feature is available for their accounts". That boundary — the server administrator on one side; resellers and customers on the other, and only as far as you open it for them — is what a badly set file permission erases. Let us be precise about what we do not know: Acronis does not say the backups themselves were touched in these attacks, and neither do we. What we are saying is what sits within reach of whoever reaches root on that machine — a question anyone can answer without waiting for more vendor detail.

The patching queue sorts by the wrong number

A patching queue is almost always sorted on two columns: the CVSS number and whether the flaw arrives over the network. This CVE loses on both. And yet on 16 September CISA put it in the known exploited vulnerabilities catalog with a 19 September deadline — three days — the same window it gave that same day to a Cisco Identity Services Engine flaw that is remote and unauthenticated. The catalog sorts on one thing, which is whether somebody is using it.

That three-day window comes from directive BOD 26-04, dated 10 June 2026, which replaced the single deadline with a table of four variables: asset exposure, catalog status, exploit automation and technical impact. And there is one box worth knowing about, because it changes the work: when a deadline carries "& forensic triage", the obligation is not only to patch but to "complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised". This CVE's catalog entry carries that mark.

The directive binds US federal agencies and nobody else; CISA says so itself: "While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities". It does not bind you, but it is handing you the prioritisation criteria of an organisation that sees exploitation data from half the world. We treat it as an inbox. We wrote about this back with Artifactory, where the "medium" CVE landed before the critical one: severity describes the possible damage, not the odds that it reaches you this week.

What we would do this morning

If you run or maintain cPanel/WHM or Plesk servers with the Acronis plugin, this is what we would work through, in this order:

• Check the exact package build. The reference points are builds 1.9.3.1021 (cPanel & WHM) and 1.8.11.638 (Plesk); Acronis's notes list the fix as 1.9.3 HF3. An rpm -q or dpkg -l on the plugin package answers the question in ten seconds per server.
• Verify the vendor repository is still configured. The installation script, per the manual, "will register the Stable plugin repository on the system for further plugin updates via yum or apt utilities". If that repository fell off during a rebuild, or if your unattended upgrades exclude third-party packages, the patch will not arrive on its own no matter how urgent it is.
• Count the real users on that machine. Not panel accounts: lines in /etc/passwd with a UID of 1000 or above, interactive shell or not. On cPanel most carry noshell or jailshell, and it makes no difference: for this flaw it is enough to be able to run code as that user. That number is the size of your "local" attack surface.
• Do the triage even though no directive binds you. With no published indicators, what is left is the usual list, and it works: files that are new or whose owner changed in the agent's directories, setuid binaries that appeared in the last few weeks, cron jobs belonging to hosting users, keys added to root's authorized_keys, and sessions from addresses that are not yours. If you do not keep logs off the server itself, today is the day you find that out.
• Check whether your backups are still backups once that machine falls. That is the underlying question: if somebody is root on the protected server, can they delete or alter what is already stored? With immutable retention and credentials that do not live on the protected host, the answer is no. Without that, your backup is one sudo away.
• And the point everybody skips: make the same list for the other privileged agents on that machine. Monitoring, inventory, antivirus, remote access. They were all installed as root and none of them shows up in the application inventory.

On the first point it is worth insisting: having the patch installed and running the fixed build are not the same thing. Here the question has an exact numeric answer, so check it on every server instead of trusting the monthly patch report.

What this case does NOT prove

Acronis comes out of this no worse than anyone else: a default-permissions flaw in a component installed as root is among the most repeated mistakes in this trade, and it turns up in products of every size. As for the attackers, we do not know how they reached the machine — the advisory says nothing, and anyone giving you the vector in detail is making it up — so the hosting account as the way in is our hypothesis and is stated as one. And a local 7.8 is not always urgent either: on an application server with two administrators and no other users, working the normal queue order is perfectly reasonable.

The useful part of the case is smaller: the same CVE carries different urgency on two different servers, and the difference is decided by how many people hold an account on that machine. That number lives in the head of whoever administers the server, and usually nobody asks them; it is certainly not in the vulnerability scanner.

And there is the underlying matter, which goes beyond this advisory. A backup agent is the most privileged, least watched process on any server: installed once, works, never looked at again. When somebody goes after the backups they rarely attack the repository: they attack whatever has permission over it, a credential or an agent. We saw it with the group that deleted the backups at both data centres at once, where what travelled between sites was a key, not an exploit. The practical consequence is boring and applies today: your backups have to survive their own server being in somebody else's hands.

And if you take away a single task from this, make it the fifth one: run a full restore with the backup credentials living outside the protected server. We time that drill; our last full-recovery rehearsal came in at fourteen minutes, and we say that as proof it can be measured, not as a contractual promise. It is the piece of disaster recovery nobody rehearses because it never fails… until the day the agent stops being yours.

Note on sources

All consulted on 17 September 2026. One: advisory SEC-10986 from Acronis's advisory database, read in its full record (identifier, CVE-2026-87886, CWE-276, high severity with CVSS 7.8 and vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, products and fixed builds 1.9.3.1021 and 1.8.11.638, published 2026-09-15T15:30:00Z); that is the source of the targeted-attacks quote and of the observation that the references and credits fields are empty. Two: CISA's known exploited vulnerabilities catalog, version 2026.09.16, entry for CVE-2026-87886 — added 2026-09-16, due 2026-09-19, flagged for forensic triage — and the alert published the same day, which is where the FCEB sentence comes from; the comparison with the Cisco Identity Services Engine flaw (CVE-2026-76460) comes from the neighbouring entry, added the same day with the same deadline. Three: directive BOD 26-04, dated 10 June 2026, source of the literal definition of "& forensic triage" and of the deadline table by exposure, catalog status, automation and impact. Four: the "Acronis Backup plugin for cPanel & WHM" manual (May 2026 revision, official Acronis PDF), source of the root installation instructions, the repository registration for updates via yum or apt, the sentence on who may manage backups, and the index of download and recovery operations. Five: cPanel's documentation on account creation in WHM, for the UIDs and GIDs between 1000 and 60000. Six: The Hacker News coverage of 2026-09-16, source of the 1.9.3 HF3 release note and the Acronis spokesperson's reply. What is our opinion is stated as such: that a local CVE's priority depends on how many users the machine has, that the backup agent is the most privileged and least watched process on a server, and the order of the six checks. Nobody has published indicators of compromise for this flaw; the triage list is ours, not the vendor's.