LiteSpeed cPanel plugin CVE-2026-48172: the symlink-to-root flaw and how to verify you’re patched

The LiteSpeed Web Server plugin for WHM is a small piece of software that does a privileged job: it switches the web server between Apache and LiteSpeed, edits the LiteSpeed configuration, and reads and writes files under customer document roots on the administrator’s behalf, all as root. In June 2026 two flaws, CVE-2026-48172 and CVE-2026-54420, were disclosed in how it handled paths. A cPanel user could plant a symbolic link in a location the plugin later processed, and the plugin followed the link as root, giving the user a write into a file of their choosing.

Version 2.4.8 of the plugin fixed both. This guide explains the mechanism, how to check, and what to do on a server that ran the vulnerable version with untrusted users.

Short answer: CVE-2026-48172 and CVE-2026-54420 let any cPanel user plant a symlink that the root-level LiteSpeed WHM plugin followed, turning it into an arbitrary file write as root; plugin version 2.4.8 fixed both. Check the installed version with cat /usr/local/cpanel/whostmgr/docroot/cgi/lsws/VERSION or rpm -q lsws-whm-plugin, and if it is below 2.4.8 re-run lsws_whm_plugin_install.sh to update. Then search /home for symlinks pointing at /etc, /root or cron directories and review root persistence locations for changes since June 2026.

Why a symlink is enough

The plugin performs several operations that touch user-owned paths: rebuilding per-account configuration, migrating .htaccess settings, handling cache directories and reading account metadata. When a root process opens a path inside a user’s home without checking whether each component is a symlink, the user controls where the open lands. Point the link at /etc/passwd, /root/.ssh/authorized_keys or a root cron file, trigger the plugin operation, and the plugin writes attacker content there. The second CVE covered a variant where a race between a check and the subsequent use allowed the same outcome even where a check existed.

On a shared server every customer is an untrusted local user, and a compromised WordPress site gives an attacker exactly the shell access needed to create the link. That is why this class of bug is rated as a full root compromise rather than a local nuisance.

Check the installed version

The plugin reports its version in WHM » Plugins » LiteSpeed Web Server, but the command line is quicker across a fleet:

cat /usr/local/cpanel/whostmgr/docroot/cgi/lsws/VERSION 2>/dev/null
rpm -q lsws-whm-plugin 2>/dev/null

The path varies slightly between plugin generations; if the first command prints nothing, run find /usr/local/cpanel/whostmgr/docroot/cgi -maxdepth 2 -iname '*lsws*' and look for a VERSION file inside. Anything below 2.4.8 is vulnerable. Check the LiteSpeed server version at the same time, since the plugin update sometimes coincides with a server update:

/usr/local/lsws/bin/lshttpd -v

Update

The plugin has a self-update path in WHM, but for a fleet use the installer script, which fetches the current release and replaces the plugin in place:

cd /usr/src
curl -fsSLO https://www.litespeedtech.com/packages/cpanel/lsws_whm_plugin_install.sh
bash lsws_whm_plugin_install.sh

Re-run the version check afterwards. The installer does not restart LiteSpeed and does not touch customer sites; it replaces the WHM plugin files only. If the server runs the LiteSpeed cPanel plugin through the cPanel Plugin system with automatic updates, confirm those updates actually ran; some servers have the update task disabled in /etc/cpupdate.conf alongside other plugins.

cPanel listed CVE-2026-48172 and CVE-2026-54420 in its own June advisory alongside the plugin release, so also confirm the panel build is current. The build list is in our CVE and build guide.

Look for exploitation

If the vulnerable plugin was in place with untrusted users for any length of time, assume someone may have tried. The evidence is symlinks in user home directories pointing at root-owned files:

find /home -maxdepth 4 -type l -lname '/etc/*' -o -maxdepth 4 -type l -lname '/root/*' -o -maxdepth 4 -type l -lname '/var/spool/cron/*' 2>/dev/null

Then check the usual root persistence locations for recent, unexpected changes:

ls -la --time-style=full-iso /root/.ssh/ /etc/cron.d/ /var/spool/cron/
find /etc /root -newermt '2026-06-01' -type f 2>/dev/null | head -50
grep -v '^#' /etc/passwd | awk -F: '$3==0'

Any user with UID 0 other than root, an authorized_keys entry nobody recognises, or a cron file created around the time the plugin ran a task is a compromise, and the correct response is rebuild rather than clean-up. Our security audit script performs these checks along with the standard persistence review.

Reduce the impact of the next one

Plugins that run as root will have bugs again. Two settings limit the damage. Enable symlink protection at the kernel level so root refuses to follow links owned by other users in world-writable or user-owned directories:

sysctl -w fs.protected_symlinks=1
sysctl -w fs.protected_hardlinks=1
grep -E 'protected_(sym|hard)links' /etc/sysctl.conf /etc/sysctl.d/*.conf

These are on by default in AlmaLinux 9 and 10 but are sometimes disabled by legacy tuning. Note that protected_symlinks only covers links in sticky world-writable directories, so it would not have prevented this specific flaw in a home directory, but it stops the /tmp variants. CloudLinux with CageFS restricts what a user can see and link to, and is the stronger mitigation on shared servers; see our CloudLinux 10 guide.

Verify

After updating, confirm the version file reads 2.4.8 or higher, open the plugin in WHM to confirm it loads without error, and run one harmless operation such as viewing the server status to confirm the plugin still works with the current LiteSpeed build. Repeat the symlink search a week later; an attacker who planted links before the fix may leave them in place. The common pitfall is updating LiteSpeed Web Server itself, seeing a new version number in WHM, and assuming the plugin was updated with it. They are separate packages with separate version numbers, and the vulnerable component was the plugin.

LiteSpeed cPanel plugin CVE-2026-48172 at a glance

Official documentation: LiteSpeed documentation, cPanel & WHM documentation, Linux man pages.

Related guides: Certificate lifetimes are shrinking to 47 days: what hosting providers must automate now · Setting up AutoSSL with Sectigo or Let’s Encrypt and enabling short-lived ACME certificates · Retiring PHP 8.1 sites safely on cPanel: audit, test, and TuxCare ELS as a stopgap.

Frequently asked questions