Why Backup Agents Deserve the Same Scrutiny as Domain Controllers
The software that can read and restore everything can also take everything. What a compromised backup agent gives an attacker, why it escapes review, and how to put it on the privileged asset list.
What a Backup Agent Actually Has
Most organisations keep a short list of systems they consider crown jewels: domain controllers, identity providers, the hypervisor management plane, the firewall manager. Backup agents rarely make that list, and yet by the criteria used to build it, they qualify on every count.
A backup agent runs with the highest privilege available on its host, because its function is to read every file, every database, and every mailbox regardless of who owns them. It holds credentials to the backup destination, which may be local storage, a network share, or a cloud repository shared across many hosts. It has a scheduled, expected, high-volume network path to that destination, which means large outbound transfers from it look normal. And it runs on more systems than almost any other privileged component, because everything gets backed up.
The September 2026 exploitation of CVE-2026-87886, a local privilege escalation in the Acronis Backup plugin for cPanel & WHM, is a reminder that this combination is a target. The flaw itself was an insecure file permission, a modest bug class. Its impact was not modest, because of what the plugin could reach once compromised.
What an Attacker Does With One
Three outcomes follow from controlling a backup agent, and each is worse than the usual privilege escalation story.
The first is quiet data theft. The agent can read everything, and it has a legitimate channel to move large volumes of data off the host. An attacker who can influence what the agent backs up, or where it sends the result, does not need to build their own exfiltration path. On a shared hosting server, that means every customer's site files, databases, and mail in one pass.
The second is destroying the safety net before an attack. Ransomware operators have learned that encryption is only profitable if recovery is impossible, so deleting or corrupting backups is a standard step before deployment. Reaching the backup agent, and through it the backup storage credentials, is the most direct way to do that. The pattern is the same one that drives ransomware operators to encrypt at the hypervisor instead of the guest: go where one action affects everything.
The third is durable persistence. The agent is trusted, runs as root, starts on boot, and is excluded from a great deal of monitoring because its behaviour is expected to be intrusive. A modification to what it executes survives reboots and often survives incident response that focuses on web shells and user accounts.
Why Backup Agents Escape Scrutiny
Several habits keep backup software off the privileged asset list.
It is installed once and forgotten. Backup agents are deployed as part of a server build and then judged only by whether the jobs succeed. Nobody reviews the agent's version during a security assessment because it is filed under operations, not security.
It is assumed to be updated by the vendor. Many backup products manage their own updates through a central console, and administrators reasonably assume that a critical fix will arrive on its own. That assumption breaks for plugins and integrations that sit outside the main update path, which is exactly where the Acronis flaw lived. The fixed build was available for four days before the advisory, and the version label did not change.
It is not thought of as an attack surface. Because a backup agent listens on nothing public and accepts no untrusted input from the network, it fails the mental test for exposure. But on any multi-user system, local input is untrusted input. A plugin that reads files a tenant can write is exposed in the way that matters, as the explanation of why insecure file permissions let a low-privileged user become root sets out.
Putting Backup Infrastructure on the Privileged List
Treating a backup agent as a privileged asset changes a handful of practices.
Inventory it with the same rigour as identity systems. Every host that runs an agent, every plugin or extension attached to it, and the exact build of each should be recorded and reviewed on a fixed cadence. Vendor advisories and CISA KEV additions for the product should route to the same people who handle advisories for firewalls and hypervisors, on the same timelines.
Scope its credentials. The agent on one host should not hold credentials that can delete backups belonging to every other host. Where the backup product supports per-host or per-tenant storage credentials, use them. Where it supports immutable or write-once storage that the agent cannot purge, that control is the single most valuable defence against the second outcome above, and it is worth more than any amount of detection.
Monitor its behaviour, not just its job status. Alert on the agent spawning shells or interpreters, on changes to the files and permissions in its installation directories, and on backup destinations or schedules changing outside your change process. These are low-volume events on a properly run host, which makes them high-signal.
Harden the hosts it runs on. On multi-tenant servers in particular, the practical measures for how to harden a shared hosting server against local privilege escalation are what keep a tenant from reaching the agent in the first place. Restricted shells, non-executable upload directories, and regular permission audits of privileged paths all raise the cost of the local foothold that a bug like CVE-2026-87886 requires.
The Planning Question
The question to put to an infrastructure team is simple: if the backup agent on your busiest server was fully compromised tonight, what could the attacker read, what could they delete, and how would you know? If the honest answers are everything, everything, and probably not until the ransom note, the agent belongs on the privileged list and the controls above belong on the roadmap.
The Acronis case will be patched and forgotten within a month. The structural fact it illustrates will not change: the software that can read and restore everything is, by definition, the software that can take everything, and it deserves the same defensive attention as any other system with that reach.