Input Critical security updates need technical details

[Fede Marsell]

Server operating system version

AlmaLinux 8

Plesk version and microupdate number

18.0.80#4

Hello,

I don't think the current way of communicating critical security updates is sufficient for system administrators.

For Plesk Obsidian 18.0.80 Update 4, the only information currently available is:

Plesk Obsidian 18.0.80 Update 4 — 24 August 2026
This update addresses a critical security issue. We strongly recommend that you apply it as soon as possible.
Note: More details to follow shortly.

Of course, if Plesk recommends applying a critical security update as soon as possible, we will do so. The problem is what comes after applying the update.

As system administrators, we need to know what vulnerability we are dealing with. Without any technical information about the security issue, it is impossible to determine whether a server may have been exposed or compromised before the patch was installed.

We don't necessarily need a PoC or information that could facilitate exploitation before most systems have been patched. But we do need, at a minimum, enough information to understand the nature and impact of the vulnerability: affected component, attack vector, whether authentication is required, required privileges, possible impact, affected versions and, when available, the corresponding CVE.

Most importantly, we need to know what should be reviewed on systems that were running a vulnerable version.

Installing the patch prevents future exploitation, but it does not tell us whether the vulnerability was already exploited.

If this is considered a critical security issue, administrators need enough information to answer two different questions:

1. Is my server protected now?
2. Was my server compromised before I installed the update?

Update 4 allows us to answer the first question by installing it. With the information currently published, we have no way to answer the second.

I understand that some technical details may need to remain temporarily undisclosed while customers update their systems. However, there should be a security advisory providing administrators with actionable information as soon as reasonably possible.

"Critical security issue" alone is simply not enough information to properly manage a production server.

Regards,

Fede,

 

[hschramm]

With this information "But we do need, at a minimum, enough information to understand the nature and impact of the vulnerability: affected component, attack vector, whether authentication is required, required privileges, possible impact, affected versions and, when available, the corresponding CVE." put out it is only a blink of an eye someone came up with a exploit and sets the hard working administrators under more pressure. there are companies that have more than one server to update...

 

[Doost]

The CVEs have since been released on the Plesk Support site, but what is concerning, is that CVE-2026-65647 mentions that Plesk Migrator 2.36.0 must be installed to patch it.
The reason this is concerning, is because 2.35.0 is indicated everywhere as the latest available version, we cannot update to the seemingly non-existent 2.36.0.

 

[Hangover2]

Extensions are rolled-out step by step over the whole Plesk universe. Even a search for extension updates does very often not help. In this case I would uninstall it first to be on the safe side.

 

[Fede Marsell]

With this information "But we do need, at a minimum, enough information to understand the nature and impact of the vulnerability: affected component, attack vector, whether authentication is required, required privileges, possible impact, affected versions and, when available, the corresponding CVE." put out it is only a blink of an eye someone came up with a exploit and sets the hard working administrators under more pressure. there are companies that have more than one server to update...

I understand your point, and I agree that publishing full technical details or a PoC immediately could make exploitation easier while many servers are still unpatched.

But I think there is a reasonable middle ground between publishing an exploit and simply saying "critical security issue".

 

[Fede Marsell]

The CVEs have since been released on the Plesk Support site, but what is concerning, is that CVE-2026-65647 mentions that Plesk Migrator 2.36.0 must be installed to patch it.
The reason this is concerning, is because 2.35.0 is indicated everywhere as the latest available version, we cannot update to the seemingly non-existent 2.36.0.

Thanks for pointing this out.

However, these vulnerabilities do not seem to be related to the critical security issue addressed by Plesk Obsidian 18.0.80 Update 4. As far as I can see, Update 4 still has no associated CVE or technical information explaining what vulnerability it actually fixes.

There is another issue here as well: I cannot find any mention of these critical extension vulnerabilities or the required Migrator/Site Import updates in the official Plesk changelog.

In fact, I only became aware of CVE-2026-65647 thanks to your post.

So I'm honestly not sure how Plesk is communicating security issues of this severity to administrators. If a vulnerability can potentially lead to root-level code execution and requires a specific extension update, I would expect it to be clearly communicated through the official changelog or another prominent security notification.

