[Bug] WHM plugin 5.3.2.0 — Restart LiteSpeed / Restart Detached PHP buttons return 403 (CSRF token missing from anchor URLs)

[alican532]

Summary

After upgrading the LSWS WHM Plugin to 5.3.2.0, every state-changing action button returns HTTP 403 Forbidden. The cause is a missing cp_security_token in action URLs generated by the new CSRF guard introduced in this version.

Environment

• cPanel/WHM 11.134.0.30 · AlmaLinux 9 · LiteSpeed 6.3.4 Enterprise · LSWS WHM Plugin 5.3.2.0

Steps to Reproduce

1. WHM → Plugins → LiteSpeed Web Server
2. Click Restart LiteSpeed (or any other action button)
3. Spinner hangs indefinitely, no error shown in UI

DevTools: GET .../index.php?do=restart_lsws 403 (Forbidden)

Root Cause

The new csrfAllow() method (WhmMod_LiteSpeed_ControlApp.php, ~line 239) requires cp_security_token on all non-read-only actions. However, WhmMod_LiteSpeed_View.php (~lines 297–322) builds button URLs without the token:
'?do=restart_lsws' // ← no cp_security_token
'?do=restart_detached_php' // ← no cp_security_token


jQuery .load() carries neither a token parameter nor an X-CP-Security-Token header, so csrfAllow() rejects every request with 403.

The 403 is not from checkacl() — verified that $_ENV['REMOTE_USER'] returns root via all three methods.

Fix

Inject the token into ?do= URLs inside tool_list_block() in WhmMod_LiteSpeed_View.php:

private function tool_list_block( array $list )
{
$cpToken = isset($_ENV['cp_security_token'])
? (string)$_ENV['cp_security_token'] : '';
$tokenParam = $cpToken !== ''
? '&cp_security_token=' . urlencode($cpToken) : '';

foreach ( $list as $listData ) {
if ( ($link = $listData->getLink()) ) {
if ( $tokenParam !== ''
&& strpos($link, '?do=') === 0
&& strpos($link, 'cp_security_token=') === false
) {
$link .= $tokenParam;
}
}
// ... rest unchanged
}
}


Other ?do= emit points (form actions, redirects, JS-built links) should be audited as well.

Impact

High — affects every WHM admin who upgraded to 5.3.2.0 via auto-update. The spinner hangs silently with no error message; the issue is only discoverable via browser DevTools or WHM access log.

Workaround (until official fix)

Apply the patch above to WhmMod_LiteSpeed_View.php, or set LSWS_DISABLE_CSRF_GUARD=1 in the WHM process environment (disables CSRF guard entirely — emergency stopgap only).

 

[abk]

Please update our WHM plugin to v5.3.2.1 and see if the issue persists. If it does please drop us a support ticket: https://store.litespeedtech.com/store/submitticket.php?step=2&deptid=2

 

[Michael A]

Hello @alican532 ,

Thank you for the report. I can confirm that v5.3.2.1 of our WHM plugin resolves most of the overly strict CSRF checking added in that release.

We are also aware of a few more actions, cache root setup and timezonedb update for example, that still block on CSRF which will be addressed in our next release.

Regards,
-Michael A.