cPanel has patched three vulnerabilities that threaten the isolation shared-hosting customers expect between accounts. The September security release addresses cross-user exposure of calendars and contacts, an authenticated route to root code execution, and a WP Toolkit flaw that permits one tenant to alter another tenant’s databases.

The issues are particularly important for hosting providers because an attacker can begin with a legitimate low-privilege account on the same server. In a multi-tenant environment, that starting point should never provide access to a neighbor’s information or the underlying host.

Calendar permissions expose neighboring accounts

CVE-2026-68490 stems from incorrect permissions in cPanel’s CalDAV and CardDAV implementation. A local user can read calendar events and contacts belonging to other cPanel accounts on the server. The flaw affects cPanel and WHM version 120 and later.

The weakness is read-only and does not itself allow the attacker to change records or become root. Even so, exposed address books and appointments may reveal names, email addresses, internal relationships, customer meetings, and schedules. That information can support targeted phishing, impersonation, or business-email compromise.

The fixed cPanel and WHM builds are 11.134.0.57, 11.136.0.41, and 11.138.0.8, while WP Squared requires 11.138.1.11 or newer. The update corrects permissions for new storage and repairs unsafe permissions already applied to existing account data.

A second CalDAV flaw reaches root

CVE-2026-87899 is substantially more severe. Any authenticated cPanel account holder could exploit the CalDAV and CardDAV weakness to escalate privileges and execute code as root. Root access gives an intruder control over the host and can put every tenant, database, mailbox, and hosted application on the machine at risk.

The flaw affects the same cPanel version range and is resolved by the same fixed builds. Providers should therefore treat the update as an urgent host-compromise fix, not simply a privacy patch for groupware features.

WP Toolkit needs its own upgrade

CVE-2026-87900 affects database-creation command handling in WP Toolkit. A logged-in cPanel user could modify databases owned by other accounts, breaking the integrity boundary between hosted WordPress customers. WP Toolkit 6.11.2-10794 and earlier are vulnerable.

Administrators must update the separately packaged wp-toolkit-cpanel component to version 6.11.3 or later. Applying the core cPanel update without checking this package may leave the database issue unresolved.

What hosting teams should do now

Administrators can update through the WHM interface under “Upgrade to Latest Version” or use cPanel’s supported update script as root. After deployment, they should confirm the running version on every node and verify WP Toolkit independently.

• Prioritize internet-facing shared servers and high-density hosting clusters.
• Check that automatic updates did not skip paused or out-of-policy nodes.
• Review account, database, calendar, and address-book logs for cross-user access.
• Investigate unexpected root processes or changes originating from tenant accounts.
• Reset credentials and restore data from known-good sources if compromise is confirmed.

Providers should also confirm that backup systems preserve evidence before rolling logs expire. Because a malicious tenant already has valid credentials, suspicious actions may not resemble an external brute-force attack. Detection rules should look for one account accessing paths, databases, or services assigned to another.

Tenant isolation requires defense in depth

This release follows other serious flaws in the broader cPanel hosting ecosystem, reinforcing the value of limiting local privileges and separating high-risk customers. A single hosting account should not be able to reach management interfaces, unrestricted system calls, or credentials shared across services.

Patching closes the disclosed paths, but providers should also use per-tenant filesystem controls, database authorization, process isolation, and monitoring that understands account ownership. Those layers reduce the chance that the next application flaw becomes a server-wide incident.