As it stands, the official changelog makes no mention of these vulnerabilities (https://docs.plesk.com/release-notes/obsidian/change-log/), while the critical vulnerability supposedly fixed by Update 4 remains unidentified.

 

[Fede Marsell]

Extensions are rolled-out step by step over the whole Plesk universe. Even a search for extension updates does very often not help. In this case I would uninstall it first to be on the safe side.

Yes, I agree. If the patched extension version is not yet available on a particular server, uninstalling the affected extension temporarily seems like the safest option if it is not needed.

The important point, though, is that these are separate security issues from the critical vulnerability addressed by Plesk Obsidian 18.0.80 Update 4.

Updating Plesk to 18.0.80 Update 4 does not fix the vulnerabilities in Plesk Migrator or Site Import. Those vulnerabilities require the affected extensions themselves to be updated to the patched versions.

So administrators should treat them as separate issues: install Update 4 to address its still-undisclosed critical security issue, and separately check and update (or temporarily uninstall) the vulnerable Migrator and Site Import extensions.

 

[Doost]

The CVEs are listed on Plesk's Support site, but you need to dig a bit to find them:

https://support.plesk.com/hc/en-us/articles/42877023875351-Vulnerability-CVE-2026-65646-in-Plesk-s-DNS-zone-management-functionality

https://support.plesk.com/hc/en-us/articles/42844242102679-Vulnerability-CVE-2026-65642-in-Plesk-s-database-management-interface

The Site Import and Plesk Migrator CVE is also listed here:

https://support.plesk.com/hc/en-us/articles/42871001389207-Vulnerability-CVE-2026-65647-in-Plesk-s-Site-Import-and-Migrator-extensions

The update for the Migrator extension is also still not available, WebPros really isn't handling this well in general if you ask me.

 

[Fede Marsell]

And the last one: https://support.plesk.com/hc/en-us/...5642-in-Plesk-s-database-management-interface

This one appears to be related to update 4.

 

[LinqLOL]

Kinda frustrated here. As some are mentioning here. There is an important fix in the panel migrator too. The official CVE page says that 2.36 is the latest version. I understand that updates are going in waves. But we are 24h further and still have no new version of it.

Freaking me out, because without Plesk I have enough security challenges already.

 

[nmdpa3]

We just received a pre-notification about a new update that will be released tomorrow to address another newly discovered vulnerability. It appears Plesk has started providing advance notice of these security updates.

I believe you have to subscribe to these notifications somewhere on the Plesk website, although I don’t recall exactly where the subscription setting is located.

 

[TorbHo]

I just noticed that when I check for new updates, none are shown.
However, if I run the update manually, Plesk updates to 18.0.80 Update #5.

Is this the security update we've been waiting for?

 

[Hangover2]

@TorbHo Yes it is: Plesk Obsidian 18.0.80 Update 5

 

[danim]

Adding a data point to this thread. We had a full compromise on a box running 18.0.79 Update #8 early today (27 Aug) tht innjected a malicious payload into index.php across 18 hosted sites, in a matter of seconds. So fully automated.

Worth noting: the admin account had a strong password, and there were no API keys in use on this server — so nothing suggests a leaked credential or key.

Patched to 18.0.80 Update #5 since.
Sharing mainly because this ties into the thread's point — without any pre-existing IOCs or CVE details, there was no way to check before patching whether we'd already been hit.

 

[Hangover2]

Let's see if Plesk will provide any helpful information soon about the attack vector.

 

[Doost]

Let's see if Plesk will provide any helpful information soon about the attack vector.

It is available here:

https://support.plesk.com/hc/en-us/articles/42968165026967-CVE-2026-67394-Vulnerability-in-Plesk-allows-privilege-escalation-to-root

 

[Tobias Sorensson]

Adding a data point to this thread. We had a full compromise on a box running 18.0.79 Update #8 early today (27 Aug) tht innjected a malicious payload into index.php across 18 hosted sites, in a matter of seconds. So fully automated.

Worth noting: the admin account had a strong password, and there were no API keys in use on this server — so nothing suggests a leaked credential or key.

Patched to 18.0.80 Update #5 since.
Sharing mainly because this ties into the thread's point — without any pre-existing IOCs or CVE details, there was no way to check before patching whether we'd already been hit.

how did you find this?

 

[danim]

how did you find this?

Sites started throwing 500 errors, which is what triggered the investigation. Once we started digging in, we found the injected require in index.php on the affected sites and traced it back through the panel/File Manager activity — which showed the payload being dropped and the injection script running. Cross-checking that against the login logs showed the foreign IP right before the injection happened.

So honestly, we got lucky — the open_basedir collision breaking the injection (and taking the sites down) is what surfaced this quickly. If the payload had worked cleanly, we may not have noticed for a while, since there were no alerts or IOCs to check against beforehand.