Plesk EUVD-2026-57273

Exploitation requires an authenticated low-privileged Plesk account - specifically a customer or reseller role - and the ability to invoke the database cloning feature; it is not usable by a fully anonymous outsider despite the vector's PR:N. The affected server must run Plesk in the vulnerable range (18.0.52-18.0.79.6, or 18.0.80.0-18.0.80.2) with database provisioning available to tenants, which is the norm on shared/multi-tenant hosting. The limiting factors are the need for a valid tenant login and access to the cloning function; there is no user-interaction or special client-side requirement (UI:N), and attack complexity is low (AC:L). Note the discrepancy: the CVSS vector states PR:N while the description mandates a low-privileged user - verify the true privilege prerequisite with the vendor.

The vendor rates this 9.3 Critical via CVSS 4.0 (AV:N/AC:L/AT:N/PR:N/UI:N with high confidentiality, integrity and availability impact and no scope change to subsequent systems), which signals easy, low-complexity network exploitation with total impact on the vulnerable system. However, there is an internal inconsistency that must be flagged: the vector encodes PR:N (no privileges required) while the description explicitly requires a 'low-privileged user (customer, reseller)' - i.e. an authenticated panel account. Treating this as PR:L is more faithful to the description and materially lowers the practical attacker barrier only slightly, since Plesk customer/reseller accounts are cheap to obtain on shared/commercial hosting. No EPSS score, SSVC decision, KEV entry, or public POC was provided, so exploitation appears theoretical for now; the real priority driver is that any tenant on a multi-tenant Plesk server can pivot to DB-admin RCE, which is a serious isolation break for hosting providers. Net: high-priority patch for any shared-hosting deployment, but the 'unauthenticated' framing implied by PR:N should not be taken at face value.

An attacker purchases or already controls a low-privileged Plesk customer or reseller account on a shared hosting server, prepares a database whose objects carry attacker-controlled definitions, and invokes the database cloning function. The flawed cloning process executes that content under the database server administrator identity, granting the attacker arbitrary code execution in the DB admin context and access to other tenants' data. No public POC has been identified, but the low attack complexity makes weaponization straightforward for anyone with a valid panel account.