Vulnerability CVE-2026-109618 and CVE-2026-109619 (PHP2Shell): Remote code execution in PHP shipped with Plesk

• 

  Oliver Jusinger

  October 21, 2026 23:51

  One additional finding: the outdated PHP versions reported by plesk bin php_handler --list were caused by stale handler metadata.

  Running:

  plesk bin php_handler --reread

  updated all reported versions correctly, including PHP 8.5.11 → 8.5.12.

  So the security patches had already been installed independently of Obsidian Update #4, but Plesk's handler information had not been refreshed automatically.

  This explains the confusion. I still think that during a critical security incident, the update status should be much clearer and the handler metadata should be refreshed automatically after package updates.

  1
• 

  eCom Seller

  October 21, 2026 23:56

  Any update on the state of 18.0.81#4 being available?  We've had the Plesk interface disabled on our customers' servers since the announcement.

  0
• 

  Oliver Jusinger

  October 22, 2026 00:08

  One important clarification after investigating this further:

  It turns out that the situation was almost the opposite of what I initially understood.

  • Hosted websites: Plesk PHP 8.5.12 was already installed and patched.
  • Plesk UI: Still running sw-engine with PHP 8.4.25, and Obsidian 18.0.81 Update #3. According to the security advisory, the fix for this component is still pending in Update #4.

  The outdated PHP versions shown by plesk bin php_handler --list were corrected by running:

  plesk bin php_handler --reread

  So I had taken my already patched websites offline while leaving the Plesk administration interface accessible.

  I've now temporarily stopped sw-cp-server until the remaining hotfix becomes available.

  I think the distinction between the separately updated PHP packages for hosted websites and the still-pending sw-engine fix needs to be communicated much more clearly, especially during a critical security incident.

  1
• 

  Steve Yates

  October 22, 2026 01:04

  upgrade to a supported PHP version or use a vendor that provides security backports

  …such as https://www.plesk.com/extensions/tuxcare-php/

  0
• 

  Rainer Z

  October 22, 2026 01:37 (Edited October 22, 2026 01:39)

  Panel update now available since about an hour ago with 18.0.81 #4:
  (as stated by several posters above, we need to fix a.) any PHP versions used on a hosted website = the first patches we received here and b.) plesk GUI since it's also exposed to the internet when turned on, this is available now with 18.0.81.4, here's how to install it)
  
  SSH:
  ----
  plesk installer --select-release-current --upgrade-installed-components
  plesk version | head -1
  /usr/local/psa/admin/bin/php -v | head -1
  ---
  Once that returnes version 4 (and php 8.4.27 which Obsidian uses internally), you can restart your panel:
  ----
  systemctl start sw-cp-server
  systemctl is-active sw-cp-server
  ---
  If you have tasks running (e. g. scheduled backup that take long) they might still use the olds components while running.
   

  0
• 

  Brian Essig

  October 22, 2026 01:46

  systemctl status sw-cp-server

   

  Showed that the update did not restart the panel after running it.  I had to manually restart the panel.

   

  systemctl restart sw-cp-server

  0
• 

  Andrés Pinilla

  October 22, 2026 01:48

  Thank you to the Plesk team for your quick response to these critical PHP vulnerabilities.

  We appreciate the timely fixes, clear guidance, and patches for older PHP versions—especially for applications that cannot yet be migrated.

  2
• 

  Oliver Jusinger

  October 22, 2026 01:54

  Confirmed: Plesk Obsidian 18.0.81 Update #4 installed successfully.

  • Plesk: 18.0.81.4
  • sw-engine PHP: 8.4.27
  • Hosted website PHP: already patched separately

  I've restarted sw-cp-server, and the Plesk panel is accessible again.

  Thanks to the Plesk team for providing the hotfix!

  0
• 

  Jan Niklas Schröder

  October 22, 2026 04:08

  Thanks Plesk team!

  1
• 

  Rainer Z

  October 22, 2026 12:29

  Raj Gorsia : “if I was to update just the PHP 8.X via the Plesk updater GUI - what are the chances Plesk GUI going mental and screwing up? ” :
  
  That should work perfectly fine with no issues. Just as you can have several php versions installed at the same time (e. g. try 8.5 on stagings sites but run production sites on 8.3), the Plesk Obsidian GUI uses a “separate php package”. So you can update them separately. And if all need fixing, you also NEED to update ALL of them, not just php 8.4 but also the GUI = Obsidian with “it's own php 8.4”
  
  In the 5 years since switching to plesk, we never had a single issue with the GUI with any update.  But as always in IT and medicine, even the most certain things and easiest procedures still come with a risk of something going wrong… So make sure you have working backups, know how to restore them, and tested that they actually work. 
  
  Sorry Raj, it seems you asked this 20 hours ago but I was notified of the question only just now and couldn't see it yesterday. I hope you've been able to update by now. Some of yesterday's confusion was that it was such a severe and critical vulnerability that the updates were released one by one, with several versions/components being ready a few hours earlier. So we could patch the php for your websites, while Obsidian/the Plesk GUI had not yet been patched so it was vulnerable (thats why I turned it off until the 18.0.81 #4 update was installed). 

  
   

  1
• 

  Steve Yates

  October 22, 2026 12:45

  John Beranek For an older CentOS, support gave me:

  curl -fsSL https://autoinstall.plesk.com/plesk.gpg -o /tmp/plesk.gpg
  gpg --with-fingerprint /tmp/plesk.gpg
  rpm --import /tmp/plesk.gpg

  @ all, I did find that the Plesk web GUI found no update available when using the dashboard check. plesk installer update did find and install the update to Plesk itself.

  0

Please sign in to leave a comment.