WHM Security Advisor is most useful when it turns a post-update warning into an owned decision. After the July cPanel security update, that includes reviewing how the server applies two-factor authentication (2FA) policy to WHM API requests. This is not a checkbox to enable blindly: the right outcome is a policy that protects administrative access without surprising the people and systems responsible for legitimate hosting automation.
This checklist is for cPanel and WHM administrators who maintain shared hosting, agency servers, or internal application fleets. It combines the Security Advisor review with the current Configure Security Policies control and the service validation that should follow a panel update.
Understand the current API 2FA policy
cPanel's July 14 security update introduced a Security Policy that can apply the configured security-policy items to WHM API requests. When the policy is enabled alongside WHM two-factor authentication, API requests are no longer allowed to bypass that protection. New installations enable this policy by default. Existing servers are not changed automatically.
On an existing server where 2FA is already enabled but the API-request policy is not, cPanel can surface an Apply Security Policies to API requests Feature Showcase entry and a Security Advisor warning. Treat that prompt as a maintenance item: it is a reason to identify the owner of administrative automation and plan a controlled review, not proof that every server should be changed immediately without checking dependencies.
Start with ownership, not a toggle
Before changing the setting, identify which team owns WHM administration, billing or provisioning integrations, monitoring, internal tools, DNS coordination, and emergency access. Record a current contact for each system that may rely on WHM access. A policy change is easier to operate when an administrator knows who can validate each dependent workflow and who can approve an exception.
Also confirm that the server's interactive administrators have an approved two-factor enrollment and a documented account-recovery path. Do not use a production change window to discover that the only person who understands an administrative integration or recovery process is unavailable.
Review the policy in WHM
In WHM, open Security Center > Configure Security Policies. The page separates the main security-policy items from Security Policy Extensions. The API requests extension controls whether the selected security-policy items apply to WHM API requests. The same area also includes a separate DNS-cluster extension; do not treat the two as one setting just because they appear in the same section.
Review the current state before making a change. Confirm whether two-factor authentication is part of the active policy, whether the API-request extension is already enabled, and whether the Security Advisor item matches what the team expects. Hosting providers can control which panel capabilities are available to some users, so record provider-managed limits rather than trying to work around them.
When the responsible owners are ready, make the approved policy decision through the supported WHM interface. Do not combine it with unrelated authentication, DNS, mail, firewall, or PHP changes. A narrow change makes later verification and rollback discussion understandable.
Validate the real administrative workflows
After the policy change, verify normal WHM administration first. Then ask the owner of each approved automation or integration to confirm its expected workflow during a controlled window. The goal is to prove that intended administrative work remains available under the selected policy, not merely to clear a warning.
- Confirm that authorized administrators can sign in and complete normal panel work.
- Check the hosting functions that depend on coordinated administrative access, such as account lifecycle work, domain or DNS coordination, and service monitoring.
- Verify the customer-facing paths that a recent panel update could affect: a representative hosted site, webmail, mail delivery, TLS, and a managed WordPress login when those services are present.
- Record the policy state, validation owner, time window, and any accepted exception in the change record.
If an approved integration does not behave as expected, pause the rollout and work with its owner through the supported product documentation. Do not weaken unrelated controls to make an unverified integration work. A clear exception with an owner and review date is safer than an undocumented permanent workaround.
Use Security Advisor as the final configuration pass
After the immediate service checks, return to Security Advisor. Classify findings instead of recording a vague "looks fine" result. Separate items that are fixed now from items that need an owner, provider involvement, a planned reboot, or a license and architecture decision. This is especially useful on mixed fleets where some hardening controls are host-managed and others are the server administrator's responsibility.
Review whether notification recipients are still current, whether the server's malware and kernel-maintenance posture matches the organization policy, and whether recent cPanel release notes introduced a follow-up task. A Security Advisor result is not a replacement for patching, but it is a useful way to catch hardening drift after the patch is complete.
Keep the panel update and policy review connected
Use the cPanel & WHM Version 136 upgrade and security update checklist for the supported panel-maintenance and service-verification path. Keep the API-policy decision attached to that change record so a future administrator can see why the setting is enabled, which workflows were checked, and when the next review is due.
For adjacent panel administration topics, visit the cPanel and WHM support hub. When a site-level symptom remains after the hosting layer is healthy, the WordPress Support guide helps separate application troubleshooting from server-policy work.
Sources
- cPanel & WHM release notes: July 14 API-request 2FA security policy
- cPanel documentation: Configure Security Policies
Confirm the panel security-update cadence
After reviewing API 2FA policy, confirm how the server receives cPanel security releases. Recent cPanel & WHM 110 changes introduced a Security Updates control in WHM Update Preferences for current-major security releases. Treat the setting as an operational decision: verify the release tier, the update window, notification ownership, and the workflow for validating customer-facing services after a security update. Do not assume a default is appropriate for every managed fleet without confirming the server's policy and support commitments.
Review current component security fixes
The cPanel & WHM 110.0.136 changelog includes an update to Roundcube 1.6.17 that addresses CVE-2026-54432 and CVE-2026-54433. Use the supported cPanel update process to bring eligible servers current, then verify webmail, hosted sites, mail delivery, TLS, and the approved administrative workflows described above. Keep this review separate from unrelated mail-server, DNS, PHP, or firewall changes so any follow-up is easy to trace.
Keep the WordPress estate in the same maintenance loop
Panel hygiene and WordPress hygiene reinforce each other. Pair this WHM review with our WordPress security update checklist, and use the WordPress support hub when a site needs a coordinated update, cache, email, or performance check.
July 2026 EasyApache and WAF follow-up
cPanel's July 15 security notes add a separate maintenance task alongside the WHM API two-factor policy. The EasyApache updates include PHP security fixes for supported 8.2 through 8.5 packages, while the ModSecurity update addresses an issue that could weaken WAF rule enforcement for some request bodies. Review the current cPanel release notes before scheduling production maintenance.
Keep this work separate from the API policy decision. The API policy protects interactive browser-session use of the cPanel and WHM API; EasyApache and ModSecurity updates protect the server stack and its web application firewall. Both belong in the same change review, but they have different compatibility and service-impact checks.
Maintenance checklist
- Record the active cPanel release tier and the installed server build before the change window.
- Review affected PHP versions, web applications, and any extensions that have known compatibility requirements.
- Apply the approved cPanel and EasyApache updates through the normal server maintenance workflow.
- Confirm that web services and ModSecurity are healthy after the update, then test an affected WordPress administrator flow and a public page.
- Review Security Advisor findings and error reporting for follow-up items instead of treating a successful package update as the final check.
Do not defer a supported PHP package security update solely because a site needs compatibility testing. Use a planned window, validate the site immediately afterward, and keep the compatibility work moving. For WordPress-side maintenance, start with our WordPress Support resources.
