cPanel has released new builds for all public update tiers. These updates provide targeted changes to address security concerns with the cPanel & WHM product. These builds are currently available to all customers via the standard update system.
SEC-629

Summary

Respect the “no_create” parameter in BoxTrapper_getemaildirs.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Description

The BoxTrapper_getemaildirs function takes a parameter which tells it not to attempt to create the mail directories if they do not exist. This parameter was only being respected when the no_checks parameter was also set. Add a check of the value of the no_create parameter before attempting to create the mail directory. Failure to do so was the cause of bxd.cgi creating bogus domain directories under the mail directory.

Credits

This issue was discovered by William Bailey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-630

Summary

Update cpanel-php73-horde to 5.2.21-1.cp1194.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of6.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

Changelog: Update cpanel-php73-horde to 5.2.21-1.cp1194

Credits

This issue was discovered by Sonar Source. https://blog.sonarsource.com/horde-webmail-account-takeover-via-email/

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-631

Summary

Check caller privileges in create_dbowner.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 8.0 CVSS3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Description

In create_dbowner(), we need to check that the caller has the correct privileges to alter the password for the account, similar to what is done in updatehosts(). Failure to do so can allow any cPanel user to take over the root account on MySQL via the cpmysql adminbin UPDATEALL and UPDATEDBOWNER commands.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-632

Summary

MySQL admin takeover via postponed dbuser creation.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 7.6 CVSS3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H

Description

It was possible to create a cPanel account with the username ‘r_o_o_t’ when MySQL was disabled on the system. If MySQL is then enabled at a later date, then the cPanel username ‘r_o_o_t’ would map to the username ‘root’ for the database user creation. This allowed the cPanel user to change their password and take over admin rights to the MySQL server.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-636

Summary

Notify admin of lost demo mode restrictions.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 2.6 CVSS3.1AV:N/AC:H/PR:H/UI:R/S:C/C:N/I:L/A:N

Description

After an upgrade, admins are now notified that demo accounts with linked mail child nodes exist and is no longer a valid configuration.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-637

Summary

Block remote nodes on restoration of account in demo mode.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 2.6 CVSS3.1AV:N/AC:H/PR:H/UI:R/S:C/C:N/I:L/A:N

Description

The fix for case SEC-617 addressing the failure of “demo” status to propagate to remote nodes prevents setting up an account to have linked nodes while in demo mode. But, it does not block this setup on account restoration. When restoring an account, block use of linked nodes if the account is demo mode.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-638

Summary

Block cron removal on accounts with DEMO mode enabled.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 5.3 CVSS3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Description

It was possible to remove cronjobs on accounts with demo mode enabled when using legacy APIs, leaving it possible for potential attackers to cause data loss.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-639

Summary

Run demo/feature check for UAPI and API1.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 5.3 CVSS3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Description

When adding UAPI1 it was possible to by pass demo mode checks using a specially crafted URL causing the request to masquerade as a UAPI call.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-641

Summary

Stop exposing API tokens in account modification return data.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 8.0 CVSS3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:L

Description

The account modification functions return the user data to the caller. In a multi-node setup the user data can have a WORKER_NODE element added to it which contains an API token. We shouldn’t be exposing this in the return data.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

SEC-643

Summary

Immediately check account ownership in massmodifyacct.

Security Rating

cPanel has assigned this vulnerability a CVSSv3.1 score of 8.0 CVSS3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:L

Description

The error manifest in this case is two-fold. First, the check for account ownership occurs too late in the operation, and only for the local modification of the account. And, the way massmodifyacct is architected, a local failure will not prevent remote operations. Secondly, massmodify has been setup on such a way that there are no “undo” operations for any accounts where modifications have failed. To address the security aspect of this case, we need to check account ownership at the beginning of massmodifyacct and perform no further acction on an unauthorized account.

Credits

This issue was discovered by John Lightsey.

Solution

This issue is resolved in the following builds:
11.94.0.25
11.104.0.3
11.102.0.18

For the PGP-Signed message please see the linked document below.