Reviewing cPHulk login blocks without weakening global protection

Collect the affected username, service, client IP and failure time. Check whether a saved old password on a mail client or script is repeatedly retrying in the background.

1. Open cPHulk Brute Force Protection > History Reports through an authorised administrator session.
2. Choose the relevant failed-login, blocked-user or blocked-IP report and match the exact account, address and period.
3. Read the expiry and service details. Stop the legitimate application’s repeated bad attempts and correct its credentials before clearing a temporary block.
4. Use the supported targeted clearing or allowlisting control only for a verified trusted source. Keep any permanent allowlist narrow and documented.
5. Test a new login and monitor whether failures return. Preserve suspicious events for investigation rather than clearing every report immediately.

The legitimate login should work after its cause is corrected, while brute-force protection remains enabled for unrelated sources. A renewed block usually means the failing client or attack is still active.

Firewall rules, password errors and account suspension can produce similar symptoms. cPHulk does not cover every authentication method in the same way; public-key and token access require their own controls. Avoid disabling global protection to solve one user’s access issue.

That can exempt a very broad and changing population from protection. Prefer the smallest trusted administrative address range and review it when staff or network arrangements change.

• Enabling two-factor authentication for WHM administration
• Restricting a management service through WHM Host Access Control
• Revoking an exposed WHM API token and auditing its use
• Applying a narrowly scoped ModSecurity exception as administrator

• cPanel: Cphulk Brute Force Protection