Remediating the Exploited Acronis Backup Plugin Across a Shared-Hosting Fleet

AI Usage (85%)

Acronis shipped a fix for a vulnerability in its cPanel and Plesk backup plugin, and reporting dated 2026-09-16 states the flaw was exploited in targeted attacks. This post walks through remediating that exposure across a shared-hosting fleet: confirming which servers actually have the Acronis backup plugin installed, patching in the right order, rotating backup storage credentials, and hunting for post-exploitation persistence before declaring a host clean.

If you run hosting, the headline is the least useful part. The operational question underneath it is: which servers have this extension, is it already patched, and did anyone touch it before I patched it? I've cleaned up enough control-panel incidents to have a strong opinion about the order of operations here — and the order is usually the part people get wrong.

What the Acronis cPanel and Plesk Reporting Confirms, and What It Leaves Open

Confirmed by the public reporting

The three reports dated 2026-09-16 agree on a small set of facts:

Acronis released a fix for a vulnerability in its backup plugin for cPanel and Plesk.
The vulnerability was exploited in targeted attacks, not sprayed opportunistically.
The extension runs inside a widely deployed control panel used heavily by small and mid-sized hosts.

That is the entire confirmed surface. It is thin, and it should be treated as thin.

What the reporting does not establish

In the coverage I read, there's no CVE identifier, no published affected version range, no root-cause detail (authentication bypass, path traversal, command injection, and unsafe deserialization are all consistent with the headline and none is confirmed), no indicators of compromise, and no victim count. I am not going to guess at any of them.

⚠️

Absence of a CVE does not mean absence of exposure. A vendor can ship a silent fix, and an extension bug that runs with panel privileges does not need a CVE to ruin a host. Patch on the vendor's word, not on the presence of a public identifier.

Why a Control-Panel Backup Plugin Is a Host-Level Attack Surface

The trust boundary: panel privileges, not tenant privileges

A backup extension is not a blog plugin. It lives inside the control panel process, runs with the panel's privileges, enumerates every tenant's document roots to build archives, can restore over those roots, and stores credentials for whatever remote target the backups go to.

So the trust boundary isn't "one site" or "one account." It's the host. Anyone who gets code execution or a file write through this extension doesn't need to escalate much — the extension already has, by design, the access escalation would have earned them.

Blast radius of an exploited backup extension

Scope	What an attacker reaches	Why it matters
Single tenant site	That site's files and database	Normal shared-host incident, one customer
Single panel account	All sites under that account, plus its mail and cron	Billing and reputation hit, contained
Entire panel server	Every account, every document root, panel auth data	Full host rebuild conversation
Fleet-wide, if storage keys are shared	Every backup target reachable from those keys	Exfiltration and, worse, destructive restore

That last row is the one people skip. If you provisioned one storage account and reused the key across forty servers because it was convenient, a single compromised extension is a fleet event, not a host event.

Inventorying Which Servers Actually Have the Acronis Extension

Start with "what is installed." Forensics can wait.

cPanel host checks

On the cPanel boxes I've worked with, third-party panel integrations register under /var/cpanel/apps/, with the integration files living under the cPanel tree. Your layout may differ depending on how the extension was packaged, so treat this as a way to find the pattern, not a guaranteed path:

grep -rIl -i acronis /var/cpanel/apps/ 2>/dev/null
find /usr/local/cpanel -maxdepth 4 -iname '*acronis*' 2>/dev/null

The output shape you're looking for is a registration file plus an integration directory:

/var/cpanel/apps/<plugin>.conf
/usr/local/cpanel/whostmgr/docroot/cgi/<plugin>/
/usr/local/cpanel/base/frontend/jupiter/<plugin>

💪

Findings on disk are a hint, not an answer. An uninstall can leave an orphaned directory behind, and a present directory does not prove the feature is enabled. Confirm the plugin's presence and state from WHM's plugin management view before you write it into your exposure list.

Plesk host checks

Plesk is cleaner, because the CLI enumerates extensions directly:

plesk bin extension --list | grep -i acronis
plesk version

Output looks roughly like this — name, version, state:

acronis-backup     <version>    enabled

Use plesk bin extension --info <extension-id> for detail on the exact ID your install uses, and check plesk bin extension --help before assuming a subcommand exists on your build. If the extension is present but unused, plesk bin extension --disable <extension-id> is the fastest way to take it off the attack surface while you schedule the update.

Building the fleet list without SSH on every box

If you have more than a handful of servers, don't start by opening sessions. Start with the asset inventory you already pay for:

Pull the server list from your hosting automation or billing system — anything you sell as a control-panel service must be in there.
Reconcile panel versions from an external signal: the WHM and Plesk login endpoints advertise panel versions, which tells you which servers are even capable of running the affected extension.
Confirm plugin presence at the host level, because external fingerprints won't tell you whether the extension is installed.

The external signal narrows the list. The host-level check is the source of truth. Swap the order and you'll get a tidy spreadsheet and an unpatched server.

Patching the Acronis Backup Plugin Without Breaking Backups

Update the extension first, then the panel, then restart

The sequence matters because a panel package update can and will interrupt the extension's own update channel mid-flight. Update the extension first, then the panel, then restart affected services.

cPanel-shaped sequence:

## after updating the extension through its own update path or WHM
/usr/local/cpanel/scripts/upcp
/usr/local/cpanel/scripts/restartsrv_cpsrvd

Plesk-shaped sequence:

## update the extension, then the panel
plesk bin extension --update <extension-id>
plesk installer update
systemctl restart sw-engine

