Is your cPanel or Plesk server patched? Check in 10 minutes

One panel-version command identifies a cPanel/WHM or Plesk build, but it does not certify the whole server. PHP handlers, WP Toolkit, LiteSpeed and panel extensions have separate fixes. On a VPS, compare each installed component with its vendor advisory; on shared hosting, ask the operator for a dated component-by-component answer.

This matters after several September and October 2026 advisories. The 29 September cPanel CVE-2026-93698 can lead to root code execution, while later 21 October PHP and WP Toolkit advisories raised the practical patch target again. A version that passed the older check is not automatically current for the newer one.

By the end you will have the panel build and a short component inventory, know which advisory each floor answers, and have an update or host-handoff plan. Ten minutes is an initial check, not a guarantee that a multi-component update finishes in that time.

What does "patched" actually mean for a control panel?

A control panel is the software you log in to for managing sites, email and databases, such as cPanel with WHM or Plesk. A patch is a new build of that software that closes a security hole. If you want a refresher on how panels fit into hosting in general, see our guide on what web hosting is.

Think of it like a recall on your car. The maker finds a faulty part, builds a fixed one, and tells owners which serial numbers are affected. Your job is to read the serial number on your car, compare it with the list, and book the fix if you are on the wrong side.

Here the "serial number" is your panel build number, and the "recall notice" is the vendor advisory. A CVE is simply the public ID number given to a security bug, so everyone talks about the same problem.

Why this matters: CVE-2026-93698 is in a part of cPanel called the Multilang adminbin (a small helper that runs with root rights). cPanel's advisory says successful use of the bug leads to code execution as root, which means full control of the server and every account, site and database on it. The advisory lists no workaround, so updating is the fix.

Which advisories are we checking?

This article originally covered advisories through early October. Checked again on 25 October 2026: the 21 October PHP and WP Toolkit notices add newer floors. The older numbers below remain the historical fixes for their named CVEs; the comparison steps use the newer available bulletin where it supersedes a simple “fully patched” claim.

• cPanel and WHM, CVE-2026-93698 (advisory 29 September 2026): fixed in 11.110.0.148, 11.134.0.61, 11.136.0.45, 11.138.0.11 or later. WP Squared is fixed in 11.138.1.13 or later.
• cPanel stored XSS, CVE-2026-93029 and CVE-2026-93697 (same day): stored XSS means someone can save malicious script in a page that an admin later opens. Check the vendor advisories for the exact fixed builds, and updating to the latest build for your line is the simple path.
• WP Toolkit for cPanel: CVE-2026-93699 was fixed in 6.11.4, but cPanel’s 21 October advisory for separate CVE-2026-107663 says 6.11.4 and earlier are affected and 6.11.5 is fixed. On a current check, target 6.11.5 or later rather than stopping at the historical 6.11.4 floor.
• LiteSpeed Web Server Enterprise (advisory 14 September 2026): versions before 6.3.7 can let a low-privilege shared-hosting user potentially gain root, bypassing CageFS (the jail that keeps accounts apart). Fixed in 6.3.7 build 2 or later.
• Plesk for Linux, CVE-2026-68492: an authenticated user may execute code as root through an affected RESTful API extension. The fix is Plesk 18.0.80.8 or 18.0.81.1 or later with extension 2.4.7 or later. Plesk for Windows is not affected by this particular CVE; the separate 21 October PHP issue also affects Plesk for Windows and must be checked independently.

Heads up: DirectAdmin is not covered in this guide. If that is your panel, check its own release notes.

The Canadian Centre for Cyber Security also flagged the WebPros (cPanel and Plesk) advisories in its bulletin AV26-961 on 24 September 2026, which is a handy second pointer if your manager wants an outside source.

Before you start

This part takes two minutes and saves you from the one bad night every admin remembers.

• Root access: you need SSH as root, or WHM root login, or the Plesk admin account. If you only have a cPanel user login, you are in the shared-hosting group, so skip to Step 9.
• A backup you trust: take a provider snapshot of the VPS if your host offers one, and keep an offsite copy of your sites. Our guide on how to back up a cPanel site offsite and test the restore walks through it.
• A time window: checking takes seconds. A panel update can take a while, and web services may restart, so pick a quiet hour.
• Risk level: a minor build update inside your current release line is low risk. A jump to a new major version is higher risk, and cPanel says you cannot downgrade back to a previous major version afterwards.

Quick tip: open a second SSH session before you start. If the first one drops during an update, you still have a way in.

Check and update your panel

