Plesk CVE-2026-67394

The attacker must hold an authenticated Plesk customer or reseller account (PR:L) that either already has shell access enabled or has the subscription/plan permission allowing them to change their own shell access - that shell-access feature is the exact precondition (matching the AT:P attack requirement). It is not exploitable by anonymous/unauthenticated users, and accounts explicitly denied shell access and denied the right to modify their shell setting cannot trigger it. Limiting factors: requires a valid low-privileged panel account on a Plesk for Linux host in the vulnerable range (18.0.34 before 18.0.79.9/18.0.80.5); Windows Plesk and accounts with shell fully locked down by the provider are out of scope.

This is a genuine priority rather than an inflated CVSS number: it yields full root on a multi-tenant hosting server and destroys the customer/host trust boundary that shared hosting depends on, with high impact to confidentiality, integrity, and availability across the system and subsequent (SC/SI/SA:H) systems. The vendor CVSS 4.0 vector shows AV:N/AC:L/AT:P/PR:L/UI:N, meaning a low-privileged but authenticated tenant, no user interaction, and some attack requirement (AT:P) - consistent with needing shell access to be enabled. One signal to reconcile: the description labels this 'local privilege escalation' while the vector uses AV:N, so treat the true entry as an authenticated tenant who already reaches the box (typically over SSH/panel) rather than a purely remote, unauthenticated attacker - verify the intended vector with the vendor advisory. No EPSS score, no KEV listing, and no known public POC lower the immediacy of mass exploitation, but the low bar for any hosting provider means even a mid-sized regional hosting operator should treat this as urgent, because any reseller or customer account is a candidate attacker. Absence of EPSS/POC data is a gap, not evidence of low risk.

An attacker who controls or purchases a low-privileged Plesk customer or reseller account enables (or already has) shell access, then supplies a maliciously crafted value into the shell-access configuration that the root-level Plesk component executes, running attacker commands as root. From there they read or tamper with every other customer's data on the shared server and establish persistence. No public POC is identified at time of analysis, and the low attack complexity means a working exploit would be reliable once the shell-access precondition is met.