A hosting control panel holds the keys to every site, mailbox, database and DNS zone on a server, so one stolen panel credential or one unpatched panel flaw can become a compromise of hundreds of customers at once. Panels such as cPanel and WHM, Plesk and DirectAdmin are built for delegation: server administrators, resellers and end customers all log in, and scripts and integrations call the panel's API with long-lived tokens. That makes them identity systems as much as hosting tools. This guide covers the panel account model, admin and reseller credentials, API tokens and login keys, two-factor authentication, network restriction, isolation between tenants, panel vulnerabilities in the CISA Known Exploited Vulnerabilities catalogue, and the logs that show misuse. It is for hosting providers, agencies and in-house teams running their own panel servers. Product facts come from each vendor's documentation, checked on 2 November 2026; menus and defaults change between versions, so confirm against your installed version.
Key takeaways
- Treat panel tokens as root credentials. A WHM API token with the "Everything" privilege is full root-level access, cPanel tokens default to one year and can be set never to expire, and expired tokens stay until someone deletes them.
- Restrict every privileged path by network. WHM tokens accept up to 100 allowed IP ranges, Plesk can limit Administrator logins and its API to listed addresses, and DirectAdmin login keys take an allowed IP list. Unrestricted is the default in each case.
- Two-factor is per user, not per server. In cPanel the root user turns on the policy, but each cPanel user must set it up; WHM cannot enable it for them. Measure enrolment, do not assume it.
- Panel flaws are exploited, often with ransomware. KEV lists a 2026 cPanel and WHM authentication bypass with known ransomware use, an actively exploited LiteSpeed cPanel plugin flaw, and command injection in CWP, CyberPanel and Webmin.
- Isolation decides the blast radius. A per-site PHP pool, per-user file system isolation and no shared database or SSH credentials turn one compromised customer site into one incident instead of a server-wide one.
The panel account model and why it is an identity problem
Every major panel has the same three tiers, plus machine access through an API. The names differ, the risks do not.
| Tier | cPanel and WHM | Plesk | DirectAdmin | What compromise gives an attacker |
|---|---|---|---|---|
| Server administrator | WHM root (port 2087) | Plesk Administrator and additional administrator accounts | Admin level (port 2222) | The whole server: every account, every file, mail and DNS |
| Reseller | WHM reseller with a privilege set chosen by the provider | Reseller account | Reseller level | All customer accounts owned by that reseller; often account creation |
| End customer | cPanel account (port 2083) | Customer or subscription user | User level | That account's sites, databases, mailboxes and files |
| Machine access | WHM and cPanel API tokens | Plesk XML API and REST API | Login keys (CMD_LOGIN_KEYS) | Whatever the token's privileges and command list allow, usually without two-factor |
The machine tier is the one most often forgotten. Tokens live in billing systems, DNS clusters, migration tools, agency deployment scripts and monitoring, they rarely expire, and they bypass interactive controls: cPanel's documentation notes that public key and API token authentication still work during a cPHulk brute force lockout, and DirectAdmin notes that disabling API access with the login password does not affect login keys and session keys. The general principles for privileged identities are in the Admin panels and super admin accounts guide; this page applies them to hosting panels.
Admin and reseller credentials
- Named administrators, not shared root: give each person their own administrator or reseller login where the panel allows it, keep the true root or primary admin as a vaulted break-glass account, and log who used it. See the Break-Glass Account Guide.
- Reseller privileges are a scope decision: in WHM the provider chooses each reseller's privileges, and some interfaces appear only when specific privileges are granted (for example, resellers see API Tokens only if all Initial Privileges are enabled). Grant the minimum set, and review it when a reseller's business changes.
- Delegated admin is not a sandbox: DirectAdmin's own documentation warns that a delegated admin with a restricted command set "is not fool-proof", because overlapping commands may still allow changes to admin accounts. Treat any admin-level account as full admin.
- Provisioning systems hold everyone's credentials: in the GoDaddy Managed WordPress Breach 2021, one compromised password reached the provisioning system and exposed admin, sFTP and database credentials, with sFTP passwords reportedly stored in retrievable form. Do not keep retrievable customer passwords in panel-adjacent tooling.
- Offboarding: when staff, agencies or resellers leave, remove their logins and revoke every token they created, not only their password. See the NHI Offboarding and Decommissioning Guide.
API tokens and login keys
Panel API credentials are non-human identities with administrative reach. The controls each vendor documents are below; use all of them.
| Control | WHM and cPanel API tokens | Plesk API | DirectAdmin login keys |
|---|---|---|---|
| Scope | At least one ACL privilege per token, limited to privileges the creator holds; cPanel marks ACL assignment as experimental | API access is server-wide; the documentation warns an attacker could use it to gain control of the server | Allowlist of CMD_API_ commands; avoid ALL_USER, CMD_LOGIN_KEYS and CMD_API_LOGIN_KEYS |
| High-risk permissions | "Everything" (root-level), Change Password, Create User Session and Manage API Tokens; the last two can bypass the token's restrictions | Not applicable | Key management commands, which let a key mint new keys |
| Expiry | Default one year from creation, or never; expired tokens must be deleted manually | Not documented on the page read | Expiry date, request count limit and auto-delete when either is reached |
| Network restriction | IPs field, up to 100 addresses or CIDR ranges; blank means any address | [api] section of panel.ini: enabled = off, or allowedIPs for trusted addresses | Allowed IPs list per key |
| Secret handling | Token shown once at creation | Store integration secrets in a vault | Current password required to create a key |
| Revocation | Per token or Revoke All; deleting an account revokes its tokens; renaming does not | Disable the API or remove the address | Delete the key or use Clear Key |
Token rules that work across panels
- Inventory first. List every token and key on every server, who created it, what calls it, its privileges, IP restriction and expiry. In WHM the token list shows expiring tokens in yellow and expired ones in red.
- One token per integration. A billing system, a DNS cluster and a backup tool each get their own, so revocation does not break unrelated jobs. DirectAdmin's documented DNS cluster example limits the key to three DNS and login test commands and the master server's IP.
- Never "Everything" for automation. Pick the specific privileges the integration needs, and never grant token management or session creation to a token that does not need them.
- Bind to source addresses. Always fill the IP list. A token with no restriction can be used from anywhere it leaks to.
- Expire and rotate. Set expiry of a year or less, rotate on staff or supplier change, and delete expired tokens rather than leaving them for audit noise.
- Keep tokens off web servers. A token stored in a site's deployment script on the same server is readable by anyone who gets code execution there, which is how a single site compromise becomes a panel compromise. The PHP2Shell guide lists panel tokens among the secrets a PHP worker exposes. See also the API Key Management Guide.
Two-factor authentication and brute force protection
| Panel | Two-factor | Brute force protection | Notes from vendor docs |
|---|---|---|---|
| cPanel and WHM | TOTP six-digit codes; root enables the Two-Factor Authentication Security Policy, then each user sets it up; root and resellers with create-acct enrol in WHM, cPanel users in cPanel | cPHulk covers cPanel (2083), WHM (2087), Dovecot, Exim, Pure-FTPd and SSH; default account lock at 15 failures in 5 minutes; allow and deny lists, country rules | Root is not locked by default; token and key logins bypass lockout; 2FA may break some third-party applications; admins can disable a user's 2FA from Manage Users |
| Plesk | Not covered by the vendor pages read; confirm the two-factor options in your Plesk version's documentation | IP Access Restriction Management for Administrator logins: allow-all-except-list or deny-all-except-list | The IP restriction applies only to Administrator accounts, not customers |
| DirectAdmin | Two-step authentication (TOTP) with one-use scratch codes; twostep_auth=1 by default in directadmin.conf; trusted device cookie lasts twostep_auth_trust_days=30 | Built-in IP blacklisting after repeated failures on port 2222; Brute Force Monitor parses Apache, Dovecot, Exim, ProFTPd and SSHd logs and blocks through CSF | Failed 2FA attempts count toward the same failed login limit; notify_on_all_twostep_auth_failures=yes in user.conf alerts the user |
- Enforce for every privileged login: 2FA for root, all administrators and all resellers first, then customers. Track enrolment per tier, because the panels let users opt in rather than forcing them.
- Protect the recovery path: an administrator who can disable a user's 2FA is part of the trust chain, so log and review every 2FA reset (cPanel records 2FA setting changes in
/var/cpanel/accounting.log). See the MFA backup codes and recovery codes guide. - Allowlist your own addresses before deny-by-default: cPHulk and Plesk's deny-all policy can lock administrators out; cPanel's documentation advises adding your own IP to the allow list.
- Use TLS on panel ports: DirectAdmin's documentation recommends securing port 2222 with a certificate; the same applies to every panel login.
The MFA Guide covers method choice beyond TOTP.
Network exposure
Panel ports exposed to the whole internet are the main reason panel vulnerabilities turn into mass exploitation. Decide per tier:
- Administrator and WHM access: reachable only from a VPN, bastion or fixed office addresses. Use Plesk IP Access Restriction Management, cPHulk allow lists with deny-by-country where appropriate, or a host firewall.
- Panel APIs: in Plesk, set
enabled = offin the[api]section ofpanel.iniif nothing uses the API, otherwise list trusted addresses inallowedIPs. In WHM and DirectAdmin, rely on per-token and per-key IP lists. - Customer panels: usually must stay public for shared hosting customers. Compensate with 2FA, brute force protection and fast patching.
- Webmail, FTP and SSH on the same host: include them in brute force protection (cPHulk and DirectAdmin's monitor both cover mail and SSH), and prefer SFTP with keys over FTP passwords.
Multi-tenant isolation
On shared hosting, the panel is also the tenant boundary. The worst incidents happen when one compromised site can read another's files or credentials.
| Layer | Weak configuration | Stronger configuration | Source |
|---|---|---|---|
| PHP handler | mod_php, ISAPI or CGI, which Plesk calls "severely outdated and/or insecure"; one shared FPM pool per PHP version | Dedicated FPM pool per site, which Plesk recommends for shared hosting | Plesk PHP handlers documentation |
| File system view | Users can list other accounts, server configs and processes | Per-user virtualised file system such as CloudLinux CageFS, where users cannot see other users, their processes or server configuration files (CageFS does not support mod_php and is off by default) | CloudLinux documentation |
| Credentials | One database password or SSH key used across several customer sites | Per-site database users and SSH keys; no private keys stored in hosting accounts | SOCRadar's 2026 extortion case found both reuse patterns enabling movement between accounts on one host |
| Panel plugins | Third-party plugins running privileged helpers for every user | Minimal plugins, patched on the vendor's advisory, removed if unused | KEV entries for the LiteSpeed cPanel plugin |
The KEV entries show why isolation is not optional: CVE-2026-48172 let any cPanel user run scripts as root through the LiteSpeed user-end plugin, according to LiteSpeed, which reported active exploitation; CVE-2026-54420, another LiteSpeed cPanel plugin flaw, is described by CISA as a symlink-following issue usable by a user with FTP or web shell access on a CloudLinux CageFS server. In both cases the attacker starts as an ordinary tenant. A compromised customer site is therefore a server-level threat until the panel is patched. The Multi-Tenant SaaS Architecture Security Guide covers tenant isolation thinking more broadly.
Panel vulnerabilities in the CISA KEV catalogue
From the KEV catalogue (version 2026.10.30). Use KEV status to set patch priority for panel servers ahead of ordinary updates. See the CISA KEV Catalogue Guide.
| CVE | Product | Weakness (KEV description) | Added to KEV | Known ransomware use |
|---|---|---|---|---|
| CVE-2026-41940 | cPanel & WHM and WP2 (WordPress Squared) | Authentication bypass in the login flow giving unauthenticated access to the control panel | 30 Apr 2026 | Known |
| CVE-2026-48172 | LiteSpeed cPanel Plugin | Privilege escalation: any cPanel user can run scripts as root | 26 May 2026 | Unknown |
| CVE-2026-54420 | LiteSpeed cPanel Plugin | Symlink following by a user with FTP or web shell access on CloudLinux/CageFS | 15 Jun 2026 | Unknown |
| CVE-2025-48703 | CWP Control Web Panel | Unauthenticated OS command injection in a file manager request (a valid non-root username must be known) | 4 Nov 2025 | Unknown |
| CVE-2024-51567 | CyberPanel | Incorrect default permissions allowing remote unauthenticated command execution as root | 7 Nov 2024 | Known |
| CVE-2024-51378 | CyberPanel | Incorrect default permissions allowing authentication bypass and command execution | 4 Dec 2024 | Known |
| CVE-2022-44877 | CWP Control Web Panel | OS command injection in the login parameter | 17 Jan 2023 | Unknown |
| CVE-2019-15107 | Webmin | Command injection in password_change.cgi | 25 Mar 2022 | Known |
Two patterns stand out. Pre-authentication flaws in the login path (cPanel, CWP, CyberPanel, Webmin) make network restriction of admin ports the most effective compensating control. Plugin and helper flaws (LiteSpeed) mean the plugin inventory is part of the panel's attack surface, not an add-on. Panels also bundle PHP builds for customer sites, so runtime flaws such as PHP2Shell need the panel vendor's rebuild; see Unsupported PHP versions.
Hardening rollout
- Inventory. List panel servers, versions, update tier, installed plugins, administrators, resellers and every API token or login key. This is also the baseline for later reviews.
- Patch and turn on automatic panel updates on a channel you can support, and subscribe to each vendor's security announcements and the KEV feed.
- Restrict admin and API access by network. Pilot on one server: add your management addresses to the allow list first, test login from inside and outside, then apply deny-by-default. Roll back by removing the policy from the console or configuration file if you lock yourself out, which is why the console route must be tested first.
- Enforce 2FA for root, administrators and resellers. Warn affected third-party integrations first, since cPanel notes 2FA can break some of them, and move those integrations to scoped tokens.
- Rebuild token estate. Replace broad or non-expiring tokens with one scoped, IP-bound, expiring token per integration; revoke the old ones; confirm each integration still works.
- Isolate tenants. Move sites to per-site FPM pools, enable file system isolation where available, and split shared database and SSH credentials.
- Forward logs and set alerts (next section), then review quarterly.
Small providers or agencies with one or two servers can do all of this in a week; the biggest gain is network restriction plus 2FA. Large providers should automate token inventory and enrolment reporting across the fleet. The Cybersecurity for MSPs and MSSPs Guide covers the supplier side.
Logs, detection and measurement
| Log | What it records | Alert on | ATT&CK v20 |
|---|---|---|---|
cPanel /usr/local/cpanel/logs/login_log | Login attempts to cpsrvd with failure reasons | Bursts of failures, successful root or reseller logins from new addresses | T1110 Brute Force; T1110.004 Credential Stuffing |
cPanel /usr/local/cpanel/logs/access_log and session_log | Account access with authentication method and port; session creation | Sessions created by tokens or for users who did not log in themselves | T1078 Valid Accounts |
cPanel /usr/local/cpanel/logs/api_tokens_log | WHM API token use: user, token name, request, status | Token use from new addresses, unusual functions, use of tokens believed retired | T1550.001 Application Access Token |
cPanel /var/cpanel/accounting.log | Account create, suspend, delete, reseller ownership, API token and 2FA changes | New accounts or tokens outside change windows; 2FA disabled for privileged users | T1136 Create Account; T1098 Account Manipulation |
cPHulk logs and reports; DirectAdmin failed_logins and Brute Force Monitor | Blocked users and IPs across panel, mail, FTP and SSH | Distributed failures against admin accounts | T1110 |
| Web server and plugin logs | Requests to panel and plugin endpoints | Requests matching vendor-published checks for exploited plugin functions | T1190; T1068 Exploitation for Privilege Escalation |
| File integrity on customer web roots | New PHP files after panel or site compromise | Web shells appearing across many accounts at once | T1505.003 Web Shell |
cPanel's api_log for user-level API calls is off until enabled in Tweak Settings; turn it on for servers with active integrations. Forward all of these to a SIEM so they survive a server compromise. See the SIEM Guide.
Metrics:
- Percentage of administrator and reseller accounts with 2FA enrolled (target 100 percent).
- Percentage of API tokens and login keys with an IP restriction and an expiry date.
- Number of tokens with "Everything", Manage API Tokens or key management rights.
- Days from a panel or plugin KEV entry to all panel servers patched.
- Number of panel servers whose admin port is reachable from the whole internet.
- Percentage of sites on dedicated PHP pools with file system isolation.
Common failure patterns
- One root token for all automation. Billing, DNS and migration scripts share a non-expiring "Everything" token stored on several servers. One leak gives full control of every server it works on.
- Admin port open to the internet. Pre-authentication flaws such as CVE-2026-41940 are then exploitable from anywhere the moment details leak.
- 2FA "enabled" at server level only. The policy is on but most resellers and customers never enrolled, and nobody measures it.
- Forgotten plugins. A web server or caching plugin installed years ago runs a privileged helper every tenant can reach, as in the LiteSpeed cPanel plugin cases.
- Shared credentials between customer sites. An agency reuses one database password and stores an SSH key in a hosting account; one site's compromise opens the rest.
- Panel-adjacent tools holding plaintext secrets. Provisioning and support tooling that can show customer passwords becomes the single target, as in the GoDaddy case.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management; AC-6 Least Privilege; IA-2 Identification and Authentication; IA-5 Authenticator Management; AC-7 Unsuccessful Logon Attempts | Admin and reseller accounts, token scope and expiry, 2FA, brute force protection |
| NIST SP 800-53 Rev. 5 | AC-17 Remote Access; SC-39 Process Isolation; SI-2 Flaw Remediation; AU-6 Audit Record Review | Panel network exposure, tenant isolation, patching, log review |
| NIST CSF 2.0 | PR.AA-01; PR.AA-03; PR.AA-05; PR.IR-01; DE.CM-03 | Managing human and machine panel identities, authentication, least privilege, network protection, monitoring activity |
| MITRE ATT&CK v20 | T1190; T1110; T1110.004; T1078; T1550.001; T1528; T1098; T1136; T1068; T1505.003 | Exploitation, credential attacks, token misuse, persistence and privilege escalation on panel servers |
| CISA KEV | CVE-2026-41940; CVE-2026-48172; CVE-2026-54420; CVE-2025-48703; CVE-2024-51567; CVE-2024-51378; CVE-2022-44877; CVE-2019-15107 | Patch priority for panel software and plugins |
Practitioner checklist
- Inventory panel servers, versions, plugins, administrators, resellers, tokens and login keys.
- Patch panels and plugins on KEV entries within days, and enable automatic panel updates.
- Restrict administrator logins and panel APIs to management addresses, after allowlisting your own.
- Enforce and measure 2FA for root, administrators and resellers; log every 2FA reset.
- Replace broad tokens with one scoped, IP-bound, expiring token per integration; delete expired tokens.
- Never store panel tokens or keys on customer web servers.
- Run each site in its own PHP pool with file system isolation; remove mod_php and CGI handlers.
- Split shared database and SSH credentials between customer sites.
- Forward login, session, token and accounting logs to a SIEM and alert on new tokens and accounts.
- Remove unused panel plugins and review reseller privileges quarterly.
Standards and references
- cPanel: Manage API Tokens in WHM
- cPanel: Two-Factor Authentication for WHM
- cPanel: cPHulk Brute Force Protection
- cPanel: The cPanel Log Files
- Plesk: Restricting Remote Access via Plesk API
- Plesk: PHP Handlers
- DirectAdmin: Securing DirectAdmin
- CISA: Known Exploited Vulnerabilities Catalog
Related NHI Mgmt Group resources: Admin panels and super admin accounts · API Key Management Guide · PHP2Shell · CISA KEV Catalogue Guide · Privileged Access Management Guide