Plesk Bug Lets One Hosting Customer Access Another Customer’s Database
- The Mess: Plesk has shipped a nasty multi-tenant security bug tracked as CVE-2026-65642. An authenticated user can gain unauthorized read and write access to databases belonging to other customers on the same server. Plesk published the advisory today, August 25.
This is not a simple information leak.
The vulnerable database management interface breaks the isolation that hosting providers rely on to keep customers separated. One account is supposed to see its own databases. Not everyone else’s.
With the flaw, that boundary can fail.
An attacker with a valid Plesk account could potentially view data belonging to other customers, modify database contents or delete them. That means customer records, application data, WordPress databases and other hosted information can become fair game.
And this is exactly where shared infrastructure gets uncomfortable.
A hosting server can contain dozens or hundreds of websites. They may belong to completely unrelated customers. The whole point of the control panel is to keep those environments logically separated.
CVE-2026-65642 punches a hole in that separation.
Plesk lists the affected builds as 18.0.79.7 and earlier, plus 18.0.80 through 18.0.80.3, on both Linux and Windows. The fixed builds are 18.0.79.8 and 18.0.80.4.
There is no need to dress this up.
If multiple customers share the same Plesk server, this is exactly the kind of bug administrators need to take seriously.
- The Damage: A compromised or malicious hosting account could potentially access, alter or delete another customer’s database, exposing sensitive application data or damaging entire websites.
For WordPress sites, the database can contain much more than blog posts.
User accounts. Email addresses. Configuration data. Orders. Customer information. API credentials. Plugin settings.
Change the wrong records and a website can be broken.
Change the right records and an attacker may be able to manipulate application behavior or create a path toward a larger compromise.
The important point is that the attacker does not necessarily need to compromise the hosting provider’s administrator account first. The vulnerability starts with an authenticated Plesk user.
That makes stolen hosting credentials suddenly much more valuable.
A phishing attack, reused password or compromised customer account could potentially become the starting point for attacking other tenants on the same machine.
This is why multi-tenant isolation matters.
Once it fails, “your website is on your own account” stops meaning very much.
- The Fix: Update Plesk immediately to 18.0.79.8, 18.0.80.4 or later, then review database access and logs for suspicious activity involving customer accounts.
Plesk’s official guidance is straightforward: install the update and verify that the server is running one of the fixed builds.
If the server was running a vulnerable version and hosts multiple customers, administrators should also consider whether the flaw could have been abused before patching.
A successful update fixes the vulnerability.
It does not undo unauthorized database changes that may already have happened.
Bugstoday Opinion
This is the kind of hosting bug that makes the phrase “isolated customer environment” look rather optimistic.
A customer logs into their own hosting account.
They expect to see their databases.
They should not be able to touch the databases of everyone else on the box.
That is not an exotic security requirement. That’s the basic deal.
The really annoying part is the blast radius. One vulnerable control panel can sit above a pile of completely unrelated websites. Break the isolation once and the attacker gets a much bigger playground.
Bugstoday verdict: patch Plesk now. Then check whether someone has already been browsing databases that were never theirs.
