Plesk CVE-2026-68487

Requires an authenticated Plesk customer account (PR:L) with access to the Backup Manager feature; the attacker crafts a malicious backup header exploiting the fact that it is unsigned/unvalidated, so no signature or integrity check blocks the traversal. Exploitation is network-reachable with low complexity and no user interaction (AV:N/AC:L/UI:N), meaning any valid low-privileged customer can trigger it against a default Plesk installation. The limiting factor is the need for a working login on the panel and access to the backup functionality - it is not exploitable by fully unauthenticated attackers.

The supplied CVSS 3.0 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 9.9) reflects a genuinely severe issue: network-reachable, low attack complexity, only low privileges (a normal customer account, which is the expected trust boundary in multi-tenant hosting), no user interaction, and a scope change because a customer breaks out to root/system control with full C/I/A impact. Arbitrary file write as root is a near-certain path to code execution (e.g., writing cron jobs, systemd units, SSH keys, or web shells), so the technical impact is total. Exploitation is not automatable in the mass-scan sense because it requires a valid customer login on the target panel, which tempers spray-and-pray but is trivial in shared/reseller hosting where accounts are sold openly. No EPSS score, KEV listing, or POC status was provided, so real-world exploitation frequency is unknown; the 9.9 rating is well justified by impact but current active-exploitation signals are absent from the input.

An attacker purchases or already holds an ordinary Plesk customer account on a shared-hosting server, then invokes the Backup Manager with a crafted unsigned backup header whose path field traverses out of the backup directory. The root-privileged backup process writes an attacker-controlled file to a sensitive location (e.g., a cron job or SSH authorized_keys), yielding root code execution and full compromise of every tenant on the box. No POC is identified in the provided data, but the vendor has described the unsigned-header root cause.