Steps 1 to 5 are for cPanel and WHM. Steps 6 and 7 cover add-ons that often sit on cPanel servers. Step 8 is Plesk, and Step 9 is for shared-hosting readers.

Step 1: Find your cPanel build

Log in over SSH as root. This command prints the installed cPanel and WHM version.

/usr/local/cpanel/cpanel -V

The short command output may show a major line and build (for example 134 build 66, corresponding to 11.134.0.66). Record the exact output rather than stripping digits or assuming all components share its patch state.

If you prefer the browser, WHM also shows the version in the top right corner of the interface.

Step 2: Compare it with the fixed build for your line

For the cPanel/WHM PHP-related 21 October bulletin, compare within the exact release line. These newer builds also exceed the older CVE-2026-93698 floors, but still do not verify WP Toolkit or the site’s PHP package.

• Major version 110: 11.110.0.153 or later for the 21 October cPanel/WHM bulletin (the earlier Multilang fix began at .148).
• Major version 134: 11.134.0.66 or later for the 21 October bulletin (earlier Multilang fix .61).
• Major version 136: 11.136.0.50 or later for the 21 October bulletin (earlier Multilang fix .45).
• Major version 138: 11.138.0.18 or later for the 21 October bulletin (earlier Multilang fix .11).
• WP Squared on 138.1: 11.138.1.17 or later for the 21 October bulletin (earlier Multilang fix .13).

Made-up example: Priya runs a VPS at the reserved example address 192.0.2.10. Her 134 build 58 is below both the older .61 Multilang floor and the later .66 PHP-related floor. If she later sees 134 build 61, that confirms only the first comparison; she still has to update and recheck against the newer bulletin and installed add-ons.

If the release line is not listed, do not conclude from its absence alone that it is unsupported. Check cPanel’s current lifecycle and advisory for that exact line; arrange a supported upgrade or vendor guidance if no fixed build is available.

Step 3: Check your tier and automatic updates

Your release tier decides which builds your server is allowed to install. Go to WHM > Home > Server Configuration > Update Preferences and look at the tier that is selected.

• LTS: one version per year, supported for that year.
• STABLE: builds that have had wide public use and testing.
• RELEASE: feature complete and well tested. This is the default for new installs.
• CURRENT: tested, but may not contain every planned feature.
• EDGE: only basic testing. cPanel says to use it only for testing in a controlled environment, so keep it off production servers.

Why this matters: cPanel notes that on the RELEASE tier, automatic upgrades to a later major version can be delayed by several business days, with a random length, and that a manual upgrade skips that delay. Priya's gap is a build inside her major version, so that delay may not explain it. Her tier, her update settings and the update log are the places to look.

The same page also controls the security-only updates. cPanel's upcp script has a --security option that applies critical security updates and runs from an hourly cron job (a scheduled task). It can be turned off in Update Preferences, so check that you have not disabled it.

Step 4: Update cPanel and WHM

You have two ways to do this. Both install the newest build allowed by your tier.

In WHM, use Home > cPanel > Upgrade to Latest Version and review the offered build and any preflight warning. A blocker may stop an upgrade before it starts, but no interface message guarantees that every possible interrupted update leaves all components untouched. Keep a recoverable snapshot and read the update log afterward.

On the command line, this runs the cPanel update script in the foreground so you can watch it.

/usr/local/cpanel/scripts/upcp

If your SSH connection is shaky, this runs the same update in the background and writes the output to a log file.

/usr/local/cpanel/scripts/upcp --bg

When the background run starts, the shell returns quickly. The log goes to /var/cpanel/updatelogs with a file name in the update.DATE pattern, where DATE is a Unix timestamp.

Heads up: you will see --force in many forum posts. It reinstalls all files and updates to the latest version, and it overrides your update preferences, so check your tier first. Use it only when you have a reason, not as your default.

If an update finished but something looks broken, --sync reinstalls your current version without downloading a newer one. You cannot combine it with --force.

Step 5: Confirm the new build and read the log

Run the version command again and compare the result with your line in Step 2.

/usr/local/cpanel/cpanel -V

Compare the resulting panel build with the dated advisory for its line. This does not establish that PHP handlers or WP Toolkit updated. If you used --bg, list the newest update logs and inspect the latest completed run.

ls -lt /var/cpanel/updatelogs | head -n 5

Open the newest file with less and jump to the end. Look for the final lines of the run rather than for one magic phrase, and search for words like "error" or "blocker" if the build did not change.

Step 6: Verify WP Toolkit 6.11.5 or later

