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

If you run cPanel or Plesk on a VPS or dedicated server, you can find out whether you are patched with one command and a short list of version numbers. If you are on shared hosting, you cannot run these checks yourself, but you can ask your host three short questions and get a clear answer the same day.

Here is why it is worth ten minutes this week. From late August to early October 2026, cPanel posted a new security advisory almost every week, and one of them, CVE-2026-93698, lets an attacker run commands as root on every supported cPanel build. The fixed builds are already out, and the check takes a few seconds.

By the end of this guide you will know your exact panel build, whether it is on the safe side of the line, how to update it safely, and what to send your host if the server is not yours to touch.

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?

At the time of writing (19 October 2026), these are the vendor fixes this guide covers. Version numbers go stale fast, so treat them as a floor and prefer the newest build your tier offers.

• 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 (advisory 1 October 2026, updated 7 October 2026): version 6.11.3 and older let a user run code as another account owner on the same server. Fixed in 6.11.4 or later.
• 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 (root code execution through the Plesk RESTful API extension): affected Plesk 18.0.34 to 18.0.80.7 and 18.0.81.0 with the extension at 2.4.2 to 2.4.6. Fixed in Plesk 18.0.80.8 or 18.0.81.1 or later, and extension 2.4.7. Plesk for Windows is not affected.

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

You will see the major version (for example 134) and the build number (for example 61). Advisories write that same build in long form as 11.134.0.61, so 134 build 61 and 11.134.0.61 mean the same thing.

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

Find the line that matches your major version, then check that your build number is the same or higher.

• Major version 110: you need build 148 or later (11.110.0.148).
• Major version 134: you need build 61 or later (11.134.0.61).
• Major version 136: you need build 45 or later (11.136.0.45).
• Major version 138: you need build 11 or later (11.138.0.11).
• WP Squared on 138.1: you need build 13 or later (11.138.1.13).

Made-up example: Priya runs a VPS at 192.0.2.10 that hosts five client sites. Her output shows major version 134 and build 58. Build 58 is lower than 61, so she is not patched, even though her server updates itself at night. She moves on to Step 3 to find out why.

If your major version is not in that list, it is probably no longer supported, and the fix is a planned upgrade to a supported line rather than a quick build update.

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 the browser, go to WHM > Home > cPanel > Upgrade to Latest Version and click Click to Upgrade. If the upgrade finds a blocker, cPanel says it stops and shows a warning, and nothing is half-installed.

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

You should now see a build number at or above the fixed one. If you used --bg, this lists the newest update logs so you can open the latest one.

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: Update WP Toolkit to 6.11.4 or later

WP Toolkit is the WordPress manager that many cPanel servers run. The bug in CVE-2026-93699 lets one hosting account run code as a different account owner, which matters most on servers that host other people's sites.

The advisory publishes this command, which downloads the vendor installer and installs version 6.11.4. Run it as one line.

bash <(curl https://wp-toolkit.plesk.com/cPanel/installer.sh || wget -O - https://wp-toolkit.plesk.com/cPanel/installer.sh) --version 6.11.4

Security note: piping a script from the internet into bash means you trust whatever that URL serves at that moment. Run only the command the vendor publishes, from the vendor domain shown above. If your policy says you must read scripts first, download installer.sh from the same URL, read it, then run it with the same --version 6.11.4 argument.

The advisory does not give a separate command to read the installed WP Toolkit version, so after the installer finishes, check the version shown in WP Toolkit itself and confirm it is 6.11.4 or later.

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

You want 18.0.80.8, 18.0.81.1 or later. In the browser, the version is under Tools & Settings > About Plesk.

To update Plesk from the command line, this installs the latest release and upgrades the installed components.

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.

Quick tip: Plesk for Windows is not affected by CVE-2026-68492, so Windows Plesk owners can skip this step for this bug.

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.

• Is the server my account is on running a cPanel build at or above the fixed build for CVE-2026-93698, or for Plesk, at or above 18.0.80.8 or 18.0.81.1 with the RESTful API extension at 2.4.7?
• If the server uses WP Toolkit or LiteSpeed Enterprise, are they at WP Toolkit 6.11.4 or later and LiteSpeed 6.3.7 build 2 or later?
• 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 shows a build at or above the fixed build for your line, and WHM shows the same in the top right corner.
• 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: the version shown is 6.11.4 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: plesk version shows 18.0.80.8, 18.0.81.1 or later, and plesk bin extension --get-xml-info rest-api shows 2.4.7 or later.
• 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: Priya ran a manual upgrade from WHM, and the version command then showed 134 build 61. She saved the output in her ticket notes with the date, so the next time a client asks, she can answer in one line.

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

Likely cause: you are on a cPanel line the advisory does not list. Fix: plan a move to a supported line on a staging server first, take a snapshot, and remember that major version upgrades cannot be rolled back to the previous major version.

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

Likely cause: curl and wget are missing, or outbound HTTPS from the server is blocked by a firewall. Fix: confirm the server can reach wp-toolkit.plesk.com over HTTPS, install curl from your OS packages, then run the vendor command again exactly as published.

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? Specifically: (1) the current cPanel and WHM build, and whether it is at or above the fixed build for CVE-2026-93698 (11.110.0.148, 11.134.0.61, 11.136.0.45 or 11.138.0.11 or later), or for Plesk, whether it is at 18.0.80.8 or 18.0.81.1 or later with the RESTful API extension at 2.4.7 for CVE-2026-68492; (2) whether WP Toolkit is at 6.11.4 or later and LiteSpeed Enterprise, if used, is at 6.3.7 build 2 or later; (3) the date of the last panel update and whether automatic security updates are on. Thank you.

One command, one comparison and one message is all it takes to know your server is on the safe side of these fixes.