Plesk CVE-2026-65642

Exploitation requires a valid Plesk customer account on the targeted server - any standard tenant account with access to the database management interface is sufficient, with no elevated role or administrative privilege needed. The attacker and victim must be co-hosted on the same Plesk server instance; this is not a remotely exploitable flaw against arbitrary internet targets. The following factors limit exploitation scope: authentication as a Plesk customer is mandatory (the CVSS 4.0 PR:L metric confirms this - anonymous internet exploitation is not possible); only databases managed through the specific database management interface are reachable, not file system or mail data; and both the attacker's and victim's databases must reside on the same physical Plesk installation.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N) is internally consistent with the vulnerability description: network-accessible, low complexity, requiring only a standard customer account, yielding high confidentiality and integrity impact with no availability or subsequent-system component. No EPSS score was included in the available intelligence, so exploitation probability cannot be quantified. The vulnerability is absent from CISA KEV, and no public exploit code has been identified, which moderates urgency relative to a KEV-confirmed flaw. However, the practical risk to shared hosting operators is elevated beyond what raw CVSS alone conveys: a single compromised or malicious customer account becomes a vector for full cross-tenant database exposure on the entire server, meaning a hosting provider with hundreds of customers per node faces disproportionate blast radius. The CVSS vector and description are fully consistent - no conflicts requiring vendor verification were identified.

An authenticated Plesk customer accesses the database management interface and manipulates the database object identifier in a request - by incrementing or enumerating values - to reference a database registered to a different customer on the same server. The application, lacking an ownership check, returns the target database contents or executes modification operations as instructed. No public exploit code has been identified, but the low attack complexity and predictable nature of sequential database identifiers make independent exploitation feasible for any technically capable hosting customer.