WHM Service Subdomains: Blocking Port 2087 May Not Be Enough

Summary

Blocking WHM ports 2086 and 2087 is not always enough to remove public WHM exposure. On cPanel servers, WHM may still be reachable through service/proxy subdomains such as whm.customer-domain.tld over HTTPS port 443.

This matters when administrators restrict the direct WHM port but leave another HTTPS-based access path active through generated service subdomains, proxy subdomains, DNS records, or webserver virtualhost configuration.

This article is based on operational observations from shared hosting environments where WHM exposure was reviewed as part of server hardening and incident response.

The issue should be treated as a configuration and exposure-path security risk. It is not, by itself, a claim of a cPanel exploit or 0-day vulnerability.

Who this is for

This article is intended for:

• shared hosting providers
• cPanel/WHM administrators
• security teams reviewing WHM exposure
• incident responders investigating cPanel compromise paths
• sysadmins hardening public hosting infrastructure

Quick check

From an external network that is not allowlisted, enter a customer domain hosted on the server and test both direct WHM access and the service subdomain path:

curl -Ik https://server.example.com:2087/
curl -Ik https://whm.customer-domain.tld/

If the direct WHM port is blocked but the service subdomain still returns a WHM/cPanel login page, cpsess redirect, or cpsrvd response over HTTPS port 443, WHM is still exposed through another path.

A sanitized response may look like this:

HTTP/2 200
server: cpsrvd
content-type: text/html

or:

HTTP/1.1 301 Moved
location: /cpsessXXXXXXXXXX/login/

Tested environment

The behavior described here was observed in shared hosting environments using:

• cPanel & WHM 136.x
• CloudLinux 8.x
• Apache or LiteSpeed generated virtualhost configuration
• Service/proxy subdomains enabled
• WHM port 2087 restricted at firewall level

The exact behavior can vary depending on firewall rules, proxy configuration, service subdomain settings, and generated virtualhost configuration.

The common assumption

A common cPanel hardening approach is simple:

Block public access to WHM ports 2086 and 2087.
Allow only trusted IP addresses or internal networks.

The logic is understandable.

WHM is an administrative interface. It should not be exposed to the public internet unless there is a strong reason for that exposure.

In many environments, firewall rules are configured so that only trusted office IPs, VPN ranges, jump servers, or internal management networks can reach WHM.

At first glance, that looks sufficient.

If an attacker cannot reach:

https://server-hostname.example.com:2087/

then WHM should not be reachable.

However, on cPanel systems, there is another access path that administrators sometimes overlook.

What are cPanel service/proxy subdomains?

cPanel supports service or proxy subdomains that allow users to access services through friendly hostnames instead of service ports.

Common examples include:

cpanel.example.com
webmail.example.com
webdisk.example.com
whm.example.com

These are convenient because users do not need to remember ports such as:

2083
2087
2095
2096

Instead, they can access services over standard web ports:

80
443

For user-facing services such as cPanel, Webmail, and Webdisk, this can be useful.

But WHM is different.

WHM is not just another user-facing service. WHM is an administrative interface used for server administration, reseller administration, account management, API tokens, password changes, service restarts, terminal access, DNS management, and other privileged operations.

Because of that, WHM should not automatically share the same exposure model as Webmail.

The real security concern

The key issue is simple: direct WHM port restriction is not the same as removing every HTTP(S)-based WHM exposure path.

Direct WHM access

The direct WHM interface normally uses the WHM service port:

https://server.example.com:2087/

Restricting this port at the firewall is a valid hardening step, especially when access is limited to VPN, office IP ranges, jump hosts, or management networks.

Service/proxy subdomain access

On cPanel servers, WHM may also be reachable through a service/proxy subdomain over standard HTTPS:

https://whm.customer-domain.tld/

This path uses HTTPS port 443, which usually remains open for customer websites. If the generated virtualhost or proxy mapping forwards that hostname to WHM, blocking 2087 alone may not remove public WHM exposure.

Why the distinction matters

A server can have a blocked direct WHM port and still expose WHM through another hostname and port combination:

direct path:          https://server.example.com:2087/
service subdomain:    https://whm.customer-domain.tld/

If only the first path is restricted, WHM may still be reachable through the second path. That is the security gap.

This does not automatically mean there is a cPanel exploit. It should not be described that way without evidence.

A more accurate description is:

This is a security-sensitive configuration and exposure-path problem.

Why this matters more on shared hosting servers

On a single-server private setup, the administrator may have only a few domains to consider.

On a shared hosting server, the situation is very different.

