CVE-2026-67394: Vulnerability in Plesk allows privilege escalation to root

• 

  Michel vd Lingen

  August 27, 2026 12:49

  It seems that Plesk is riddled with CVE's and bugs. It's becoming a major, almost daily/weekly, task to update Plesk, or it's extensions or take appropiate measures. Sigh.
  
  It's like we do not have anything else to do nowadays. We are already very busy as it is. We do not have the time to update everything, every day/week (multiple times). This is becoming insane. 

  0
• 

  cicommerce

  August 27, 2026 13:27

  Michel vd Lingen While I agree in most parts, it is not only Plesk, it is almost everything. Linux, WordPress, probably many other systems. The reason is that AI is used for security audits and to find vulnerabilities, which always have been in every software known to mankind, more and more of these CVE's and bugs are to be expected.

  0
• 

  Michel vd Lingen

  August 28, 2026 06:59

  cicommerce Oh, thank you for explaining that to me. After working in this industry since 1999, I had somehow completely missed the fact that Linux, WordPress and basically every other piece of software can contain vulnerabilities. I also could never have predicted that AI-assisted security research would result in more vulnerabilities being discovered. Facepalm. 😉

  But seriously: that is not my point at all.

  I have absolutely no problem with vulnerabilities being discovered, CVEs being published, or security updates being released. Quite the opposite. Finding and fixing critical vulnerabilities is obviously a good thing.

  What I am increasingly fed up with is the operational burden Plesk keeps shifting onto its customers.

  When you manage well over 100 Plesk servers, it is not simply a matter of clicking "update" on one machine. Every new critical Plesk vulnerability, extension update, workaround, patch or configuration change has to be deployed, monitored and verified across the entire infrastructure. Yes, of course we automate as much of this as possible with scripts. But automation does not magically eliminate the work. Deployments still need to be checked, there are always servers that fail to update properly, extensions that behave differently, dependencies that break, or systems that require manual intervention.

  That is the actual issue.

  Considering the frankly enormous amount of money Plesk charges for its licences and associated services — with prices conveniently increasing almost every year — I think it is perfectly reasonable to expect critical security fixes, especially vulnerabilities that could potentially lead to full server compromise, to be pushed and applied automatically by Plesk wherever technically possible.

  Administrators should not repeatedly have to babysit the remediation of critical vulnerabilities in the control panel itself.

  And this is where Plesk's priorities increasingly frustrate me. Apparently there is enough development time to push surveys into Plesk installations and even distribute some silly 80s-style game, but somehow ensuring that critical security fixes are deployed automatically and reliably across customer systems remains our problem.

  That is what annoys me.

  Plesk is supposed to make managing servers easier. Yet increasingly, maintaining Plesk itself, its extensions and all the surrounding components is becoming a job of its own.

  So no, I am not surprised that software has vulnerabilities.

  I am surprised that, at Plesk's current pricing level, customers are still expected to do so much of Plesk's critical security maintenance for them.

  2