Verify the flags against your panel version before running anything (plesk installer --help is your friend). I'm showing the shape of the sequence, not a build-independent recipe.

What breaks if you skip a step

Action	If you skip it
Patch now, outside the maintenance window	Extension stays exploitable for days while a public report circulates
Rotate backup storage credentials after patching	Any key already read from the plugin config still works for the attacker
Check for prior compromise before declaring done	You patch a host that is already someone else's persistence
Verify the extension actually restarted	Old code stays resident; you believe you're fixed and are not
Confirm storage targets still reachable post-rotation	You trade a security fix for silent backup failures

Staged rollout: why you should not patch the whole fleet at once

Patching an entire fleet at once, inside a backup window, is how a security fix becomes an availability incident. Backups are I/O- and network-heavy; extension restarts mid-run produce partial archives, and you find out about partial archives six months later when you actually need to restore. Roll in waves, and check that the first wave's backup jobs completed before starting the second.

Hunting for Post-Exploitation on an Affected Host

Account-level and filesystem tells

The signals that have paid off for me on panel compromises are boring: files that shouldn't exist, users that shouldn't exist, cron that nobody wrote.

## files written into tenant roots in the exposure window
find /home/*/public_html -type f -newermt "2026-09-01" ! -name '*.log' -printf '%T@ %p\n' | sort -n | head -40

## any change inside the panel integration directory
find /usr/local/cpanel -path '*acronis*' -newermt "2026-09-01" -ls 2>/dev/null

## cron entries per account
for f in /var/spool/cron/*; do echo "== $f"; cat "$f"; done

Output shape to look for:

2026-09-03 02:14:51 /home/siteA/public_html/wp-content/uploads/2026/09/x.php
2026-09-03 02:15:09 /home/siteA/public_html/.well-known/index.php

Two files, ninety seconds apart, in directories that have nothing to do with each other, is a pattern. One file is noise. Compare against a baseline if you have one — and if you don't, that gap is the real finding.

Credential exposure in the plugin config

Assume any remote backup target configured in the extension is known to the attacker. Don't print those credentials into a ticket, a chat, or a shell history while you investigate. Enumerate the targets, rotate the keys at the storage provider, update the plugin config with the new values, then run a verification backup. Rotation is mandatory after a suspected compromise, not optional hygiene.

Log sources worth pulling

Source	What it tells you
Panel authentication log	Which accounts logged in, from where, when
Panel access log (HTTP)	Requests to plugin endpoints, including failed ones
System auth log	SSH, sudo, and service-level access
Web access logs per domain	Exploit attempts and dropped files

The correlation that matters is a panel login followed by a write into a tenant directory that account should not own:

grep -i "SUCCESS" /usr/local/cpanel/logs/login_log | grep "2026-09-0"
grep -i "acronis" /usr/local/cpanel/logs/access_log | tail -50

If you find a login at 02:14:02 and a new PHP file at 02:14:51, you are no longer hypothesizing. You are documenting.

What to Fix First, and What the Typical Response Gets Wrong

Priority order after confirming exposure

Confirm exposure. Does the extension exist on this host? Yes or no, without guessing.
Patch it. Extension, then panel, then restart, then verify.
Rotate backup storage credentials. Immediately after patching, before any deeper investigation.
Investigate. Only on hosts that were exposed.

A fleet-wide forensic sweep of hosts that never installed the extension is wasted effort, and it delays steps 2 and 3 on the hosts that matter. Tier by exposure first.

Where I part ways with the typical response

Treating the vendor patch as remediation is the most common mistake I see. Patching closes the front door; it does not remove the person already inside. If the extension was exploited on a host before you patched, the vulnerability is the least interesting thing about that host.

The second mistake is reading a quiet week after patching as proof of cleanliness. Attackers targeting a panel extension don't need to keep exploiting it — they need one successful run to plant persistence, harvest credentials, and leave. Silence after the patch is not evidence. Log review and a filesystem diff are.

Reducing Blast Radius Before the Next Control-Panel Plugin Bug

Hardening that would have helped here

Constrain the extension. If it can run with reduced privileges or be disabled outside backup windows, do that.
Restrict egress. The backup extension needs to talk to specific storage endpoints. Little else on that host does. Enforce it, don't document it.
One storage account per server. Shared backup keys turn one compromised extension into a fleet-wide credential leak.
Integrity monitoring on panel plugin directories. Hash the plugin tree at a known-good state and alert on change. This is the cheapest detection you can buy.
Staged rollouts. Already covered, but it belongs on the hardening list too, because availability is part of security.

What this class of bug says about panel extensions

Control panel extensions are supply chain, but most hosts inventory them like they inventory nothing. You know your kernel packages to the version. You probably cannot list your panel extensions without logging in and looking. That asymmetry is the actual vulnerability class here, and it will outlive this specific Acronis bug.

Inventory extensions the way you inventory packages: an owned list, versions, owners, and a review cadence. Then the next headline is a query, not a scramble.

What I Confirmed Versus What I Did Not Test

Confirmed from public reporting: Acronis shipped a fix for a vulnerability in its cPanel and Plesk backup plugin; reporting on 2026-09-16 states the flaw was exploited in targeted attacks. That is the extent of it.

Not tested, or not established: I did not have a lab host running this extension, so every command shown here is the reliable shape of the check rather than a captured transcript from an affected box. The affected version range, the root cause, any CVE identifier, and any indicators of compromise were not in the coverage I read and are unknown to me. Paths and CLI flags vary by panel version — verify before running.