Acronis Patches CVE-2026-87886: In-the-Wild Exploit in cPanel Plugin

Acronis released urgent patches on September 15, 2026, for a local privilege escalation vulnerability in its Backup plugin for cPanel & WHM and its extension for Plesk. The flaw, tracked as CVE-2026-87886 with a CVSS 7.8 score per the vendor advisory, has already been exploited in targeted attacks against cPanel & WHM deployments, forcing administrators to immediately verify installed builds—a process complicated by a non-trivial operational wrinkle: a choice between two update paths with different backend prerequisites.

The Flaw: From Faulty File Permissions to Total Local Control

The vulnerability resides in insecure file permissions in the Acronis plugin code for cPanel & WHM and the extension for Plesk. An attacker who has already gained local access with limited privileges—typically via a compromised user account—can exploit these permissions to elevate their rights on the system without requiring interaction from the legitimate user.

The condition is particularly insidious in shared hosting environments, where the compromise of a single customer account can become the starting point for lateral movement within the server. The backup plugin, by its nature, operates with elevated privileges to access user data: this architecture makes it a prime target for those seeking to escalate permissions.

According to sources, the vulnerability is rated CVSS 7.8 by Acronis, placing it in the upper tier of the scale without reaching maximum criticality. The distinction matters: the local nature of the flaw requires an initial access prerequisite that reduces the attack surface compared to a remotely exploitable vulnerability, but does not diminish the danger in multi-tenant environments where user account compromise is a recurring event.

Attacks Confirmed, But on Uncertain Ground

Acronis communicated that exploitation has been detected in the wild. According to SecurityWeek, which reports a direct quote from the vendor advisory:

"Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments"

Help Net Security and BleepingComputer converge on the same data point, with a crucial clarification added by the latter: the assessment is based on "a single report from a potentially affected customer." This element, explicitly documented in the source, constitutes a structural limit of the claim: this is not a campaign observed at scale or multiple independently confirmed patterns, but a single report that Acronis deemed sufficient to declare active exploitation status.

No evidence of exploitation on Plesk deployments has emerged to date. The distinction between the two control panels is operational: although they share the same vulnerable code in the Acronis component, only the cPanel & WHM ecosystem has been the target of confirmed attacks.

The Build Maze: Why 1.9.3 Is Not Enough

The fix does not follow the linear path administrators might expect. It is not sufficient to designate "version 1.9.3" as safe: the exact build determines whether the system is vulnerable or not.

According to WindowsForum, which analyzed Acronis public data, build 1.9.3.998—technically belonging to the 1.9.3 line—remains below the remediation threshold. The fix arrives with build 1.9.3.1021, distributed as hotfix 1.9.3 HF3. For the Plesk extension, the threshold is build 1.8.11.638.

An additional layer of complexity exists. A version 1.9.4 build 1022 includes the fix but introduces different backend prerequisites: it requires Acronis Cyber Cloud and the protection agent at version C26.08, versus the C26.02 sufficient for 1.9.3.1021. Administrators with legacy infrastructure or backend update constraints face a forced choice: stay on the 1.9.3 line with minimal operational impact, or adopt 1.9.4 with a broader upgrade cycle for the underlying platform.

This articulation—builds rather than marketing versions, backend prerequisites that bifurcate paths—is typical of enterprise software but rarely communicated with the clarity needed by operators who must act urgently. The concrete risk is that an administrator updates to "1.9.3" without verifying the build, remaining exposed with the false sense of having fixed the problem.

What to Do Now

• Verify the exact installed build of the Acronis plugin for cPanel & WHM or the Plesk extension: the minimum security thresholds are 1.9.3.1021 and 1.8.11.638, respectively
• If the Acronis Cyber Cloud backend is at version C26.02, apply the 1.9.3 HF3 path (build 1021); if it is already at C26.08 or higher, evaluate moving to 1.9.4 build 1022
• Recognize that Acronis has not published indicators of compromise or technical exploit details, making retrospective signature-based threat hunting impossible: verifying the installed build is the only concrete action available
• For cPanel & WHM deployments, consider verification a priority given they constitute the only target with confirmed exploitation; for Plesk, maintain the normal patching cycle without additional alarm

The Operational Void Without IoCs

The absence of published indicators of compromise from Acronis leaves administrators in a position of information asymmetry. It is not possible to determine if a server was compromised in the past via this flaw, nor to build detection rules for future intrusions. The defensive strategy reduces to preventive patching, without the possibility of an evidence-based remediation phase.

This communication choice by the vendor—common in active exploitation scenarios where disclosing technical details risks amplifying attacks—nevertheless penalizes operators managing potentially already compromised infrastructure. The only remaining certainty is the installed build: below the indicated thresholds, the system is vulnerable; above them, it is patched.

Why the Hosting Sector Is in the Crosshairs

Backup components integrated into control panels like cPanel and Plesk represent a specific attraction point for attackers in multi-tenant environments. Their function requires privileged access to data from all accounts hosted on the server, meaning a plugin compromise translates to potential cross-account exposure.

The local nature of the vulnerability does not diminish the risk for hosting providers: in a context where customer accounts are regularly compromised via stolen credentials or vulnerable applications, the step from "limited user" to "elevated privileges" via a backup component is a well-defined attack path. The confirmation of in-the-wild exploitation, even on the basis of a single report, legitimizes the assessment of this vector as actively exploited by targeted operators.

The distinction between "limited, targeted attacks" and a large-scale campaign is relevant for resource prioritization, not for the severity of the vulnerability itself. A targeted attacker who deliberately chooses high-value targets—hosting providers with hundreds or thousands of accounts—can generate impacts far greater than an automated worm striking indiscriminately.

Reading: The Invisible Build Problem

The CVE-2026-87886 case highlights a systemic fracture in security vendor communication: marketing versions ("1.9.3," "1.8.11") are perceived as sufficient by administrators, while technical reality is determined by internal builds that are often opaque or difficult to consult. In an active exploitation scenario, this opacity introduces patching latency and false security positives.

The backend prerequisite C26.02 versus C26.08 adds a further constraint that many patch management workflows are not structured to handle: fixing a vulnerability in a perimeter component forces evaluation of the underlying infrastructure state. For MSPs managing hundreds of heterogeneous deployments, this is not a technical detail but a planning variable with impact on intervention timelines.

The combination of confirmed exploitation, uncertain detection basis, and patching complexity creates a scenario where actual security depends more on operational precision than reaction speed. Updating "immediately" to the wrong version is technically possible; updating correctly requires information that vendors do not always make immediately accessible.

Sources

• https://www.securityweek.com/acronis-patches-exploited-vulnerability-in-cpanel-backup-plugin/
• https://www.helpnetsecurity.com/2026/09/16/acronis-backup-plugin-vulnerability-exploited-cve-2026-87886/
• https://www.bleepingcomputer.com/news/security/acronis-warns-of-actively-exploited-flaw-in-its-cpanel-backup-plugin/
• https://windowsforum.com/news/cve-2026-87886-acronis-cpanel-fix-is-build-1-9-3-1021.444528/
• https://podcast.securityweek.com/

Information has been verified against cited sources and updated at time of publication.

Sources