CVE-2026-93699, fixed in WP Toolkit 6.11.4, allowed cross-account code execution. A separate 21 October cPanel advisory, CVE-2026-107663, lists 6.11.4 and earlier as affected and 6.11.5 as the patched build. The current target for this component is therefore 6.11.5 or later.

First use the read-only version check published in cPanel’s 21 October advisory. If older than 6.11.5, follow that current vendor advisory or your host’s managed-update procedure. Its published installer downloads code and executes it as root; verify the HTTPS vendor source, review the script under your change-control policy and use a maintenance window rather than pasting an old 6.11.4 command.

grep version /usr/local/cpanel/3rdparty/wp-toolkit/build.json

The cPanel advisory publishes the installer URL and a command targeting 6.11.5. Use its current instructions after inspection and backup; do not disable TLS verification or fetch from an unofficial mirror. Record the installer outcome and run the version check again.

The 21 October cPanel advisory does provide the read-only build.json check above. Confirm it shows 6.11.5 or later; a panel build alone does not prove this add-on is fixed.

Step 7: Check LiteSpeed Enterprise, if you use it

Skip this step if your server runs Apache or Nginx. If you run LiteSpeed Web Server Enterprise, these commands show the installed version, the installed build, and the newest build available.

cat /usr/local/lsws/VERSION
cat /usr/local/lsws/BUILD
cat /usr/local/lsws/autoupdate/build

You want version 6.3.7 with build 2 or later. The advisory warns that if you updated to 6.3.7 earlier, you should upgrade again to reach the fixed build.

The advisory gives this command to update LiteSpeed to 6.3.7.

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7

The -f flag installs the latest edge build even when the latest stable release is already installed, -v picks the version, and LiteSpeed's docs also offer -b to pick a build number. When the update finishes, this restarts the web server so the new build takes over.

/usr/local/lsws/bin/lswsctrl restart

Then run cat /usr/local/lsws/BUILD again and confirm the build is 2 or higher.

Step 8: Plesk on Linux

Plesk says the RESTful API extension is installed by default but hidden in the interface, so you may be affected even if you never installed it. Both parts must be at an affected version for the bug to apply, but you should fix both anyway.

This command shows the installed version of the rest-api extension.

plesk bin extension --get-xml-info rest-api

You want version 2.4.7 or later. Plesk's example of good output is <module fullVersion="2.4.7-18178" status="true"/>.

If you see an older version, this command updates the extension from the Plesk catalog.

plesk bin extension --install rest-api

Next, check the Plesk version itself. This prints the product version, OS and build date.

plesk version

For the older RESTful API CVE, the product floor is 18.0.80.8 or 18.0.81.1 within its release line, paired with extension 2.4.7. The later PHP2Shell advisory raises the panel-engine requirement to 18.0.80 Update 11 or 18.0.81 Update 4 and also requires patched PHP handlers. In the browser, the product version is under Tools & Settings > About Plesk.

After checking the later panel-engine and PHP-handler floors above, use Plesk’s documented update path in a maintenance window if either is behind. This command selects the latest Plesk release and upgrades installed components; check the exact offer and backup/rollback plan before running it.

plesk installer --select-release-latest --upgrade-installed-components

In the browser, go to Tools & Settings > Updates, click Install or Update Product, then click Continue. When it finishes, run plesk version again.

Plesk for Windows is not affected by CVE-2026-68492. It is in scope for the separate PHP2Shell advisory, so Windows operators should still check panel-engine and PHP handler builds.

Step 9: On shared hosting? Ask your host

On shared hosting you do not have root, so none of the commands above will work for you, and that is fine. Your host patches the server. Your job is to ask clearly and get a dated answer.

• For cPanel/WHM, what exact build is installed and is it at or above the 21 October PHP-related floor for its line? For Plesk, does it meet both the RESTful API fix (extension 2.4.7 and fixed product build) and the later panel-engine PHP fix?
• If WP Toolkit or LiteSpeed Enterprise is installed, is WP Toolkit 6.11.5 or later, and is LiteSpeed Enterprise at least 6.3.7 build 2?
• When was the last panel update applied, and are automatic security updates turned on?

Quick tip: ask for the build number in writing with a date. "We keep servers updated" is a nice sentence, but a build number is something you can compare with the list above yourself.

How to check it worked

Run these checks after any update, and write the results down with the date.

