Plesk has had a busy May 2026 run, and hosting admins should treat it as more than a routine panel refresh. The current Plesk Obsidian changelog lists security improvements in the May 18 and May 19 updates, a Linux-side nginx and sw-cp-server component update, PHP branch updates, WP Toolkit security-risk changes, and an SSH Terminal extension update that addresses a Go compiler CVE.
This is the kind of control-panel maintenance that can quietly affect every site on a server: the panel UI, the Plesk web server, WordPress management, PHP runtimes, Git/Laravel/Joomla tooling, and customer-facing maintenance windows. If you manage Plesk servers, do not only check the WordPress sites. Check the panel layer too.
What Changed In The May 2026 Plesk Updates
- Plesk Obsidian 18.0.77 Update 3 was listed on May 19, 2026 with security improvements and Linux component updates.
- Plesk Obsidian 18.0.78 Update 1 was listed on May 18, 2026 with security improvements and the same Linux nginx /
sw-cp-servercomponent line. - SSH Terminal 1.4.5 was listed on May 15, 2026 with a Go compiler update tied to CVE-2026-27143.
- Plesk Obsidian 18.0.78 added product fixes and extension changes on May 12, 2026.
- WP Toolkit 6.10.0 introduced a Security Risk view for WordPress components, changing how vulnerable WordPress sites are prioritized inside Plesk.
- PHP updates were listed for PHP 8.5, 8.4, 8.3, and 8.2 on May 11, 2026.
Who Should Care
This matters for hosting providers, agencies, and site owners who run Plesk Obsidian on Linux or Windows, especially when Plesk is used to manage customer WordPress sites, PHP versions, SSL, mail, Git deployments, Laravel apps, or Joomla instances.
It matters even more if the server has public panel access, many WordPress customers, older PHP branches, Plesk extensions that customers can use directly, or automation that depends on Plesk’s bundled nginx / sw-cp-server service.
Safe Plesk Update Path
Start with a normal maintenance window. Confirm backups, tell customers if panel access or hosted sites may restart, and make sure you have console or provider access before touching production.
plesk version
plesk installer --select-release-current --show-components
plesk repair installation -nThen update through Plesk’s supported updater path. On most systems that means using the Plesk UI under Tools & Settings, the Plesk Installer, or provider-managed automatic updates. Avoid mixing manual package changes with Plesk-managed component updates unless vendor support tells you to.
plesk installer update
plesk installer --select-release-current --upgrade-installed-componentsAfter the update, verify that Plesk, nginx / sw-cp-server, PHP handlers, extension versions, and customer sites are healthy.
plesk version
plesk repair web -n
systemctl status sw-cp-server sw-engine --no-pagerWordPress Toolkit Notes
The WP Toolkit Security Risk view is worth calling out because it changes the admin workflow. Instead of treating every vulnerable plugin or theme as equal, Plesk now presents risk in a way that should help admins prioritize public, exploitable, and customer-impacting issues first.
For managed WordPress hosting, that means your update process should include:
- Reviewing high-risk WordPress components in WP Toolkit.
- Checking whether auto-updates are safe for the affected plugin or theme.
- Cloning or staging fragile sites before large plugin updates.
- Documenting customer-facing changes when a plugin has no fix or needs replacement.
- Checking logs and uploads if a WordPress vulnerability was already public before patching.
Customer Communication
Tell customers the Plesk control-panel layer received security and component updates, and that WordPress Toolkit vulnerability handling may look different after the update. For customers with managed WordPress plans, explain that higher-risk plugin and theme issues will be prioritized first, and that no-fix plugins may need replacement instead of repeated temporary mitigation.
What To Verify After Updating
- Plesk version and update level.
- Extension versions for WordPress Toolkit, SSH Terminal, Git, Laravel Toolkit, Joomla Toolkit, and any customer-facing extensions.
- PHP branch versions used by customer sites.
- Panel login, customer login, SSL renewal, scheduled tasks, backups, and mail flow.
- Web service health for Apache, nginx, PHP-FPM, and
sw-cp-server. - Unexpected executable files under customer web roots if the update followed a known WordPress/plugin incident.
