cPHulk monitors failed logins to WHM, cPanel, SSH, FTP and mail services by account and source address. It does not always identify itself when blocking access, so symptoms can appear as invalid credentials, a timeout or a firewall-level drop. The correct remediation is to whitelist the administrator address and clear only the relevant lockout, not to leave protection disabled.
The same error screen can originate from different services. Separate network reachability, service state, firewall policy and authentication before changing anything.
An IP-based or account-based threshold may have been reached without an explicit cPHulk message.
When firewall-level blocking is enabled, cPHulk may create an iptables rule.
The server and account are healthy; the previous public address is likely blocked.
The lockout or firewall policy was generated by cPHulk and requires targeted cleanup.
Instead of disabling the entire protection stack, prove which rule blocks access and change only the required scope.
The source can receive a temporary or one-day block after crossing the configured threshold.
Distributed attempts can lock the account regardless of the attacker source address.
A dynamic public IP change makes the previous whitelist entry ineffective.
A current iptables block can continue to drop traffic until the affected history is flushed.
Back up the current configuration, validate syntax and keep a second administration session open before every service or firewall change.
Do not whitelist an address from an old VPN, mobile network or CGNAT session.
Correlate the user, source address, service and timestamp for the failed login.
Use a single address or /32 instead of trusting a broad ISP network.
Use flush_cphulk_login_history_for_ips instead of deleting all cPHulk evidence.
A separate CSF or upstream firewall rule can remain active after the cPHulk record is removed.
Reduce password-based root access and preserve an independent recovery path.
Replace example IP addresses, ports and paths with your own values. Review command output before moving to the next step.
whmapi1 --output=jsonpretty cphulk_status whmapi1 --output=jsonpretty read_cphulk_records list_name='white'
/usr/local/cpanel/scripts/cphulkdwhitelist 203.0.113.10 whmapi1 --output=jsonpretty create_cphulk_record list_name='white' ip='203.0.113.10' comment='Eka administrator IP'
whmapi1 --output=jsonpretty flush_cphulk_login_history_for_ips ip='203.0.113.10'
tail -n 100 /usr/local/cpanel/logs/cphulkd.log tail -n 100 /usr/local/cpanel/logs/cphulkd_errors.log /usr/local/cpanel/scripts/restartsrv_cphulkd
A wrong firewall, SSH or login-protection rule can make the server unreachable. Do not close management ports without KVM, VNC or provider console access.
Not always. Existing account or address locks can remain, so remove the affected history explicitly.
The WHM API may remove cPHulk-generated blocks, but a separate CSF or provider firewall rule must be checked independently.
cPanel documentation states that cPHulk does not affect public-key authentication, making it an important recovery path.
Usually not. Remove only the affected administrator address to preserve evidence and unrelated protection records.
Monitored services, account and IP thresholds, whitelist and history reports.
Whitelist, blacklist, log files and lockout-removal procedures.
WHM API 1 operation that removes login history for selected addresses.
Parameters for adding an address with a comment to the white or black list.
Key-based access, custom ports and secure sshd configuration.
The correct security method is not to disable protection, but to measure the network, service and rule path and apply the narrowest safe change.