Plesk CVE-2025-66430

Requires a valid, authenticated Plesk panel user account and the use of Plesk's Password-Protected Directories feature, per the vendor advisory ('allows Plesk users to gain root-level access'). It is a privilege-escalation-to-root path from within the panel rather than a pre-auth remote takeover. Limiting factors: the attacker must already possess legitimate Plesk credentials, and only Plesk 18.0 (Obsidian) servers using the affected feature are impacted - this meaningfully reduces real-world exposure compared to the unauthenticated PR:N implied by the raw CVSS vector.

This is a genuinely high-priority flaw, but the input signals conflict and must be reconciled. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.1) describes a network, low-complexity, unauthenticated issue with no availability impact. However, the vendor advisory explicitly scopes it as 'allows Plesk users to gain root-level access to a Plesk server' - i.e. a privilege-escalation chain that presupposes an existing authenticated Plesk account, which contradicts PR:N, and a root-level outcome that should imply A:H and a scope change, contradicting A:N/S:U. CVSS vector claims PR:N (unauthenticated), but the vendor description implies an authenticated Plesk user is required - verify with vendor before treating as fully unauthenticated. On exploitation likelihood, EPSS is low at 0.55% (45th percentile), there is no CISA KEV listing and no public exploit identified, so despite the 9.1 base score there is currently no evidence of active or imminent widespread exploitation. Net: treat as a high-severity, patch-soon issue (root compromise of a hosting control plane is severe) rather than a drop-everything emergency, while watching for EPSS/KEV changes once exploit details circulate.

An attacker who holds a legitimate Plesk panel user account (for example a reseller or hosting customer on a shared Plesk 18.0 server) abuses the Password-Protected Directories feature to escape the panel's access-control boundary and obtain root-level privileges on the underlying server. No public exploit code has been identified at time of analysis, so exploitation would require independent research or reverse-engineering of the patch.