A shared hosting server may host hundreds or thousands of domains. If WHM service/proxy subdomains are generated across customer domains, the number of possible WHM entry points grows significantly.

Examples:

whm.customer-domain-1.tld
whm.customer-domain-2.tld
whm.customer-domain-3.tld
whm.customer-domain-4.tld

This matters for several reasons.

First, the attack surface becomes larger. Instead of one known WHM hostname, there may be many domain-based WHM hostnames.

Second, firewall logic becomes more complicated. Port 443 cannot simply be blocked because it is required for customer websites.

Third, administrators may have a false sense of security. They may believe WHM is restricted because 2087 is blocked, while WHM may still be accessible over 443.

Fourth, incident response becomes harder. If an attacker has valid WHM credentials, a stolen session, a privileged API token, or another form of administrative access, every additional WHM access path makes containment more difficult.

Service subdomain override risk

One particularly important cPanel setting is:

Service subdomain override

This setting allows users to create service subdomains such as:

cpanel
webmail
webdisk
cpcalendars
cpcontacts
whm

that override automatically generated service subdomains.

For services like cpanel, webmail, or webdisk, this may be acceptable in some environments.

For whm, it is more sensitive.

On shared hosting infrastructure, regular hosting users should not be able to create, control, or override whm.* behavior in a way that affects administrative access paths.

WHM should be treated differently from user-facing service subdomains.

A more secure model would allow providers to configure service subdomains individually, for example:

cpanel      enabled
webmail     enabled
webdisk     enabled
cpcontacts  enabled
cpcalendars enabled
whm         disabled

That distinction matters because Webmail and WHM do not carry the same risk.

Generic incident pattern

In serious cPanel/WHM compromise scenarios, attackers often do more than simply log in.

A generic incident pattern may include:

suspicious WHM root login
root password change
SSH key removal
WHM API token creation
privileged user or reseller abuse
modified cPanel/WHM login template
credential harvesting
cron or system persistence
attempted access to customer accounts

This pattern is especially dangerous if the login interface itself is modified.

If a cPanel, WHM, or Webmail login template is changed to capture submitted credentials, then every user who logs in after the modification may have their credentials exposed.

In such a case, rotating only the root password is not enough.

Administrators must consider the possibility that user credentials, reseller credentials, API tokens, and other authentication material may also be compromised.

Why WHM over 443 changes the containment model

During incident response, administrators may quickly block direct WHM ports such as:

2086
2087

That is a reasonable emergency action.

But if WHM remains reachable through:

https://whm.customer-domain.tld/

then the attacker may still have an available path to the WHM interface over:

443

This is why administrators should verify real exposure paths, not only firewall rules.

A firewall rule can be correct and still incomplete.

The real question is:

Can WHM still be reached from an untrusted network through any hostname or port?

How to test whether WHM is exposed through service subdomains

External testing is important. Do not only inspect firewall rules. Test from a network that is not allowlisted.

Start with the direct WHM port:

curl -Ik https://server.example.com:2087/

Then test the WHM service subdomain path:

curl -Ik https://whm.customer-domain.tld/

If direct access to 2087 is blocked, but https://whm.customer-domain.tld/ still returns a WHM/cPanel login page, redirect, cpsess URL, cpsrvd header, or WHM-like response over HTTPS port 443, then WHM still has an exposure path.

You can also test multiple sanitized customer-domain examples:

curl -Ik https://whm.customer-domain-1.tld/
curl -Ik https://whm.customer-domain-2.tld/
curl -Ik https://whm.customer-domain-3.tld/

Look for responses that indicate WHM/cPanel handling, such as:

WHM login page
cPanel login page
cpsess redirect
service proxy redirect
server: cpsrvd
HTTP response from cPanel/WHM proxy layer

Useful OpsCheck tools

You can also verify DNS, TLS, HTTP headers, and port exposure using OpsCheck tools such as the DNS Lookup Tool, SSL Certificate Checker, HTTP Header Checker, and Port Checker.

For ownership and network context checks, the WHOIS Lookup and IP / ASN Lookup can also help validate which domains, IP addresses, and networks are involved.

Local checks on the server

You can also check DNS zones and generated webserver configuration.

Search DNS zones for whm. records:

