15 SEP 2026 — A customer on a shared Plesk server who has nothing more than their own panel login and FTP access to their own site can turn a backup restore into root on the whole machine, according to an advisory for CVE-2026-68488. The flaw is rated 9.9. Fixes are out for the two affected Plesk for Linux release lines, and no exploitation had been reported when the flaw was made public.
On a single-tenant server that would be serious. On shared hosting, where one machine carries dozens or hundreds of unrelated customers, it breaks the promise the product exists to keep.
What the flaw is
The bug sits in Plesk's Backup Manager, in the step that restores a subscription's content. It is a time-of-check to time-of-use race involving symbolic links. The restore checks a path, and in the gap before it acts on that path, a user who controls the files can swap in a symbolic link pointing somewhere else. The restore runs with root's privileges and does not properly validate who owns what it is following, so files or directories anywhere on the system can be taken over.
The attacker needs ordinary access to the Plesk panel and FTP access to their own hosted subscription. That is exactly what every paying shared-hosting customer has. Windows installations of Plesk are not affected.
Affected versions are Plesk Obsidian for Linux 18.0.80.6 and earlier, and 18.0.79.10 and earlier. The fixes are 18.0.80.7 and 18.0.79.11. The flaw was reported by researchers Ali Mustafa and abed1526.
Races of this kind can sound too fragile to matter, since the attacker has to act in a narrow window. In practice they are often reliable. The attacker controls one side of the race, the files in their own subscription, and can trigger the restore repeatedly until the timing lands. A restore that processes many files offers many chances. Nothing about the attack requires unusual skill once the technique is known, which is why a working method tends to spread quickly after a flaw of this type is published.
Why it scores 9.9
Most privilege-escalation bugs that require a logged-in user score lower, because needing an account is a real barrier. This one scores near the top of the scale for two reasons in its vector. The privileges required are low — any customer account will do — and the scope changes, meaning the attack starts inside one security boundary, a customer's subscription, and ends in another, the server itself.
The scope change drives the rating. In our CVSS calculator, switching scope from unchanged to changed with everything else held constant is enough to make the score jump. A shared-hosting customer escalating to root is the textbook case of an attack that crosses the boundary it started in.
What shared hosting promises
The economics of shared hosting depend on isolation. A provider puts many customers on one server because each is confined to its own directory, its own processes and its own database, and cannot see or touch the others. Customers accept sharing the hardware on that condition.
A tenant-to-root flaw ends that confinement. Once one customer has root, every other site on the server is open to them, including its files, its databases, its stored credentials and the email accounts it hosts. On a server hosting a few hundred small businesses, a single malicious signup, or a single customer account compromised through a weak password, becomes a compromise of all of them.
Hosting control panels have been a recurring target this year. We reported a cPanel flaw in the EmailTrack component that also led to root on shared hosting, and Plesk's own support site lists other root-level escalation advisories carrying 2026 identifiers. The panels are attractive targets for the same reason edge appliances are. They run with the highest privileges, they face customers who are not trusted, and one bug pays out across many victims.
What hosting providers should do
Update to 18.0.80.7 or 18.0.79.11, and do it before the next routine maintenance window. The attack requires no special position, only a customer account, and on a shared server a provider cannot assume that every customer is benign.
Where an update has to wait, restricting or disabling customer-initiated restores in Backup Manager narrows the path, since the race lives in the restore step. That is an interim measure rather than a fix. Providers should also review recent restore activity and any unexpected changes to system files or ownership, because the flaw was public before every fleet could be patched.
What customers should know
If your website sits on shared Plesk hosting, the fix is your provider's to apply, not yours. It is reasonable to ask them whether it has been applied and when.
Shared hosting is cheap because the server is shared, and the isolation between customers is software, which occasionally has a hole in it. For a business whose website handles customer data, that trade-off is worth reconsidering against a virtual private server or a managed platform where no stranger has an account on the same machine.
View author profile → · Editorial policy