• cPanel: /usr/local/cpanel/cpanel -V matches the 21 October line-specific floor above; separately confirm PHP package and handler versions.
• cPanel update log: the newest file in /var/cpanel/updatelogs ends without a blocker warning.
• Update Preferences: your tier is LTS, STABLE, RELEASE or CURRENT (not EDGE), and security updates are not disabled.
• WP Toolkit: build.json or the vendor interface reports 6.11.5 or later.
• LiteSpeed: /usr/local/lsws/VERSION shows 6.3.7 or later and /usr/local/lsws/BUILD shows 2 or later on 6.3.7.
• Plesk: for CVE-2026-68492, confirm RESTful API extension 2.4.7 and a fixed Plesk build. Separately confirm the 21 October panel-engine and PHP-handler fixes; the older 18.0.80.8/18.0.81.1 floor alone is insufficient for those later bugs.
• Sites: open two or three sites, log in to WHM or Plesk, send a test email, and make sure everything loads as before.

Made-up example, continued: after a manual upgrade Priya sees 134 build 66, records the dated output, then separately checks PHP packages, WP Toolkit and LiteSpeed if installed. One panel number is a component result, not a blanket clean bill of health.

Troubleshooting

The upgrade stops with a blocker warning

Likely cause: cPanel found something that makes the upgrade unsafe, such as an unsupported setting or OS state. Fix: read the warning text, then open cPanel's Upgrade Blockers documentation from the Upgrade to Latest Version page and clear the named blocker before trying again.

The version did not change after the update

Likely cause: your tier does not yet offer a newer build, a major version upgrade is still inside the RELEASE tier delay, or the update failed partway. Fix: check the tier in WHM > Home > Server Configuration > Update Preferences, read the newest file in /var/cpanel/updatelogs, and run a manual upgrade.

Your major version is not in the fixed list

A line absent from this snapshot is not automatically unsupported. Consult the current cPanel lifecycle and vendor advisory, then plan a tested move if your actual line has no maintained fixed build. Major-version rollback may not be supported.

Your SSH session dropped during the update

Likely cause: a network timeout during a long foreground run. Fix: log back in, check whether the update is still running before starting another, and use upcp --bg next time so the work continues and logs to /var/cpanel/updatelogs.

The WP Toolkit installer command fails to download

Possible causes include unavailable curl/wget or blocked outbound HTTPS. Confirm connectivity to the official wp-toolkit.plesk.com endpoint and inspect the exact vendor installer and its error output under your change-control procedure; do not bypass TLS checks or substitute an unofficial mirror. If the blocker persists, ask the host or vendor rather than repeatedly running a root installer.

LiteSpeed still shows an old build after updating

Likely cause: the update finished but the server was not restarted, or you updated to 6.3.7 before build 2 existed. Fix: run /usr/local/lsws/bin/lswsctrl restart, then check /usr/local/lsws/BUILD, and repeat the lsup.sh update if it is still below 2.

Plesk still reports the extension below 2.4.7

Likely cause: the catalog update did not run or failed quietly. Fix: run plesk bin extension --install rest-api again, read its output for errors, and check again with --get-xml-info. If it still fails, open a ticket with Plesk support and include both outputs.

Pro tips for staying patched

Patching once is good. Staying patched without thinking about it is better.

• Keep security updates on and pick a tier you are comfortable with. RELEASE is the default, LTS suits people who want fewer changes.
• Put a monthly reminder in your calendar to run the version command and skim the vendor security pages.
• Lock down the way into WHM and Plesk too. Turn on two-factor authentication for your panel and add Fail2ban to slow down SSH attacks.
• Test big upgrades on a staging copy of the server before you touch production.

Security note: a patched panel closes known holes. It does not replace backups, strong passwords or least-privilege accounts, so keep those habits too.

The one message worth forwarding

If you are on shared hosting, or a developer manages your server, copy this and send it as is.

Hi, could you confirm the patch status of the server my account is on, with a date and the exact component builds? For cPanel/WHM, please compare the installed build with the 21 October PHP-related advisory floor for its line (11.110.0.153, 11.134.0.66, 11.136.0.50, 11.138.0.18, or WP Squared 11.138.1.17) and confirm the PHP handlers and WP Toolkit 6.11.5 or later. If LiteSpeed Enterprise is installed, please confirm 6.3.7 build 2 or later. For Plesk, please confirm the RESTful API extension is 2.4.7 or later, the product build fixes CVE-2026-68492, and the newer 21 October PHP handler/panel-engine fixes are installed. Which checks were actually performed, and when?

One command starts a useful panel check. Complete it by comparing the dated vendor advisory for each installed component, verifying the update result and asking the host for evidence you cannot inspect yourself.