grep -R "whm\." /var/named/*.db 2>/dev/null | head

Search Apache configuration for WHM server aliases:

grep -R "ServerAlias.*whm\." /etc/apache2/conf/ /etc/apache2/conf.d/ 2>/dev/null

On cPanel servers using LiteSpeed, remember that LiteSpeed may use generated Apache-compatible configuration. Check the generated configuration path used by your environment.

Also verify the result externally. Local configuration checks are useful, but the final test should be from outside the trusted network.

Workaround: remove only the WHM service subdomain

cPanel provides a command that can remove a specific service subdomain.

For WHM, the command is:

/scripts/proxydomains --subdomain=whm remove
/scripts/rebuildhttpdconf
/scripts/restartsrv_httpd

On LiteSpeed servers, the restart command may be different:

/scripts/proxydomains --subdomain=whm remove
/scripts/rebuildhttpdconf
systemctl restart lsws

This can remove WHM service subdomains for existing users and domains.

However, this should be treated as a cleanup action, not as a complete permanent policy.

The important limitation is that future actions may recreate service subdomains depending on the environment and configuration.

Examples include:

new account creation
account restore
account transfer
DNS zone rebuild
service domain rebuild
configuration regeneration
manual or automated cPanel scripts

Because of that, one-time removal is not enough for larger shared hosting fleets.

Recommended long-term hardening approach

A more reliable approach is layered.

1. Disable Service subdomain override

If regular users can override service subdomains, consider disabling that option.

This is especially important for whm.*.

The goal is to prevent users from influencing administrative service hostnames.

2. Remove existing WHM service subdomains

Run:

/scripts/proxydomains --subdomain=whm remove
/scripts/rebuildhttpdconf
/scripts/restartsrv_httpd

or the LiteSpeed equivalent:

/scripts/proxydomains --subdomain=whm remove
/scripts/rebuildhttpdconf
systemctl restart lsws

3. Enable 2FA for WHM root and privileged users

Two-factor authentication should be enabled for WHM root access and any privileged WHM or reseller accounts.

This does not remove the WHM service/proxy subdomain exposure path, and it should not be treated as a replacement for network restrictions, Host Access Control, or service subdomain hardening.

However, it does reduce the risk of a password-only compromise. If an attacker obtains the WHM root password, 2FA can prevent direct login unless the attacker also has access to the second factor.

For shared hosting environments, 2FA should be considered a baseline control for:

• the WHM root account
• reseller accounts with elevated privileges
• accounts with root-level or near-root WHM ACLs
• administrative accounts used by hosting staff

Administrators should also review whether API tokens, external authentication methods, and reseller privileges are still required. 2FA protects interactive login, but it does not replace proper API token hygiene or privilege review.

Recommended checks:

whmapi1 twofactorauth_policy_status

If 2FA is not enabled, enable it from:

WHM » Security Center » Two-Factor Authentication

or through the WHM API where appropriate.

Also consider Host Access Control for WHM:

WHM » Security Center » Host Access Control

In Host Access Control, restrict the WHM service (whostmgrd) to trusted administrative IP addresses where operationally possible.

Even with 2FA enabled, administrators should still verify whether WHM is reachable through whm.customer-domain.tld over port 443.

2FA makes unauthorized login harder, but it does not change the fact that WHM may still be exposed through an alternate hostname and port.

The goal should be layered security:

Limit where WHM is reachable.
Require 2FA for privileged login.
Restrict WHM by trusted IPs where possible.
Audit WHM API tokens.
Monitor WHM sessions and login events.
Remove unnecessary WHM service subdomain exposure.

4. Verify externally

Check from outside the trusted network:

curl -Ik https://whm.example.com/
curl -Ik https://example.com:2087/

The expected result depends on your policy, but if your intent is to block public WHM access, whm.example.com should not expose the WHM interface publicly.

5. Add periodic audits

Add a periodic audit that checks whether whm.* service subdomains have reappeared.

Example checks:

grep -R "whm\." /var/named/*.db 2>/dev/null

grep -R "ServerAlias.*whm\." /etc/apache2/conf/ /etc/apache2/conf.d/ 2>/dev/null

This audit can alert administrators instead of automatically changing configuration.

For larger fleets, central reporting is recommended.

6. Consider hook-based enforcement

In larger cPanel environments, manual cleanup is not enough.

Consider controlled hook-based enforcement after events such as:

account creation
domain addition
subdomain creation
account restore
transfer completion
DNS rebuild

The hook can either alert administrators or remove the WHM service subdomain again.

Be careful with automatic rebuilds and webserver restarts on busy shared hosting servers. Test thoroughly before deploying fleet-wide automation.

Incident response checklist for cPanel administrators

If you suspect WHM abuse, review at least the following areas.

cPanel and WHM logs

/usr/local/cpanel/logs/session_log
/usr/local/cpanel/logs/access_log
/usr/local/cpanel/logs/error_log

Look for:

unknown WHM root logins
root password changes
API token creation
session transfers
possessed sessions
WHM Terminal access
unusual user agents
unexpected source IPs

System authentication logs

/var/log/secure

Look for:

SSH logins
sudo activity
password changes
new users
failed logins
unexpected public key authentication

WHM API tokens

List and review API tokens.

Pay attention to:

tokens with all privileges
tokens without expiration
tokens created recently
tokens with suspicious names
tokens created from unknown IP addresses

Users and privileges

Check:

/etc/passwd
/etc/group
/etc/shadow
/etc/sudoers
/etc/sudoers.d/

Look for:

new privileged users
unexpected shell access
users in wheel/root-related groups
NOPASSWD sudo entries
suspicious service-like usernames

Reseller privileges

Check reseller configuration and privileges.

Look for:

unexpected reseller accounts
root-equivalent ACLs
recently changed reseller privileges
unknown owner relationships

SSH keys

Review:

/root/.ssh/authorized_keys

Look for:

unknown keys
recent modifications
keys without clear comments
duplicate or suspicious backup files

Cron and persistence

Check:

/var/spool/cron/
/etc/cron.d/
/etc/cron.daily/
/etc/cron.hourly/
/etc/systemd/system/

Look for:

scripts restoring modified files
curl/wget downloaders
hidden persistence jobs
unexpected service files
suspicious shell scripts

cPanel/WHM templates

Check whether login templates or other cPanel interface files were modified.

If login templates were modified, assume credentials may have been captured.

In that case, consider:

root password reset
WHM API token revocation
reseller password resets
user password resets
mail account password resets
review of recent logins
review of file manager activity
review of web shells

Important note about root compromise

If root compromise is confirmed, cleanup on the same server may reduce immediate risk, but it does not always restore trust.

A full rebuild or migration to a clean server is often the safer long-term option.

Before migrating, inspect customer accounts carefully.

Do not blindly move:

malicious cron jobs
web shells
backdoored PHP files
unknown SSH keys
compromised CMS plugins
malicious mail filters
infected application files

Otherwise, the compromise may simply move to the new server.

What vendors should ideally provide

The cleanest long-term solution would be a per-service control for service/proxy subdomains.

For example:

cpanel      enabled
webmail     enabled
webdisk     enabled
cpcontacts  enabled
cpcalendars enabled
whm         disabled

This would let hosting providers keep user-facing service subdomains while disabling WHM exposure through customer domains.

That model is more appropriate for shared hosting environments because WHM has a different risk profile from Webmail or Webdisk.

Conclusion

Service/proxy subdomains are useful, but WHM should not be treated the same as user-facing services.

Blocking port 2087 is a good security control, but it may not be complete if WHM remains reachable through whm.customer-domain.tld over port 443.

For shared hosting providers, the key lesson is:

Verify actual WHM exposure paths, not only firewall rules.

A practical hardening approach should include:

disabling Service subdomain override
removing WHM service subdomains
testing externally
auditing DNS and webserver configuration
monitoring WHM logs and API tokens
considering hook-based enforcement
building a clear incident response process

Blocking port 2087, enabling WHM 2FA, and using Host Access Control are all useful controls, but none of them should be treated as a substitute for verifying whether WHM is still reachable over 443 through service/proxy subdomains.

The worst assumption is that WHM is protected only because port 2087 is blocked.

In cPanel environments, that assumption is not always true.

FAQ

Does blocking port 2087 fully block WHM access?

Not always. If WHM is still reachable through a service/proxy subdomain such as whm.customer-domain.tld over HTTPS port 443, direct port blocking alone may be incomplete.

Is this a cPanel vulnerability?

Not necessarily. In most cases, this should be described as a configuration and exposure-path issue unless there is evidence of an actual vulnerability.

Should WHM service subdomains be enabled on shared hosting servers?

That depends on the hosting model and operational requirements. For shared hosting providers, WHM exposure should usually be treated differently from user-facing services such as Webmail or cPanel.

What should administrators audit?

Administrators should audit firewall rules, service/proxy subdomain settings, generated virtualhost configuration, DNS records, and external reachability from a non-allowlisted network.

References

• WHM Exposure Checker - compare WHM access on ports 2087 and 443.
• cPanel Documentation: Service and Proxy Subdomains
• cPanel Documentation: How to Configure Your Firewall for cPanel & WHM Services
• cPanel Documentation: Tweak Settings — Domains
• cPanel Documentation: Manage Service SSL Certificates
• cPanel: What is Host Access Control?
• cPanel: How to enable 2FA in WHM