• 

  Michel vd Lingen

  August 28, 2026 07:14

  I have also submitted an idea for Plesk about these CVE's. No clue if Plesk will even take it seriously, however this is what I have submitted:
  
  Automatic deployment of critical security patches for Plesk and official Plesk components

  I would like Plesk to introduce a proper automatic emergency security patching mechanism for critical vulnerabilities affecting Plesk itself, official Plesk extensions, and components that are supplied or directly managed as part of a Plesk installation.

  This should not simply be another option for automatically installing normal Plesk updates. Critical security remediation should be treated as a separate security mechanism.

  When Plesk publishes a critical vulnerability that may result in privilege escalation, arbitrary code execution, disclosure of administrative credentials, access to other customers' data, or ultimately complete root control of a server, the corresponding security fix should be distributed and installed automatically wherever technically possible.

  The current situation places too much responsibility for urgent remediation on the customer.

  During August alone, Plesk has published a remarkable number of serious security advisories within a very short period. Several of these vulnerabilities could result in privilege escalation or complete administrative control of a server.

  For an administrator managing one, two, or perhaps five Plesk servers, urgently updating several systems may only require a limited amount of additional work.

  That changes completely when an organisation operates more than 100 Plesk servers.

  Every urgent security advisory then becomes an operational project of its own. The affected servers must be identified, updates or extension updates must be deployed, the deployment must be monitored, the result must be verified, failed installations must be investigated, and individual servers often require additional manual attention.

  Yes, this can partly be automated.

  We already use our own scripts to deploy Plesk updates, extension updates, configuration changes, and other required fixes across our infrastructure.

  However, automation does not remove the operational burden.

  Someone still has to determine exactly what must be changed, make sure that the automation performs the correct action, execute it across the infrastructure, monitor the result, verify that every server is actually protected, and investigate the systems that fail to update correctly.

  With more than 100 production Plesk servers, there are almost always exceptions.

  A server may have an update problem. An extension may fail. A package dependency may cause an issue. A repository may temporarily be unavailable. A Plesk update may encounter an unrelated existing problem. A service may not restart correctly. Whatever the reason, somebody still needs to check the result.

  This becomes especially frustrating when security advisories occur almost weekly, and occasionally several times within the same week.

  This is not merely a request for convenience.

  It is a security issue.

  The longer it takes an administrator to deploy a critical fix across an infrastructure, the longer affected servers remain exposed. Human intervention and customer specific deployment processes unnecessarily increase the time between Plesk releasing a fix and the server actually being protected.

  For vulnerabilities that can result in root access or complete compromise of a shared hosting server, reducing that time should be a priority for Plesk as well.

  Plesk knows which versions are affected.

  Plesk knows which extensions are installed.

  Plesk knows which patched versions are required.

  Plesk controls the update infrastructure for its own product and official extensions.

  Therefore Plesk is also in the best possible position to distribute urgent security remediation automatically.

  What I would like to see

  1. A dedicated emergency security update mechanism for critical Plesk vulnerabilities.
  2. Critical security fixes for Plesk itself should be installed automatically on supported installations whenever this can be done safely.
  3. Critical fixes for official Plesk extensions should also be installed automatically when those extensions are installed and affected.
  4. Components supplied or directly managed by Plesk should be included where Plesk is able to provide or trigger the required security update.
  5. Emergency security updates should be independent from the administrator's normal update schedule. An administrator choosing a conservative schedule for regular feature or maintenance updates should not mean that a critical root vulnerability remains unpatched.
  6. Wherever possible, Plesk should distribute a minimal security fix instead of requiring a larger unrelated product update solely to remediate one vulnerability.
  7. Plesk should automatically verify whether the security fix was successfully installed.
  8. If installation fails, Plesk should retry where appropriate and clearly notify the administrator that a specific server still requires attention.
  9. Administrators should receive a clear report after remediation showing what vulnerability was addressed, what component was changed, when the fix was installed, and whether any further action is required.
  10. Organisations that deliberately require full manual control should be able to disable automatic emergency remediation, but secure automatic behaviour should be the sensible default.

  The objective should be simple.

  When Plesk discovers and fixes a vulnerability that could result in complete compromise of a Plesk server, customers should not have to start an urgent deployment project across their entire infrastructure.

  Plesk should protect the affected installations automatically and inform the administrator afterwards.

  This becomes even more relevant considering the positioning and pricing of Plesk.

  Plesk is not marketed or priced as a low cost control panel for hobby servers. It is a professional commercial product used by hosting companies and other organisations to manage production infrastructure.

  Licence costs are substantial and have increased considerably over the years. With that level of commercial positioning, customers should also be able to expect a corresponding level of operational security service.

  Critical remediation of vulnerabilities in Plesk's own software should, in my opinion, be part of that service.

  It is also difficult to understand the current priorities from a customer's perspective.

  Plesk is technically capable of proactively pushing surveys and other content into Plesk installations. Recently, even an unsolicited 80s style game was promoted through the product.

  Apparently there is infrastructure, development capacity, and product logic available to proactively deliver such things to Plesk servers.

  If Plesk can proactively deliver surveys, promotional content, and entertainment features, surely it should also be possible to build a robust mechanism that proactively protects those same servers when a critical security vulnerability is discovered.

  I would much rather see development effort invested in making critical security maintenance almost invisible to the administrator.

  That would provide real value.

  For us, maintaining Plesk should not increasingly become a separate operational workload on top of maintaining the servers themselves.

  The purpose of a professional server management platform should be to reduce administrative work, not repeatedly create urgent additional work because administrators have to remediate vulnerabilities in the management platform itself.

  Again, the problem is not that vulnerabilities are discovered.

  Vulnerabilities exist in software and finding and fixing them is important.

  The problem is the remediation model.

  For critical vulnerabilities in Plesk and its official components, especially vulnerabilities capable of leading to root access or complete server compromise, Plesk should take responsibility for getting the security fix onto affected systems as quickly, safely, and automatically as possible.

  For customers managing a large Plesk infrastructure, this would be a substantial improvement in both security and operational efficiency.

  Considering the severity and frequency of the recent vulnerabilities, I believe this should be treated as a security priority rather than an ordinary feature request.

  1

Please sign in to leave a comment.