CVE-2026-64639 is a database cloning privilege escalation in Plesk that lets a low-privilege reseller or customer execute code as the database server administrator. The CVSS 9.3 score measures technical severity but completely misses the real danger: this is a catastrophic tenant isolation failure, not merely code execution. When a malicious hosting customer escapes their container into the database service account, they're not compromising one site — they're positioning themselves inside the infrastructure layer that holds every other customer's data on that host. One compromised tenant gets privileged access to the shared data store that defines trust for the entire server.
The version matrix tells a story analysts are underreading. The fix spans two releases — 18.0.79.6 AND 18.0.80.2 — which indicates either an incomplete initial patch or a rollback due to regressions. Either scenario extends the exploitation window. If you patched to 18.0.79.6 and stopped, you may still have exposure. The patching sequence is diagnostic evidence that the remediation touched brittle code handling privilege transitions — the exact kind of forgotten logic that accumulates in mature control panels.
This vulnerability is the third or fourth database cloning privilege escalation in major hosting control panels in five years. The pattern recurs because the architectural knowledge to build safe multi-tenant database workflows exists but isn't economically incentivized. Feature velocity wins over security hygiene in a market where switching panels is expensive and customers tolerate risk they shouldn't.
Priority actions: First, identify every customer who had database cloning access during the window between vulnerable versions and the patched releases — assume compromise for anyone in that window, regardless of whether exploitation has been detected. Second, check whether 18.0.80.2 actually replaces the vulnerable logic or merely adds guards around it; if it's guards, the underlying code persists and warrants deeper review. Third, examine MySQL process execution traces from the preceding 90 days — spawned shells, modified UDF tables, or unexpected write targets would indicate someone already exploited this. If your logging infrastructure can't answer that question, assume it may have been exploited already; the service account you'd need to query for evidence is the same one that may be compromised. Patching alone may not be sufficient — post-patch forensics are warranted for any hosting environment where customers had database cloning access.